Subject: [rtcweb] FW: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Feb 2013 19:52:15 +0000

FYI,

Christer
________________________________________
From: [email-masked] [[email-masked]] on behalf of Christer Holmberg [[email-masked]]
Sent: Monday, 18 February 2013 9:50 PM
To: [email-masked]
Subject: [MMUSIC] Draft new version:    draft-ietf-mmusic-sdp-bundle-negotiation-03

Hi,

I've submitted a new version (-03) of BUNDLE.

Based on discussions with Cullen, and exchange of the concerns we had with the different port alternatives (different-ports vs identical-port), this version now describes a mechanism where both alternatives more or less are combined. When the first BUNDLE offer is sent, and it is now known whether the answerer supports BUNDLE (or, even identical ports), different ports are used (read: the one-rtp alterntaive). Once BUNDLE answer has been received, a new offer, with identical port numbers, is sent.

We think that having to send a second offer is not going to increase complexity and delay, because in many use-cases subsequent offer(s) will be sent anyway. For example, RTCWEB entities will do it because of ICE.

Cullen has also been added as co-author.

Now, we do realize that there are still issues that have to be described, and hopefully we will be able to focus on those from now on, but our wish is that this proposal will unite the different "port camps" :)

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Feb 2013 12:01:19 -0800

What are implications of this "new" approach on the SDP usage in the JSEP API, if any? 

For example: do we expect the SDP output by createOffer() to support this "different port" alternative by default? 

Also, overall is there a goal of "optimizing for the common case"?  

> From: [email-masked]
> To: [email-masked]
> Date: Mon, 18 Feb 2013 19:50:21 +0000

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Feb 2013 20:10:20 +0000

Hi,

>Also, overall is there a goal of "optimizing for the common case"?

Good questions, for which I don't have any answers at this point :)

But, IF we can agree on this as a way forward, one of the next steps is to look at the JSEP impacts.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Feb 2013 12:25:22 -0800

> But, IF we can agree on this as a way forward, one of the next steps is to look at the JSEP impacts.

[BA] The problem is that my opinion will differ depending on whether the SDP in question is to be used in the API or over the wire. 

The "different port" formulation makes good sense to me if you are looking for backward compatibility with existing SIP/SDP implementations which are likely to send an error in response to a "same port" formulation.   So if this is an "on the wire" question I give it a thumbs up. 

However, if you are asking me whether it makes sense for createOffer() to output SDP with different ports by default, when 99 percent of applications are likely to not be doing SIP interop, I would say "no".   Then the next question is whether there needs to be a mechanism in the API for indicating a preference for different ports, when this is desired.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Feb 2013 21:26:21 +0100

On 02/18/2013 09:01 PM, Bernard Aboba wrote:
> For example: do we expect the SDP output by createOffer() to support 
> this "different port" alternative by default?

If this ends up being the one alternative that people think is best, I 
think createOffer() should (of course) create that format by default.

> Also, overall is there a goal of "optimizing for the common case"?

I think the first focus is to have something that works; second focus is 
not failing in "interesting" ways in too many cases.

The browser-to-browser case should be able to send data after the first 
offer/answer, just as we do in the fastest proposals now. The second 
offer/answer to regularize port pairings shouldn't add time to the setup 
phase.

> > Subject: [MMUSIC] Draft new version: 
> draft-ietf-mmusic-sdp-bundle-negotiation-03
> >
> >
> > Hi,
> >
> > Based on discussions with Cullen, and exchange of the concerns we 
> had with the different port alternatives (different-ports vs 
> identical-port), this version now describes a mechanism where both 
> alternatives more or less are combined. When the first BUNDLE offer is 
> sent, and it is now known whether the answerer supports BUNDLE (or, 
> even identical ports), different ports are used (read: the one-rtp 
> alterntaive). Once BUNDLE answer has been received, a new offer, with 
> identical port numbers, is sent.
> >
> > We think that having to send a second offer is not going to increase 
> complexity and delay, because in many use-cases subsequent offer(s) 
> will be sent anyway. For example, RTCWEB entities will do it because 
> of ICE.
> >
> > Now, we do realize that there are still issues that have to be 
> described, and hopefully we will be able to focus on those from now 
> on, but our wish is that this proposal will unite the different "port 
> camps" :)
> >
> > Regards,
> >
> > Christer
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 19 Feb 2013 10:14:53 +0100

