Question about determining 3GPP adaptation and sending NADU app packets

---

From: ext Milko Boic [mailto:milkoreal.com]
Sent: Tuesday, July 25, 2006 11:57 AM
To: Chen Carol.I (Nokia-TP-MSW/Dallas); protocol-devhelixcommunity.org
Subject: Re: [Protocol-dev] Question about determining 3GPP adaptation and sending NADU app packets

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
       ;  boundary="----_=_NextPart_001_01C6AF83.D93C78BF"

Hi,

We have encountered a problem where Helix client is sending HELX packets in RR instead of PSS0 (NADU) ones when streaming against a non-Real server capable of 3GPP adaptation.

In CHXRateAdaptationInfo::OnRateAdaptResponse, we check the Request and Response headers to see if they match. If there's a mismatch -> NADU parameters not set -> NADU report frequency is zero -> NADU packets not sent -> HELX packets sent instead.

In 3GPP TS 26.234, it requires the server not to change the values in the response header. However, it doesn't say anything about the order of the adaptation parameters. The mismatch comes about when a server "swaps" the buffer-size and target-time parameters, i.e.:

Request -- 3GPP-Adaptation: url=" rtsp://mediaserver.com/movie.test/streamID=0 ";target-time=5000;size=14500
Response -- 3GPP-Adaptation: url=" rtsp://mediaserver.com/movie.test/streamID=0 ";size=14500;target-time=5000

Since a memcmp is done on the two buffers, the above will fail. Another (non-Real) server returns the Response header without swapping the two values, and so we send PSS0 packets as desired.

My first question: is there a fixed order for the parameters? TS 26.234 doesn't confirm that, even though the ABNF for the 3GPP-Adaptation header -- as well as the example RTSP chats -- seem to suggest that buffer-size should come before target-time. (Also, in CHelixAdaptationHeader, there's a "paramOrder" function that also places buffer-size in front of target-time, but not in C3gpAdaptationHeader.)

Possible solutions:

(1) Make our Request header put the buffer-size before target-time, i.e. add C3gpAdaptationHeader::paramOrder().

(2) Suggest to server implementation that they should always return the Response header exactly the same as Request header without changing the order of the parameters.

(3) When comparing the two headers, instead of using memcmp, we break down the parameters and compare them individually by their keys.

I'm inclined to (1) but I thought I should ask the group first since this is common code.

Thanks in advance for any comments / suggestions.

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