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

[Harald Alvestrand <[e-mail]>]

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

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

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?

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

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