Subject: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only)

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 14:06:43 +0000

Hi,

Within SDP Offers and Answers, BUNDLE (-04) does currently not allow usage of port zero in bundled m- lines.

However, due to the Berlin agreement to move forward with the UP (unified plan), we need to change that for SDP Offers, as port zero is used in bundled "bundle-only" m- lines.

Now, as the agreed context for the UP was WEBRTC only, we need to determine whether similar restrictions are needed in the generic BUNDLE spec. We also need to decide whether port zero is allowed for "bundle-only" m- lines only, or for any bundled m- line.

So, a couple of questions:

Q10: Assuming we define the SDP bundle-only attribute in the BUNDLE spec, do we need to limit the scope to WEBRTC (or whatever the scope also in the BUNDLE spec?

Q11: Do we, in SDP Offers, allow port zero ONLY in "bundle-only" m- lines, or in ANY bundled m- line (obviously, the semantics will vary)?

Note that the UP does NOT require bundled port zero m- lines in SDP Answers, and I am NOT suggesting a change to that.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 11:21:16 -0400

On Aug 5, 2013, at 10:06 AM, Christer Holmberg <[email-masked]> wrote:

> Now, as the agreed context for the UP was WEBRTC only, we need to determine whether similar restrictions are needed in the generic BUNDLE spec.

My understanding of the consensus call was that the UP as a single, collective whole was scoped for WebRTC for now.  That doesn't mean individual parts can't be generically applicable, nor that we can't decide all the parts could be generically applicable in the end.

> We also need to decide whether port zero is allowed for "bundle-only" m- lines only, or for any bundled m- line.

If the mechanism is backwards-compatible with not only existing RFCs, but also existing deployed systems, I can't see a reason not to make the mechanism generically applicable.  It was my understanding that the bundle-only port-0 concept requires and will always perform a second offer/answer round, with real port numbers.  Yes or no?

> Q11: Do we, in SDP Offers, allow port zero ONLY in "bundle-only" m- lines, or in ANY bundled m- line (obviously, the semantics will vary)?

If I understand it correctly, a "bundle-only" m-line is one that you only want to use if and only if the other end supports BUNDLE; a "bundled" m-line is one you want to use regardless of whether the far-end supports BUNDLE, but would want to bundle together if the far-end does support BUDNLE.  Correct?  If so, then let's call the "bundled" one a "bundle-up" for now, for "bundle upgrade".

If the above is correct, then ISTM the goal of a "bundle-up" m-line is (1) backwards compatibility, and (2) to successfully use the media stream regardless of the far-end's BUNDLE support.  For (1) I think it's safer not to use a port of 0.  For (2) I don't see a purpose in setting an m-line to port 0.  So why do it for bundle-up?

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Mon, 05 Aug 2013 10:31:13 -0500

On 8/5/13 10:21, Hadriel Kaplan wrote:
> It was my understanding that the bundle-only port-0 concept requires and will always perform a second offer/answer round, with real port numbers.  Yes or no?

The port-0 concept does *not* require a second exchange.

There are a lot of circumstances in which a second exchange is likely to 
take place (cf. "Handshaking"), but none of these are influenced one way 
or another by the use of zero-ports on bundle-only initial offers.

I presume you're concerned that the far end won't know which port to 
use? There's really not an issue here. These lines are interpreted by a 
bundle-aware implementation as having the same port number as the 
non-bundle-only lines that they're bundled together with. To be clear: 
you can't have a bundle that consists exclusively of bundle-only lines. 
At least one of them has to be non-bundle-only and have a real port 
number associated with it.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 11:39:48 -0400

On Aug 5, 2013, at 11:31 AM, Adam Roach <[email-masked]> wrote:

> There are a lot of circumstances in which a second exchange is likely to take place (cf. "Handshaking"), but none of these are influenced one way or another by the use of zero-ports on bundle-only initial offers.
> 
> I presume you're concerned that the far end won't know which port to use? There's really not an issue here. These lines are interpreted by a bundle-aware implementation as having the same port number as the non-bundle-only lines that they're bundled together with. To be clear: you can't have a bundle that consists exclusively of bundle-only lines. At least one of them has to be non-bundle-only and have a real port number associated with it.

No, I'm concerned with usages other than WebRTC.  The question was on whether the bundle-only port-0 thing should be generically applicable, or scoped to WebRTC.  So I'm thinking of what its impact is on SIP usage in the real world, including on things that go bump in the night.  All kinds of crap happens in the middle these days in SIP networks. (and no, not only with SBCs)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Mon, 05 Aug 2013 10:59:36 -0500

On 8/5/13 10:39, Hadriel Kaplan wrote:
> No, I'm concerned with usages other than WebRTC. The question was on 
> whether the bundle-only port-0 thing should be generically applicable, 
> or scoped to WebRTC. So I'm thinking of what its impact is on SIP 
> usage in the real world, including on things that go bump in the 
> night. All kinds of crap happens in the middle these days in SIP 
> networks. (and no, not only with SBCs)

I don't think I'd expect bundle-only lines to work through 
extra-specification bumps in the wire. If the bumps are upgraded to work 
with bundle, great, but I know that this won't happen overnight (and, 
for many corners of the network, ever). But given that these bumps in 
some sense serve as the "other end" of the connection, a failure to get 
bundle-only lines through them is merely the design working per its 
requirements.

