CN: Helix client not sending PSS0 (NADU) APPpacket in RR

Thanks Eric. Checked in to 210CayS and HEAD.

-----Original Message-----
From: ext Eric Hyche [real.com" eudora="autourl"> mailto:ehychereal.com]
Sent: Thursday, July 27, 2006 12:33 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org
Subject: RE: [Protocol-dev] CR-RESEND: Helix client not sending PSS0
(NADU) APPpacket in RR


Looks good.

> -----Original Message-----
> From: protocol-dev-bounceshelixcommunity.org
> [helixcommunity.org" eudora="autourl"> mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of
> Carol.i.Chennokia.com
> Sent: Thursday, July 27, 2006 12:03 PM
> To: protocol-devhelixcommunity.org
> Subject: [Protocol-dev] CR-RESEND: Helix client not sending PSS0
>; (NADU) APPpacket in RR
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
>; code under said agreement."
>;
> Modified by:
>     carol.i.chennokia.com
>
> Reviewed by:
>
> Date:
>     7-26-2006
>
> Error ID:
>     TSW ID=EJZG-6RKS6U
>
> Project:
>     Helix plugin for Symbian
>
> Synopsis:
>     When negotiating 3GPP-adaptation with a server, we send a Request
> header after determining server has 3GPP-adaptation-support from the
> Session Description. We expect the server to send a Response header
> back that matches our Request header. If there's a mismatch, NADU
>; parameters (such as report frequency) will not be set. Later when
>; constructing RR packets, we check for the report frequency, but that
>; fails so we don't send NADU APP packets. The mismatch happens when a
> server switches the two parameters (buffer size and target time)
> around. (The parameter values are not changed, as required by TS
> 26.234.) Some servers just send the exact copy of our Request header
> back as the Response (bless those guys) and all's fine. Those that
>; swaps the two params could have done it based on the examples in the
> TS, where buffer-size always comes before target-time.
> The solution is to order the params in our outgoing Request header so
> that we follow the "convention"; as well.
>;
> Files Modified:
>     protocol\rtsp\pub\3gpadapthdr.h
>     protocol\rtsp\3gpadapthdr.cpp
>
> Files Added:
>     none
>
> Image Size and Heap Use impact:
>     minor
>;
> Platforms and Profiles Build Verified:
>     armv5 / helix-client-s60-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified:
>     armv5 / helix-client-s60-mmf-mdf-dsp
>
> Branch:
>     hxclient_2_1_0_cayennes and HEAD
>
>
>
> Index: 3gpadapthdr.h
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/pub/3gpadapthdr.h,v
> retrieving revision 1.3
> diff -u -w -r1.3 3gpadapthdr.h
> --- 3gpadapthdr.h       3 Feb 2005 21:10:49 -0000 ;      1.3
> +++ 3gpadapthdr.h       26 Jul 2006 17:05:56 -0000
> -60,6 +60,7
>  protected:
>      virtual const char* const* intParams() const;
>      virtual const char* const* stringParams() const;
> +    virtual const char* const* paramOrder() const;
>
>  private:
>      // Hide copy constructor and assignment operator.
> -68,5 +69,6
>
>      static const char* const zm_pIntParams[];
>      static const char* const zm_pStringParams[];
> +    static const char* const zm_pParamOrder[];
>  };
>  #endif /* _3GP_ADAPT_HDR_H */
>
>
> Index: 3gpadapthdr.cpp
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/3gpadapthdr.cpp,v
> retrieving revision 1.3
> diff -u -w -r1.3 3gpadapthdr.cpp
> --- 3gpadapthdr.cpp   ;  3 Feb 2005 21:10:48 -0000     ;  1.3
> +++ 3gpadapthdr.cpp   ;  26 Jul 2006 17:06:30 -0000
> -55,6 +55,11
>  const char* const C3gpAdaptationHeader::zm_pStringParams[] = {"url",
>          ;           ;           ;           ;           ;    NULL};
>
> +const char* const C3gpAdaptationHeader::zm_pParamOrder[] = {"url",
> +      ;           ;           ;           ;           ;      "size",
> +         ;           ;           ;           ;           ;  
> "target-time",
> +  ;           ;           ;           ;           ;          NULL};
> +
>  C3gpAdaptationHeader::C3gpAdaptationHeader()
>  {}
>
> -72,3 +77,9
>  {
>      return zm_pStringParams;
>  }
> +
> +const char* const*
> +C3gpAdaptationHeader::paramOrder() const {
> +    return zm_pParamOrder;
> +}
>
>
>
>
>
>


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev

---

From: ext Rishi Mathew [mailto:rmathewreal.com]
Sent: Thursday, July 27, 2006 3:34 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); ehychereal.com; protocol-devhelixcommunity.org
Subject: RE: [Protocol-dev] CN: Helix client not sending PSS0 (NADU) APPpacket in RR

