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

[Flemming Andreasen <[e-mail]>]

On 11/16/11 9:35 PM, Christer Holmberg wrote:
> Hi,
>
>    
>> 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
>> - Does not work without symmetric media/RTP (as more or less noted in the draft)
>> - 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.
>> - Given that shared transport addresses between different media streams is undefined in RFC 4566, the answerer may not support this to begin with
>>      
> That may of course be true, and in that case the answerer might reject the offer. However, I have been informed by a number of companies that their products will NOT have a problem with the fact that the remote end uses the same ports.
>
>    
>> - 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.
>> - 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.
>>
>> 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).
>>
>> 2) The intent of the draft is to effectively turn multiple media descriptions into a single RTP (or other media) session.
>>      
> It can be a single RTP session, or multiple RTP sessions. The draft suggests a default, but it can be extended also for other cases.
>
>
>    
>> 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).
>>      
> I agree, and that for sure is something we will have to work with before the spec is published as RFC. Section 6.4 (and 7.2) is intended to cover such text (there is already some text about the b= parameter, but more will be needed).
>
> However, I hope that not having all those details ready available at this point is a show stopper for starting the work.
>    
Agreed, however it may affect the nature of the solution and hence it 
would be good to understand more details around this before deciding 
which way to go. Taking capability negotiation as an alternative for 
example, you there have an explicit negotiation framework that could 
make it very explicit as to what you actually want to do depending on 
whether you end up doing the bundle or not in a given negotiation. The 
approach outlined here seems less clear (for the moment at least) and 
will require a bunch of new rules that may or may not generalize well 
among existing and future SDP extensions.

-- Flemming


>
> Regards,
>
> Christer
>
>
>
>