Remember, we're designing these lines to be fragile on purpose. That's 
the whole point of using a zero port: if we don't have end-to-end 
understanding of bundle-only, we need them to break.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 16:48:19 +0000

Hi,

As Adam indicated, the need to send a second offer isn't introduced by port zero. Currently the second offer is always sent after the initial offer (some comments were raised regarding that, but it is a separate discussion).

Having said that, if a second offer IS sent (for whatever reason), I assume that the actual bundle port value would be assigned also to the bundle-only m- lines (assuming the answerer supports bundle-only, that is)?

Regards,

Christer

-----Original Message-----
From: Adam Roach [[email-masked]]
To: Hadriel Kaplan [[email-masked]]
CC: Christer Holmberg [[email-masked]]; mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only)

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 12:48:41 -0400

On Aug 5, 2013, at 11:59 AM, Adam Roach <[email-masked]> wrote:

> I don't think I'd expect bundle-only lines to work through extra-specification bumps in the wire. If the bumps are upgraded to work with bundle, great, but I know that this won't happen overnight (and, for many corners of the network, ever). But given that these bumps in some sense serve as the "other end" of the connection, a failure to get bundle-only lines through them is merely the design working per its requirements.
> 
> Remember, we're designing these lines to be fragile on purpose. That's the whole point of using a zero port: if we don't have end-to-end understanding of bundle-only, we need them to break.

Sure, but the problem I'm worried about is when they break in weird ways - like they fail in the answer phase rather than offer phase; or they appear to succeed in SDP, but there's no media; or not enough bandwidth is allocated in controlled pipes; or the call gets torn down some time later by those bumps-in-the-wire.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 17:05:20 +0000

In SIP, unless you have control of each node between the endpoints, the only way to guarantee a "consistent break" is by using Proxy-Require.
But, as we know, that sucks, because it would mandate entities that could not care less about SDP (yes, such entities DO still exist :) to support bundle-only.

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Adam Roach [[email-masked]]
CC: mmusic (E-mail) [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only)

-hadriel

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 17:49:12 +0200

I don't really understand the "only for WebRTC" agreement.
I do see how defining extensions to O/A might be done only for WebRTC 
and not for 3264. (I don't *agree*, but I do *understand* that.)

But BUNDLE is a change to SDP, and SDP extensions are required to 
specify how they interact with O/A. I don't think it makes any sense to 
say that such changes only apply to WebRTC. They should apply to 
anything that chooses to claim support to the BUNDLE draft.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2013 15:59:32 +0000

Hi Paul,

Personally, I intend to focus mainly on the technical parts - others will then have to tell me what/how to write in order to scope some feature, if needed :)

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only)

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 22:55:35 -0400

> But, as we know, that sucks, because it would mandate entities that could not care less about SDP (yes, such entities DO still exist :) to support bundle-only.

Technically, I think you'd have to put something in both Proxy-Require and Require.  But that would make it virtually DOA, from a practical perspective.  It would fail constantly.  I realize that's kinda the point, to fail early, but failing all the time probably isn't the point.

The other challenge is it's not just about SBCs, B2BUAs, app servers, etc.  It's also about the lovely "ALGs" in NATs, CGNs, and Firewalls, and the passive inspecting things made by certain popular router vendors - you know, all the things that ostensibly prevented us from adding two bytes for an RTP shim header to mux/demux, even though somehow we can now add more bytes as RTP extension headers instead - those things don't understand or involve themselves with Proxy-Require/Require, as far as I can tell.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 13:52:40 -0400

On Aug 6, 2013, at 11:49 AM, Paul Kyzivat <[email-masked]> wrote:

