Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00

[Harald Alvestrand <[e-mail]>]

On 11/17/2011 06:19 PM, Flemming Andreasen wrote:
>
>
> On 11/17/11 3:43 AM, Harald Alvestrand wrote:
>> Thanks for the review!
>>
>> I may want to be a little more undiplomatic than Holmberg, however...
>>
>> On 11/17/2011 10:07 AM, Flemming Andreasen wrote:
>>> I have two major comments on the draft:
>>>
>>> 1) The draft says that it is backwards compatible, however I don't 
>>> believe it is. As the authors note, sharing tranxport addresses 
>>> among multiple media descriptions is undefined in RFC 4566, and 
>>> while the draft suggests some ways around that on the offering side, 
>>> I don't believe they work. Problems include:
>>> - Potential SSRC overlap between the different media streams, which 
>>> will lead to all kinds of problems
>> The result of successfully negotiating the extension will be one RTP 
>> session (or one RTP session per bundle). If the RTP implementation is 
>> incompetent enough to put more than one media flow onto one SSRC 
>> inside one RTP session, then it has much bigger problems than 
>> supporting the bundle.
> The issue here is when the answerer does not support the extension. 
> The answerer now believes there are multiple different RTP sessions 
> and hence may end up using the same SSRC, however this will not work 
> on the offering side.
It will work if the offerer is able to distinguish the two 5-tuples; 
since the answer came back without the BUNDLE extension, the offerer 
knows that there are multiple different RTP sessions.
>
>>> - Does not work without symmetric media/RTP (as more or less noted 
>>> in the draft)
>> I believe this is true. It should be made even more explicit than it 
>> already is.
>> Being a precondition for using it means that we don't have to deal 
>> with the non-symmetric-media situation; we simply can't use the 
>> extension under those conditions.
> Indeed, and hence it is not backwards compatible for those 
> implementations.
>
>> (This also means that the extension is useless for multicast. Not a 
>> problem.)
>>
>>> - Even when symmetric media/RTP is used, NAT implies that you cannot 
>>> use the port information from the SDP answer to infer the missing 
>>> parts of the 5-tuple.
>>
>> When NAT is used, ICE is required to get media flowing. This is 
>> something that is true for all SDP session negotiations; I do not 
>> believe it is in any way unique to this draft.
>>
> The draft says that "the SDP offerer can use the port information from 
> the SDP answer in order to create the 5-tuple mapping for each media". 
> I'm simply saying this doesn't work in the presence of NATs (whether 
> ICE is used or not).
Yes, this language needs to be changed to clarify that "port information 
from the SDP answer" may refer to port information gathered via the ICE 
exchange rather than the (useless) information from the SDP m= line.

The language in question is in section 6.2:

    NOTE: Assuming symmetric media is used, the SDP Offerer can use the
    port information from the SDP Answer in order to create the 5-tuple
    mapping for each media.


