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

[Flemming Andreasen <[e-mail]>]

On 11/17/11 5:46 AM, Harald Alvestrand wrote:
> 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.
Maybe so, but when those two RTP sessions have different payload type 
mappings for the same payload type numbers (as they most likely will) it 
gets ugly.


>>
>>>> - 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.
3GPP and PacketCable policy control.

>>
>>>> - 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?
>>
Yes - I believe it would resolve the backwards compatibility issues 
discussed so far.


>>
>>
>>>>
>>>>
>>>> 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?
It can't hurt to take a look at that, although I prefer that each new 
extension is self-contained and hence doesn't require other (especially 
future) extensions to define how they work together (classic feature 
interaction issue).

Thanks

-- Flemming

>
>