Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Mar 2012 15:15:32 -0500

Christer -

One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from
using the same IP/port for media outside of BUNDLE (i.e. multiplexing)?

I'm wondering because I think BUNDLE will break if it talks to a non-BUNDLE
endpoint that is already doing multiplexing (of which we have found a few
examples); the BUNDLE endpoint won't be able to demux traffic by 5-tuple.

Thoughts?

--justin

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2012 11:11:21 +0100

Hi Justin,

As is indicated in the introduction section of the draft, the usage of the same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in order to allow it, an extension is needed - and BUNDLE is such extension :)

I am not sure I understand the break issue.

And, what do you mean by "non-BUNDLE endpoint that is already doing multiplexing"? Do you mean an endpoint that uses the same IP/port for multiple m- lines? If so, such endpoint breaks the SDP specification. BUT, even if such endpoints exist, I still don't understand how BUNDLE would break things.

Regards,

Christer

________________________________
From: Justin Uberti [[email-masked]]
Sent: Thursday, March 08, 2012 10:15 PM
To: [email-masked]
Cc: Christer Holmberg; Cullen Jennings
Subject: Re: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt

Christer -

One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from using the same IP/port for media outside of BUNDLE (i.e. multiplexing)?

I'm wondering because I think BUNDLE will break if it talks to a non-BUNDLE endpoint that is already doing multiplexing (of which we have found a few examples); the BUNDLE endpoint won't be able to demux traffic by 5-tuple.

Thoughts?

--justin

---

From: Justin Uberti <[email-masked]>
Date: Mon, 12 Mar 2012 12:58:42 -0400

On Mon, Mar 12, 2012 at 6:11 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Justin,
>
> As is indicated in the introduction section of the draft, the usage of the
> same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in
> order to allow it, an extension is needed - and BUNDLE is such extension :)
>

Right, but my question is whether it is forbidden, or merely unspecified.
Consider the case of a gateway, which predates BUNDLE and thinks it is
being clever by doing BUNDLE-type multiplexing (demuxing by remote address)
without signaling this in any way, other than the same port for each m=
line. This gateway would work with existing clients, but break when it
talks to a BUNDLE client, even though BUNDLE is not negotiated, since it
can't demux by remote address.

One reason for such gateways to exist would be to allow media to be sent to
a known "common" port, such as port 443.

> And, what do you mean by "non-BUNDLE endpoint that is already doing
> multiplexing"? Do you mean an endpoint that uses the same IP/port for
> multiple m- lines? If so, such endpoint breaks the SDP specification. BUT,
> even if such endpoints exist, I still don't understand how BUNDLE would
> break things.
>

Yes, an endpoint that uses the same IP/port for multiple m= lines.

> I'm wondering because I think BUNDLE will break if it talks to a
> non-BUNDLE endpoint that is already doing multiplexing (of which we have
> found a few examples); the BUNDLE endpoint won't be able to demux traffic
> by 5-tuple.
>
> Thoughts?
>
> --justin
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2012 19:33:11 +0100

Hi,

>> As is indicated in the introduction section of the draft, the usage of the same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in

I don't think it's forbidden, but as the semantics is undefined, it's not very useful.

RFC 4566 (SDP) says:

      "The semantics of multiple "m=" lines using the same transport
      address are undefined.  This implies that, unlike limited past
      practice, there is no implicit grouping defined by such means and
      an explicit grouping framework (for example, [18]) should instead
      be used to express the intended semantics."

So, I think it is very clear that an extension, which defines the semantics, is needed.
> Consider the case of a gateway, which predates BUNDLE and thinks it is being clever by doing BUNDLE-type
> multiplexing (demuxing by remote address) without signaling this in any way, other than the same port
> for each m= line. This gateway would work with existing clients,

...unless the clients will reject the SDP.

And, as we know from recent discussions, RTP multiplexing is not only about the port and address. It's about single vs multiple RTP sessions, how the multiplexing is implemented on the RTP level, etc etc etc. Without mechanisms to negotiate/indicate such things I am not sure how things would work.

> but break when it talks to a BUNDLE client, even  though BUNDLE is not negotiated, since it can't demux by remote address.
>
> One reason for such gateways to exist would be to allow media to be sent to a known "common" port, such as port 443.

Again, such gateways are not standards compliant, in my opinion.

Having said that, however, a BUNDLE implementation can always choose to accept the same address/port in the remote SDP even if BUNDLE is not indicated.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 12 Mar 2012 14:55:33 -0400

On Mon, Mar 12, 2012 at 2:33 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >> As is indicated in the introduction section of the draft, the usage of
> the same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in

In the course of our BUNDLE implementation, we (Google) noticed that we are
using these kinds of gateways, so this functionality is useful in at least
some situations. I suspect we are not the only ones to find it useful.

> So, I think it is very clear that an extension, which defines the

I am not questioning the usefulness of BUNDLE, which I think is very
important. But this edge case affects us, and it may affect other existing
applications or devices.

> being clever by doing BUNDLE-type
> And, as we know from recent discussions, RTP multiplexing is not only
> about the port and address. It's about single vs multiple RTP sessions, how
> the multiplexing is implemented on the RTP level, etc etc etc. Without
> mechanisms to negotiate/indicate such things I am not sure how things would
> work.
>