>
>
>>>
>>> - Given that shared transport addresses between different media 
>>> streams is undefined in RFC 4566, the answerer may not support this 
>>> to begin with
>>
>> You mean transport addresses on flows from the answerer to the offerer?
>
> Effectively yes (theoretically, there could be an issue on the 
> answerer processing such an offer in the first place).
>
>>
>> This is the piece that bothers me, and which was the main difference 
>> between draft-holmberg and draft-alvestrand-one-rtp-stream. However, 
>> most commenters when they were both presented seemed to indicate that 
>> draft-holmberg's solution did not present a problem.
>>
>>> - Shared destination transport addresses without full 5-tuple 
>>> information implies that you cannot identify each media stream as an 
>>> independent flow in the network, and the ability to do so may be one 
>>> reason the answerer did not want to do bundles to begin with.
>> I do not parse this sentence. Given that symmetric SDP is a 
>> requirement, the full 5-tuple is known by both sender and receiver. 
>> Most equipment that cares about flows works on 5-tuples rather than 
>> 3-tuples; are you suggesting that there exists flow-identifying 
>> equpment we care about where unique 3-tuples is a requirement for 
>> correct operation?
>>
> The full 5-tuple that the sender and receiver knows may not be the 
> same as the network sees due to NATs. There exists equipment and 
> standards that classify flows based on destination transport address 
> alone (e.g. for QoS operation).
References? I'm quite aware of equipment that does classification on 
destination port numbers, but that's obviously not what you're thinking 
about.
>
>>> - Fallback is to do another O/A exchange, however at that point, the 
>>> media streams have already been established, and hence this is not 
>>> backwards compatible.
>> Do you mean that doing two O/A exchanges is not backwards compatible, 
>> or that having some short period of media flow before the new O/A 
>> exchange can be performed is an issue?
> Both, however the issue is that the first O/A exchange may establish 
> media streams that do not function correctly. Furthermore, you cannot 
> always immediately start a second O/A exchange to rectify this (think 
> early media).
>
>
>>>
>>> Fundamentally, we always have this backwards compatibility issue 
>>> when using grouping to try and negotiate something that has to be 
>>> supported by the other side to avoid failures, and this is another 
>>> example of that. I will note that SDP Capability Negotiation is an 
>>> alternative solution to what you are trying to do and it would not 
>>> suffer from these backwards compatibility issues (would still need 
>>> to define a capability negotiation extension for this though).
>>
>> I did not see anything in RFC 5939 that would be helpful; I might not 
>> have read it closely enough.
>>
> The issue is that RFC 4566 (SDP) has a rule that says to simply ignore 
> unknown attributes. If correct processing of those unknown attributes 
> is a prerequisite for correct operation you have a problem. The way 
> grouping is used here you run into that per the above.
In this case, we're dependent on a particular behaviour (5-tuple stream 
ID and symmetric RTP) that I believe is widely used outside of this 
standard, but that behaviour is not specified by any attribute I know of 
(RFC 4961 did not specify an SDP attribute).

The alternate from draft-alvestrand, different source ports, would 
present other problems (must spin up ports that are thrown away if not 
used). Would you see that as less problematic?
>
>
>
>>>
>>>
>>> 2) The intent of the draft is to effectively turn multiple media 
>>> descriptions into a single RTP (or other media) session. We do 
>>> however have a number of SDP parameters (in RFC 4566 and extensions) 
>>> that are specified on a per media stream basis and we need some 
>>> general rules around how to deal with those. Section 7.2 begins to 
>>> look at it, but we need a lot more here, especially if we need to 
>>> support backwards compatibility at the same time in a single O/A 
>>> exchange. Some media description parameters will have to be 
>>> cumulative among the multiple "m=" lines (rtpmap for example), 
>>> others will have to pick a single one (e.g. SRTP keying parameters), 
>>> and yet others will need to be combined (bandwidth for example as 
>>> noted in the draft).
>>
>> This was also addressed a bit more explicitly in 
>> draft-alvestrand-one-rtp, but I have not yet seen a description of a 
>> parameter where the required rule is not obvious; payload types 
>> (a=rtpmap) values have to be unique across all the description pieces 
>> of the RTP session, which naturally solves the problem for a=fmtp 
>> parameters; bandwidth has already been discussed; a=label and SDES 
>> keying parameters only makes sense once for the session.
>>
>> Which other parameters are there where the answer is not obvious?
> Even reasonable people tend to differ on what is obvious, especially 
> once they start implementing things.  While we could go through the 
> entire list of SDP parameters defined to date and specify for each how 
> to handle it, how do you handle future SDP parameters ? It would be a 
> shame if this mechanism didn't work for any SDP extensions defined 
> after it and hence we need a general and interoperable solution to 
> this issue.
Going through the list (or parts of it) might result in us concluding 
that there are only a few categories of handling possible, and that it's 
reasonable to require future extensions to fit within the categories. Or 
it might not.

Suggestions?