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

[Flemming Andreasen <[e-mail]>]

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.

>> - 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).


>>
>> - 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).

>> - 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.



>>
>>
>> 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.

Thanks

-- Flemming



>
>