On 2013-02-18 21:25, Bernard Aboba wrote:
> [BA] The problem is that my opinion will differ depending on whether the
> SDP in question is to be used in the API or over the wire.
>
> The "different port" formulation makes good sense to me if you are
> looking for backward compatibility with existing SIP/SDP implementations
> which are likely to send an error in response to a "same port"
> formulation.   So if this is an "on the wire" question I give it a
> thumbs up.
>
> However, if you are asking me whether it makes sense for createOffer()
> to output SDP with different ports by default, when 99 percent of
> applications are likely to not be doing SIP interop, I would say "no".
> Then the next question is whether there needs to be a mechanism in the
> API for indicating a preference for different ports, when this is desired.

That sounds like a reasonable approach to me (and the default would be 
one port).

Stefan

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Feb 2013 11:48:42 +0000

Hi,

> [BA] The problem is that my opinion will differ depending on whether the SDP in question is to be used in the API or over the wire. 

True. But, if SDP is NOT used on the wire, the BUNDLE document does not put any requirements on whatever other signaling protocol you may be using. You can use a protocol that ONLY signals different port numbers, or one that ONLE signals identical port numbers, or one that ONLY signals a single port number, on the wire, and there is nothing BUNDLE can do about it :) 

BUNDLE is only about users of SDP Offer/Answer - no matter whether it's an API or a wire protocol.

>The "different port" formulation makes good sense to me if you are looking for backward compatibility with existing SIP/SDP implementations which are likely to send an error 
>in response to a "same port" formulation.   So if this is an "on the wire" question I give it a thumbs up. 
>
>However, if you are asking me whether it makes sense for createOffer() to output SDP with different ports by default, when 99 percent of applications are 
>likely to not be doing SIP interop, I would say "no".  Then the next question is whether there needs to be a mechanism in the API for indicating a preference for different ports, 
>when this is desired. 

That's a good discussion topic for JSEP :)

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Feb 2013 11:24:15 -0800

JSEP expects that most applications will send the same SDP to the API as is
sent over the wire.

Ideally, we would have a single offer-answer exchange, and the SDP created
by createOffer and fed to setLocalDescription would work properly
regardless of what is on the other side. If that's not possible, then we
will have some constraint that toggles between the 1) fast/not-legacy-safe
and 2) slow/legacy-safe output of createOffer. We will also have to decide
on what the default should be; based on the feedback from the most recent
SIPit, where most of the legacy equipment did not even support ICE, I am
leaning towards #1.

On Wed, Feb 20, 2013 at 3:48 AM, Christer Holmberg <
[email-masked]> wrote:

> True. But, if SDP is NOT used on the wire, the BUNDLE document does not
> put any requirements on whatever other signaling protocol you may be using.
> You can use a protocol that ONLY signals different port numbers, or one
> that ONLE signals identical port numbers, or one that ONLY signals a single
> port number, on the wire, and there is nothing BUNDLE can do about it :)
>
> which are likely to send an error
> >However, if you are asking me whether it makes sense for createOffer() to
> output SDP with different ports by default, when 99 percent of applications
> are
> >likely to not be doing SIP interop, I would say "no".  Then the next
> question is whether there needs to be a mechanism in the API for indicating
> a preference for different ports,
> >when this is desired.
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 22 Feb 2013 01:34:35 +0000

> What are implications of this "new" approach on the SDP usage in the JSEP API, if any? 

Assuming that the IETF can agree on a way to signal multiplexing (and I really like the current bundle draft), I am assuming that the JSEP draft will either say that browsers SHOULD or MUST implement that and the SDP created by create offer would be compliant with that. Having browsers multiplex the RTP is the whole thing driving this so I would be shocked to see us agree on how to do multiplexing then roughly the same set of people decide they did not really want to use it.