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

From: Flemming Andreasen <[email-masked]>
Date: Wed, 16 Nov 2011 21:07:34 -0500

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)

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Nov 2011 03:35:21 +0100

Hi, 

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

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 16 Nov 2011 22:32:15 -0500

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Nov 2011 09:34:28 +0100

Hi,

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

In my personal opinion (but, the WG of course decides :) I think it is quite clear and straight forward, and I don't see any major issues - eventhough I do agree that there are a number of things we need to specify. 

I do realize that there might be cases where an answerer, that does not support BUNDLE, will not accept an offer with identical port numbers. But, I have never seen such entity, and nobody has informed about such entities. That of course doesn't mean they don't exist, but my view is that it's not a big real-life problem.

Also, could you explain to me how all this would look using CapNeg, and how you would avoid the issues you've raised with BUNDLE?

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Nov 2011 16:43:51 +0800

Thanks for the review!

I may want to be a little more undiplomatic than Holmberg, however...

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

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

> media streams have already been established, and hence this is not 
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?
> 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.

> 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 

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?

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 17 Nov 2011 04:56:06 -0500

> In my personal opinion (but, the WG of course decides :) I think it is quite clear and straight forward, and I don't see any major issues - eventhough I do agree that there are a number of things w…
Ok - if it's clear and straight forward then it should be easy to write 
them up in the next version of the draft so we can see that.

> Also, could you explain to me how all this would look using CapNeg, and how you would avoid the issues you've raised with BUNDLE?
The backwards compatibility issue would be addressed by having the 
standard (non-bundle) configuration provided as the actual configuration 
(i.e. standard SDP) whereas the bundle configuration would be provided 
as a set of capabilities with a potential configuration for them. You 
may need to supplement that with one or more new attributes to specify 
bundle semantics, but those attributes could simply be provided as 
attribute capabilities that would be part of the potential (bundle) 
configuration.

As for rules around how to deal with various media-level parameters that 
you may or may not want depending on whether you end up doing the bundle 
or not, the potential configuration allows you to specify the exact set 
you want used for each configuration. It gets verbose quickly, but it's 
unambigious and well-defined at least.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 17 Nov 2011 05:19:48 -0500

On 11/17/11 3:43 AM, Harald Alvestrand wrote:
> 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.

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

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

>> streams is undefined in RFC 4566, the answerer may not support this 
>> to begin with
>

Effectively yes (theoretically, there could be an issue on the answerer 
processing such an offer in the first place).

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

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

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

>> 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).
>
> (a=rtpmap) values have to be unique across all the description pieces 
> of the RTP session, which naturally solves the problem for a=fmtp 
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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Nov 2011 18:46:05 +0800

On 11/17/2011 06:19 PM, Flemming Andreasen wrote:
>>> 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:
> 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.
It will work if the offerer is able to distinguish the two 5-tuples; 
since the answer came back without the BUNDLE extension, the offerer 
knows that there are multiple different RTP sessions.
> I'm simply saying this doesn't work in the presence of NATs (whether 
> ICE is used or not).
Yes, this language needs to be changed to clarify that "port information 
from the SDP answer" may refer to port information gathered via the ICE 
exchange rather than the (useless) information from the SDP m= line.

The language in question is in section 6.2:

    NOTE: Assuming symmetric media is used, the SDP Offerer can use the
    port information from the SDP Answer in order to create the 5-tuple
    mapping for each media.

> Effectively yes (theoretically, there could be an issue on the 
> answerer processing such an offer in the first place).
>
>>
> 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).
References? I'm quite aware of equipment that does classification on 
destination port numbers, but that's obviously not what you're thinking 
about.
>>> Fundamentally, we always have this backwards compatibility issue 
>>> when using grouping to try and negotiate something that has to be 
>>> suffer from these backwards compatibility issues (would still need 
>>> to define a capability negotiation extension for this though).
>>
> unknown attributes. If correct processing of those unknown attributes 
> is a prerequisite for correct operation you have a problem. The way 
In this case, we're dependent on a particular behaviour (5-tuple stream 
ID and symmetric RTP) that I believe is widely used outside of this 
standard, but that behaviour is not specified by any attribute I know of 
(RFC 4961 did not specify an SDP attribute).

The alternate from draft-alvestrand, different source ports, would 
present other problems (must spin up ports that are thrown away if not 
used). Would you see that as less problematic?
>>> 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).
>>
> 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.
Going through the list (or parts of it) might result in us concluding 
that there are only a few categories of handling possible, and that it's 
reasonable to require future extensions to fit within the categories. Or 
it might not.

Suggestions?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Nov 2011 12:28:58 +0100

Hi,

>> In my personal opinion (but, the WG of course decides :) I think it is quite clear and straight forward, and I 
>> don't see any major issues - eventhough I do agree that there are a number of things we need to specify.
>
> Ok - if it's clear and straight forward then it should be easy to write them up in the next version of the draft so we can see that.

I didn't mean that I have all the details in my head :)

What I meant was that it is clear WHAT we need to do, and we should do that as a community.

> unambigious and well-defined at least.

You still need to specify how the media level parameters will "interact" in a bundle - no matter whether you use CapNeg or not to negotiate the bundle.

In my opinion, the usage of CapNeg is "overkill" for this, as we're only talking about the port. And, as you said, we would still need to define new parameters for the bundle semantics. 

And, does the base CapNeg spec support providing alternative port numbers?

And, even if the answerer doesn't support bundle, maybe the offerer still wants to use the same local port.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 17 Nov 2011 06:37:35 -0500

On 11/17/11 5:46 AM, Harald Alvestrand wrote:
>>>> while the draft suggests some ways around that on the offering 
>>>> side, I don't believe they work. Problems include:
>>> session (or one RTP session per bundle). If the RTP implementation 
>>> is incompetent enough to put more than one media flow onto one SSRC 
Maybe so, but when those two RTP sessions have different payload type 
mappings for the same payload type numbers (as they most likely will) it 
gets ugly.

>>>> - 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.
>>>
>> 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).
> Yes, this language needs to be changed to clarify that "port 
> information from the SDP answer" may refer to port information 
> gathered via the ICE exchange rather than the (useless) information 
> from the SDP m= line.
>
>>> most commenters when they were both presented seemed to indicate 
>>> that draft-holmberg's solution did not present a problem.
>>>
>>>> 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.
> destination port numbers, but that's obviously not what you're 
> thinking about.
3GPP and PacketCable policy control.

>>
>>>> - 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?
>>> 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.
> In this case, we're dependent on a particular behaviour (5-tuple 
> stream ID and symmetric RTP) that I believe is widely used outside of 
> this standard, but that behaviour is not specified by any attribute I 
> know of (RFC 4961 did not specify an SDP attribute).
>
Yes - I believe it would resolve the backwards compatibility issues 
discussed so far.

>>>> 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 
>>> (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.
>>>
>> 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.
> that there are only a few categories of handling possible, and that 
> it's reasonable to require future extensions to fit within the 
> categories. Or it might not.
>
> Suggestions?
It can't hurt to take a look at that, although I prefer that each new 
extension is self-contained and hence doesn't require other (especially 
future) extensions to define how they work together (classic feature 
interaction issue).

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Nov 2011 13:00:45 +0100

Hi,

>> I believe this is true. It should be made even more explicit than it already is.

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.

> I'm simply saying this doesn't work in the presence of NATs (whether ICE

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

> that classify flows based on destination transport address alone (e.g.

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

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

> 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