Subject: Re: [MMUSIC] Transport Header Stipulation

From: Rishi Mathew <[email-masked]>
Date: Wed, 03 Nov 2004 16:01:46 -0800

Magnus,

Sorry for the late response...

Comments inline..

At 01:07 AM 10/19/2004, Magnus Westerlund wrote:
>Hi Mathew
>
>See below
>
>Rishi Mathew wrote:
>
>>Magnus/All,
>>This is regarding the Transport header defined in Chapter 14.43 of the 
>>RTSP spec. Right now, it says:
>>    The usage of any parameter that was not defined in RFC 2326 or in an
>>    extended way requires that request or response contains a Require
>>    header with the "play.basic" feature tag.
>
>What I refer to as parameter is the addition of what in the ABNF is called 
>parameter, i.e. what comes after the protocol specifier. For example a new 
>parameter would be the "new_parm" below:
>
>Transport: x-real-rdt/udp;client_port=6970;server_port=17738; new_parm=XYZ

Ok..

>>It is claimed that this was done to prevent backwards compatibility 
>>problems. However, in our field implementation, this parameter has always 
>>had a different value than what was defined in the original RTSP spec. It 
>>looks like this:
>>         Transport: x-real-rdt/udp;client_port=6970;server_port=17738\r\n
>>This was legal in the original spec. Obviously, any such stipulation is 
>>going to create more problems than it solves on the field. Our suggestion 
>>is that you remove this stipulation.
>
>"x-real-rdt/udp" is protocol specifier. However that you claim that it is 
>legal in RFC 2326 is not correct. The ABNF for the transport header looks 
>like this:
>
>    Transport           =    "Transport" ":"
>                             1\#transport-spec
>    transport-spec      =    transport-protocol/profile[/lower-transport]
>                             *parameter
>    transport-protocol  =    "RTP"
>    profile             =    "AVP"
>    lower-transport     =    "TCP" | "UDP"
>
>Which means that no extension allowance was made in the ABNF. Thus it is 
>unclear that a parser will correctly handle any extension. I do agree that 
>the intention was to allow for this. However due to the shortcoming of the 
>RFC 2326 it is a dangerous proposition to use extension protocol 
>specifiers or parameters. That is the reason the text is present in the draft.
>
>If you compare the above ABNF with the new one present in the draft:
>
>Transport       =  "Transport" ":" transport-spec
>                       *("," LWS transport-spec)
>    transport-spec  =  transport-id *parameter
>    transport-id    =  transport-prot "/" profile ["/" lower-transport]
>                       ; no LWS is allowed inside transport-id
>    transport-prot    =  "RTP" / token
>    profile           =  "AVP" / token
>    lower-transport   =  "TCP" / "UDP" / token
>
>You see that there now is specified that all these types can be extended.
>
>The draft do also define IANA registries for these points of extension, 
>see 20.5.
>
>So I don't think it is appropriate to remove this, as it can't be 
>guaranteed that your proprietary extensions would correctly work with 
>another implementation following RFC 2326. When clients support the 
>updated specification and indicates this correctly, then you can be 
>certain that any correct implementation can safely ignore your proprietary 
>transport protocol.
>
>So I think I will need to clarify the note to apply to any extensions. I 
>also should change the wording to not use the word "require". My proposed 
>change is:
>
>"The usage of any parameter or protocol specifier not defined in RFC 2326 
>or which is extended, SHALL be indicated by the use of the Require header 
>and a feature tag(s) to ensure support by the receiver. This
>is to protect against failures with uncertain consequences, as the a 
>receiver of a message may do anything between ignoring a parameter, to 
>complete refuse the message."
>
>Any Comments?

The current wording as I understand it, precludes efficient negotiation of 
transport.  For example, let's say that RDT is preferred, but RTP is
acceptable.   This would be expressed by the requestor as:

Transport: 
x-real-rdt/udp;client_port=6970;mode=play,RTP/AVP/UDP;client_port=6970;mode=play

In the (intended) RFC 2326 world, a server that doesn't understand RDT
would return:
Transport: RTP/AVP/UDP;client_port=6970;server_port=17738