Thanks Eric. Checked in to 210CayS and HEAD.

-----Original Message-----
From: ext Eric Hyche [real.com" eudora="autourl"> mailto:ehychereal.com]
Sent: Thursday, July 27, 2006 12:33 PM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org
Subject: RE: [Protocol-dev] CR-RESEND: Helix client not sending PSS0
(NADU) APPpacket in RR


Looks good.

> -----Original Message-----
> From: protocol-dev-bounceshelixcommunity.org
> [helixcommunity.org" eudora="autourl"> mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of
> Carol.i.Chennokia.com
> Sent: Thursday, July 27, 2006 12:03 PM
> To: protocol-devhelixcommunity.org
> Subject: [Protocol-dev] CR-RESEND: Helix client not sending PSS0
> (NADU) APPpacket in RR
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by:
> ;    carol.i.chennokia.com
>
> Reviewed by:
>
> Date:
> ;    7-26-2006
>
> Error ID:
> ;    TSW ID=EJZG-6RKS6U
>
> Project:
> ;    Helix plugin for Symbian
>
> Synopsis:
> ;    When negotiating 3GPP-adaptation with a server, we send a Request
> header after determining server has 3GPP-adaptation-support from the
> Session Description. We expect the server to send a Response header
> back that matches our Request header. If there's a mismatch, NADU
> parameters (such as report frequency) will not be set. Later when
> constructing RR packets, we check for the report frequency, but that
> fails so we don't send NADU APP packets. The mismatch happens when a
> server switches the two parameters (buffer size and target time)
> around. (The parameter values are not changed, as required by TS
> 26.234.) Some servers just send the exact copy of our Request header
> back as the Response (bless those guys) and all's fine. Those that
> swaps the two params could have done it based on the examples in the
> TS, where buffer-size always comes before target-time.
> The solution is to order the params in our outgoing Request header so
> that we follow the "convention" as well.
>
> Files Modified:
> ;    protocol\rtsp\pub\3gpadapthdr.h
> ;    protocol\rtsp\3gpadapthdr.cpp
>
> Files Added:
> ;    none
>
> Image Size and Heap Use impact:
> ;    minor
>
> Platforms and Profiles Build Verified:
> ;    armv5 / helix-client-s60-mmf-mdf-dsp
>;
> Platforms and Profiles Functionality verified:
> ;    armv5 / helix-client-s60-mmf-mdf-dsp
>;
> Branch:
> ;    hxclient_2_1_0_cayennes and HEAD
>
>
>
> Index: 3gpadapthdr.h
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/pub/3gpadapthdr.h,v
> retrieving revision 1.3
> diff -u -w -r1.3 3gpadapthdr.h
> --- 3gpadapthdr.h       3 Feb 2005 21:10:49 -0000 ;      1.3
> +++ 3gpadapthdr.h       26 Jul 2006 17:05:56 -0000
> -60,6 +60,7
> ; protected:
> ;     virtual const char* const* intParams() const;
> ;     virtual const char* const* stringParams() const;
>; +    virtual const char* const* paramOrder() const;
>;
> ; private:
> ;     // Hide copy constructor and assignment operator.
> -68,5 +69,6
>
> ;     static const char* const zm_pIntParams[];
> ;     static const char* const zm_pStringParams[];
> +    static const char* const zm_pParamOrder[];
>;  };
>  #endif /* _3GP_ADAPT_HDR_H */
>
>
> Index: 3gpadapthdr.cpp
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/3gpadapthdr.cpp,v
> retrieving revision 1.3
> diff -u -w -r1.3 3gpadapthdr.cpp
> --- 3gpadapthdr.cpp   ;  3 Feb 2005 21:10:48 -0000 ;      1.3
> +++ 3gpadapthdr.cpp   ;  26 Jul 2006 17:06:30 -0000
> -55,6 +55,11
> ; const char* const C3gpAdaptationHeader::zm_pStringParams[] = {"url",
> ;           ;           ;           ;           ;           ;  NULL};
>;
> +const char* const C3gpAdaptationHeader::zm_pParamOrder[] = {"url",
> +         ;           ;           ;           ;           ;   "size",
> +         ;           ;           ;           ;           ;  
> "target-time",
> +         ;           ;           ;           ;           ;   NULL};
>; +
> ; C3gpAdaptationHeader::C3gpAdaptationHeader()
> ; {}
>
> -72,3 +77,9
> ; {
> ;     return zm_pStringParams;
>;  }
> +
> +const char* const*
>; +C3gpAdaptationHeader::paramOrder() const {
> +    return zm_pParamOrder;
> +}
>
>
>
>
>
>


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev