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

[Flemming Andreasen <[e-mail]>]

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


Thanks

-- Flemming (as individual)