I agree, if both sides are muxing. If only one side is muxing (the case I
am referring to here), it is clear there are multiple RTP sessions, and
this can all be handled without knowledge of the RTP details.

>
> > but break when it talks to a BUNDLE client, even  though BUNDLE is not
> negotiated, since it can't demux by remote address.
> >
> > One reason for such gateways to exist would be to allow media to be sent
> to a known "common" port, such as port 443.
>

Perhaps, but they exist, at least to some extent. The question is, what can
we do about it? Ideally, BUNDLE would find some way to work even when
talking to something that is expecting different source ports.

>
> Having said that, however, a BUNDLE implementation can always choose to
> accept the same address/port in the remote SDP even if BUNDLE is not
> indicated.
>

This will not work since the gateway will not have provided the BUNDLE
implementation with the necessary SSRC information to demux, and it won't
understand the SSRC information the BUNDLE client sends to it.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2012 20:21:31 +0100

Hi,

> In the course of our BUNDLE implementation, we (Google) noticed that we are using these kinds of gateways, so this functionality 
> is useful in at least some situations. I suspect we are not the only ones to find it useful.
>
>> RFC 4566 (SDP) says:
>>
> I am not questioning the usefulness of BUNDLE, which I think is very important. But this edge 
> case affects us, and it may affect other existing applications or devices.
>
>> And, as we know from recent discussions, RTP multiplexing is not only about the port and address. It's about single vs multiple RTP sessions, how 
>> the multiplexing is implemented on the RTP level, etc etc etc. Without mechanisms to negotiate/indicate such things I am not sure how things 
>> would work.
>
> I agree, if both sides are muxing. If only one side is muxing (the case I am referring to here), it is clear there are multiple RTP sessions, and 
> Perhaps, but they exist, at least to some extent. The question is, what can we do about it? Ideally, BUNDLE would find some way to work even when talking to something that is expecting different source ports.
>
> This will not work since the gateway will not have provided the BUNDLE implementation with the necessary SSRC information to demux, and it won't 

So, the gateway wants to use the same local address/port, and  it *expects* the remote side to use separate address/ports, right?

If so, what do these gateways do if they still receive SDP with the same local address/port?

I guess we could always say that if a BUNDLE client *receives* a non-BUNDLE offer, but still with the same local address/port, it must reply with different address/ports - eventhough we normally don't specify procedures based on non-standard behaviors.

And, if a BUNDLE client *sends* a BUNDLE offer, I assume the gateway would reject it, and in that case I think the draft already says that the BUNDLE client should send a new non-BUNDLE offer.

Regards,

Christer

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 15:38:31 -0400

On 3/12/12 2:55 PM, Justin Uberti wrote:
>
>
> On Mon, Mar 12, 2012 at 2:33 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>      >> As is indicated in the introduction section of the draft, the
>     usage of the same IP/port for multiple m- lines is "unspecified" in
>     SDP. Therefor, in
> In the course of our BUNDLE implementation, we (Google) noticed that we
> are using these kinds of gateways, so this functionality is useful in at
> least some situations. I suspect we are not the only ones to find it useful.

Probably not.

But all all those currently using this undefined behavior using it in 
consistent ways?

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Mon, 12 Mar 2012 15:56:04 -0400

On Mon, Mar 12, 2012 at 3:21 PM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> >>>> As is indicated in the introduction section of the draft, the usage
> of the same IP/port for multiple m- lines is "unspecified" in SDP.
> Therefor, in
> are using these kinds of gateways, so this functionality
> important. But this edge
> mechanisms to negotiate/indicate such things I am not sure how things
> >> would work.
> >
> > I agree, if both sides are muxing. If only one side is muxing (the case
> I am referring to here), it is clear there are multiple RTP sessions, and
> > Perhaps, but they exist, at least to some extent. The question is, what
> can we do about it? Ideally, BUNDLE would find some way to work even when
> So, the gateway wants to use the same local address/port, and  it
> *expects* the remote side to use separate address/ports, right?
>

Yes, I believe it assumes this will be the case.

> If so, what do these gateways do if they still receive SDP with the same

I haven't tested yet, but I assume they end up picking one source address
and ignoring the traffic from the other one.

>
> I guess we could always say that if a BUNDLE client *receives* a
> non-BUNDLE offer, but still with the same local address/port, it must reply
> with different address/ports - eventhough we normally don't specify
> procedures based on non-standard behaviors.
>

OK.

>
> And, if a BUNDLE client *sends* a BUNDLE offer, I assume the gateway would
> reject it, and in that case I think the draft already says that the BUNDLE
> client should send a new non-BUNDLE offer.
>
>
It's not optimal, since it requires a new allocation of candidates, but I
think this would work for this scenario. This implies that WebRTC needs
some way to control local use of BUNDLE.

The same approach would also have to be used for another edge case where a
BUNDLE client communicates with a non-BUNDLE client that uses a TURN server
that demultiplexes off of a single port (e.g. 443).

Thanks,
--justin