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

[Christer Holmberg <[e-mail]>]

Hi,

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

Are you saying that it would be TOO restrictive to assume symmetric RTP?

I think there are a number of other features that also assume symmetric RTP.

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

Maybe we need to fix the wording, and talk about the source address of the RTP packages.

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

If you have such procedures, won't that always cause issues when you have NATs? How is that specific to BUNDLE?

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

Sure, maybe there are entities that will reject the offer, but then I will claim that it is as likely (or, even more liekly) that there will be intermediaries that will have problems with CapNeg :)

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

I still don't understand how you would avoid having to do that with CapNeg.

Regards,

Christer