> I do see how defining extensions to O/A might be done only for WebRTC and not for 3264. (I don't *agree*, but I do *understand* that.)
> 
> But BUNDLE is a change to SDP, and SDP extensions are required to specify how they interact with O/A.

Is that actually true?  I don't see that requirement in RFC 4566 IANA registration procedures, nor in IANA's SDP parameters registry.

> I don't think it makes any sense to say that such changes only apply to WebRTC. They should apply to anything that chooses to claim support to the BUNDLE draft.

OK, but in a SIP-based usage, I think it's dangerous to offer port=0 media lines and negotiate to use those media lines with the far end due to an answer containing a new bundle attribute, without sending another offer indicating you're using those media lines.

So I think if we want to use BUNDLE in SIP as well, we should really require it to do another offer/answer round.  In a WebRTC usage (ie, in Javascript API and JSEP), it can avoid the second round.

One way to describe this in a BUNDLE RFC, I think, is to say it MUST do another offer/answer exchange, except when used in [draft-jsep] or as an application programming interface. (or something like that)

-hadriel

---

From: Mary Barnes <[email-masked]>
Date: Wed, 7 Aug 2013 13:02:00 -0500

On Wed, Aug 7, 2013 at 12:52 PM, Hadriel Kaplan
<[email-masked]>wrote:

> specify how they interact with O/A.
>
> Is that actually true?  I don't see that requirement in RFC 4566 IANA
> registration procedures, nor in IANA's SDP parameters registry.
>
>
> > I don't think it makes any sense to say that such changes only apply to
> WebRTC. They should apply to anything that chooses to claim support to the
> BUNDLE draft.
>
> OK, but in a SIP-based usage, I think it's dangerous to offer port=0 media
> lines and negotiate to use those media lines with the far end due to an
> answer containing a new bundle attribute, without sending another offer
> indicating you're using those media lines.
>
> So I think if we want to use BUNDLE in SIP as well, we should really
> require it to do another offer/answer round.  In a WebRTC usage (ie, in
> Javascript API and JSEP), it can avoid the second round.
>
> One way to describe this in a BUNDLE RFC, I think, is to say it MUST do
> another offer/answer exchange, except when used in [draft-jsep] or as an
> application programming interface. (or something like that)
>
[MB] Exactly.  I think it's extremely important that the different usages
of BUNDLE/SDP are clearly delineated.  I think that's one of the reasons we
have gotten so bogged down with this whole topic.  There's no one to have a
one size fits all solution give the disparity in the usages. [/MB]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 18:05:21 +0000

Hi,

> OK, but in a SIP-based usage, I think it's dangerous to offer port=0 media lines and negotiate to use those media lines with the far end due to an answer containing a new bundle attribute, without…

You have to send an offer which indicates the port you are going to use. Sometimes that will be a "second offer" (because the "first offer" contained different ports).

> So I think if we want to use BUNDLE in SIP as well, we should really require it to do another offer/answer round.  In a WebRTC usage (ie, in Javascript API and JSEP), it can avoid the second round.

BUNDLE as such *CAN* be used with SIP. The question is whether specific parts, e.g. the SDP bundle-only attribute, needs to be scoped to "WebRTC only".

> One way to describe this in a BUNDLE RFC, I think, is to say it MUST do another offer/answer exchange, except when used in [draft-jsep] or as an application programming interface. (or something lik…

The draft already says that a second offer/answer must be sent, if the previous one did not contain the port values that are going to be used.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 14:17:03 -0400

> The draft already says that a second offer/answer must be sent, if the previous one did not contain the port values that are going to be used.

This is challenging to discuss because as far as I'm aware, the UP plan will make changes to the BUDNLE draft.  Correct?  If so, saying "but it already says X" doesn't give me the warm-fuzzies.

I believe (but could easily be wrong) the new UP plan would not require a second O/A.  Or at least that's what I interpreted Adam's email to mean here:
http://www.ietf.org/mail-archive/web/mmusic/current/msg12030.html

If I misunderstood his email, I apologize.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 18:28:34 +0000

Hi,

> If I misunderstood his email, I apologize.

You probably understood correct. Now, when I re-read it, I remembered that I didn't agree :) My opinion is that a second offer is always needed if the previous offer did not contain the port values that you are actually going to end up using.

So, if the first offer contains bundle-only/port=0, and the receiver accepts it, the second offer would contain bundle-only/port=bundle_port.

But, obviously this is something that we'll have to discuss as part of the adding-UP-to-BUNDLE procedure.

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 8 Aug 2013 03:20:23 +0530

Hi all,

It is a concern area for UP plan in case it works only for WebRTC and not
for SIP/general. The changing current BUNDLE approach breaks interop with
SIP/legacy endpoints. 

Thanks
Partha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Wednesday, August 07, 2013 11:47 PM
> To: Christer Holmberg
> Cc: [email-masked] (E-mail)
> Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero
> usage in bundled m- lines (SDP Offers only)
> 
> 
> >> One way to describe this in a BUNDLE RFC, I think, is to say it MUST
> do another offer/answer exchange, except when used in [draft-jsep] or
> as an application programming interface. (or something like that)
> >
> > The draft already says that a second offer/answer must be sent, if
> the previous one did not contain the port values that are going to be
> used.
> 
> This is challenging to discuss because as far as I'm aware, the UP plan
> will make changes to the BUDNLE draft.  Correct?  If so, saying "but it
> already says X" doesn't give me the warm-fuzzies.
> 
> I believe (but could easily be wrong) the new UP plan would not require
> a second O/A.  Or at least that's what I interpreted Adam's email to
> mean here:

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 23:02:45 +0000

> for SIP/general. The changing current BUNDLE approach breaks interop with

I disagree. The whole point was to make it work and I believe it does with the stuff I have tested.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 01:39:40 +0200

> Is that actually true?  I don't see that requirement in RFC 4566 IANA registration procedures, nor in IANA's SDP parameters registry.

I don't know if it is written anywhere or not, but as a member of the 
SDP directorate *I* assume that SDP extensions need to discuss the O/A 
impact. Even before the SDP directorate we have been bugging authors 
about that.

Sometimes that impact may be *none*. I suppose it is conceivable that 
there would be an SDP extension that isn't intended to be used in any 
O/A context. But if that is the case, then I would expect *that* to be 
specified.

	Thanks,
	Paul