However, in the current specification, this would result in another round 
trip, as the SETUP would fail and would need to
be reissued.  Worse, in many current RFC 2326 implementations, the 
connection would be torn down.

Dont you think it is worth REQUIRING new server implementations to ignore a 
particular transport and go on to the next one if there is something they 
cannot understand and parse?

Thanks,
Rishi.

>Cheers
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email-masked]

Rishi Mathew
Software Development Engineer
Helix Development Support Group
RealNetworks, Inc.
[email-masked]
206.892.6126
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Nov 2004 14:14:39 +0100

Hi Rishi,

Yes, you are right the mechanism to negotiate the transport protocol is
needed. See below proposal.

> cannot understand and parse?

Already today there is a sentence in the transport header section:

    Unknown transport parameters SHALL be ignored.

I would propose that one clarifies that this also applies to complete
transport specification, and especially the transport protocol
identifier. Thus one can include a list of potentially understood
transport specifications.

However it still leaves the problem of how one indicates that a
parameter within a specific transport spec must be understood. Maybe one
should create a new transport parameter that takes parameter names that
are mandatory for this specification to be understood. That way, one
can for each transport protocol define the parameters that must be
understood. If some special case requires extension parameters, or
normally optional parameters to be understood, then one includes the
parameter names in the mandatory parameter.

Example:

Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;spec_par="xyz";client_port=3456-3457;mode="PLAY";mand="spec_par"

Further suggestions or comments?

Cheers

Magnus Westerlund

---

From: Rishi Mathew <[email-masked]>
Date: Fri, 05 Nov 2004 13:04:12 -0800

Magnus,

Comments inline...

>RTP/AVP;unicast;spec_par="xyz";client_port=3456-3457;mode="PLAY";mand="spec_par"

This looks right... but does it mean that if there is a "MUST understand" 
parameter in a transport that I want to ignore, I have to send back an error?

For example,
Transport: 
x-real-rdt/udp;client_port=6970;mode=play;spec_par="xyz";mand="spec_par",RTP/AVP/UDP;client_port=6970;mode=play 

Lets assume a server does not understand RDT. Preferably, it should just 
ignore everything until the next "transport" and start from there. But, 
since there is a mandatory parameter in a transport that it does not 
understand, will it be forced to return an error?

>Further suggestions or comments?

I would also suggest that we modify the BNF to reflect the fact that the 
"profile" makes sense with RTP and not necessarily with other proprietary 
transport protocols.

Current syntax:

We could modify the BNF so that everything remains the same for RTP, but 
for other transport protocols, we could make the "profile" optional.

Proposed:
    transport-id    =  [ rtp-trans | other-trans ]
                       ; no LWS is allowed inside transport-id
    rtp-trans       =  "RTP" "/" profile ["/" lower-transport]
                       ; no LWS is allowed inside transport-id
    profile           =  "AVP" / token
    lower-transport   =  "TCP" / "UDP" / token

    other-trans     = token [ "/" token ]*

Cheers,
Rishi.

Rishi Mathew

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Nov 2004 22:48:54 +0100

>  >Further suggestions or comments?

Sean Sheedy made a very good suggestion to me in a hallway discussion. A 
simpler rule that makes this easier to handle would be to change the 
rule to:

A receiver MAY ignore any transport specification, but MUST understand 
all parameters within any specification it selects to use.

That way one has a very simple rule, and in cases where one has 
parameter that could be ignored, one can simply offer one transport spec 
with the parameter and another without. I don't think this will result 
in a huge number of specifications.

What do people think about it?

Cheers

Magnus Westerlund

---

From: Rishi Mathew <[email-masked]>
Date: Fri, 12 Nov 2004 16:47:56 -0800

Magnus,

Comments inline..

At 01:48 PM 11/10/2004, Magnus Westerlund wrote:
>simpler rule that makes this easier to handle would be to change the rule to:
>
>A receiver MAY ignore any transport specification, but MUST understand all 
>parameters within any specification it selects to use.
>
>That way one has a very simple rule, and in cases where one has parameter 
>that could be ignored, one can simply offer one transport spec with the 
>parameter and another without. I don't think this will result in a huge 
>number of specifications.
>

I think this is a good idea and simplifies the spec to a great extent.

Thanks,
Rishi.

Rishi Mathew