Subject: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 06:18:46 +0000

Hi,

As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it.

So, based on that assumption, my question is: why do we need port 0? Why not assign the suggested bundle port to the bundle-only m- lines from the beginning? As the bundle port is anyway going to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for bundle-only m- lines.

Regards,

Christer

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 08:21:14 -0400

If I understand your question, you're asking why bundle-only m-lines would use a port number of 0 in the offer, instead of using the same port number as the regular bundle m-line they're going to transport-bundle with?

I believe the rationale was basically argued about before, either in IETF 86 Orlando or IETF 85 Atlanta.  It gets back to the original debate about whether a BUNDLE offer should use the same port numbers or different ones, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctly).

One WG participant argued against using the same port numbers for bundle lines.  His argument was that since it was never described in an RFC, and he knew of one implementation that didn't handle it well, that therefore we couldn't send an offer using the same port numbers until we found out if the far-end supported BUNDLE or not.

That's what drove the decision to use different port numbers even in regular bundle cases, afaik.

Therefore, even for bundle-only lines, we can't use the same non-0 port number for them, because the same theoretical issue will exist.

Also, from a purely protocol perspective, it seems quite logical to me to use a port number of 0 for an m-line you literally don't want to use if the far-end doesn't support BUNDLE - a port number of 0 effectively means "disabled" today, and that's basically what you want.  What I don't think is right, is (1) having the far-end send an SDP answer back that sets a real port number for those same "disabled" m-lines, and (2) not requiring another offer/answer exchange that then uses the correct (same) port numbers for the previously-disabled m-lines.

What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines, and the UAC should then send a new offer with those m-lines having the real port number of the bundle transport, and the far-end should answer that in the same fashion.

-hadriel

On Aug 8, 2013, at 2:18 AM, Christer Holmberg <[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 13:04:28 +0000

Hi,

> If I understand your question, you're asking why bundle-only m-lines would use a port number of 0 in the offer, instead of using the same port number as the regular bundle m-line they're going to t…

Yes.

> I believe the rationale was basically argued about before, either in IETF 86 Orlando or IETF 85 Atlanta.  It gets back to the original debate about whether a BUNDLE offer should 
> use the same port numbers or different ones, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctly).
>
> One WG participant argued against using the same port numbers for bundle lines.  His argument was that since it was never described in an RFC, and he knew of one implementation 
> that didn't handle it well, that therefore we couldn't send an offer using the same port numbers until we found out if the far-end supported BUNDLE or not.
>

Correct. 

Another advantage of using different port numbers is that it provides a fallback in case the remote endpoint does not support, or does not want to use BUNDLE.

However, for bundle-only m- lines such fallback is not needed - they are ONLY going to be used IF the remote endpoint chooses to use BUNDLE.

...and, based on the agreed scope, the Offerer KNOWS that the remote endpoint supports BUNDLE, so the "one implementation that doesn't handle it" will not be there :) 

> Therefore, even for bundle-only lines, we can't use the same non-0 port number for them, because the same theoretical issue will exist.

Well, I think there will be some cases where we will have to allow the same port number. Bundle-only is one case, trickle ICE another (where one can assign port 9 for multiple m- lines).

> Also, from a purely protocol perspective, it seems quite logical to me to use a port number of 0 for an m-line you literally don't want to use if the far-end doesn't support 
> BUNDLE - a port number of 0 effectively means "disabled" today, and that's basically what you want.  

Well, one could also say that it means "Here are some m- lines  I want to bundle, with this port, but only if you (the remote endpoint) wants to use bundle." :)

> What I don't think is right, is (1) having the far-end send an SDP answer back that sets a real port number for those same "disabled" m-lines, and (2) not requiring 
> another offer/answer exchange that then uses the correct (same) port numbers for the previously-disabled m-lines.

So far I agree with you on this one :)

> What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines, and the UAC should then send a new offer with those m-lines having the real port number of the b…

The problem is that the grouping framework does not allow, in SDP Answers, usage of port=0 in grouped m- lines. It would require an update of the RFC, and I think we want to avoid that.

Also, if the Answerer chooses to use BUNDLE, as it DOES include its bundle port for all other m- lines, I think it should also do it for the bundle-only m- lines.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 10:15:45 -0400

> Another advantage of using different port numbers is that it provides a fallback in case the remote endpoint does not support, or does not want to use BUNDLE.

Yes, except as far as I can tell all devices (and even intermediaries) handle an offer with the same port number just fine.  But that's just a personal observation, and dangerous to assume ALL of them handle it fine; that's why I didn't argue for long that we should use the same port number in the offer - because it concerned me that someone knew of at least one implementation that didn't handle it well. (not that we can truly accommodate ALL implementations anyway, but it's got to be a heck of a lot higher than simple majority, and as close to 100% as we can get)

> ...and, based on the agreed scope, the Offerer KNOWS that the remote endpoint supports BUNDLE, so the "one implementation that doesn't handle it" will not be there :) 

For WebRTC sure - but we were talking about using BUNDLE generically.  Or at least that's what I thought you were asking about.  If we're only talking about using BUNDLE for WebRTC, then not only do you not need to use a port=0, but you also don't need a second offer/answer, etc.

> Well, one could also say that it means "Here are some m- lines  I want to bundle, with this port, but only if you (the remote endpoint) wants to use bundle." :)

We can certainly change the semantics of SDP offers with port=0 for WebRTC, but I think it would be really dangerous to change its semantics for general use.

> The problem is that the grouping framework does not allow, in SDP Answers, usage of port=0 in grouped m- lines. It would require an update of the RFC, and I think we want to avoid that.

Considering the number of docs the Unified-Plan proposes to either create, change, update or whatever... methinks having BUNDLE update the grouping framework RFC is rather a minor nit. :)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 12:11:59 -0500

On 8/8/13 01:18, Christer Holmberg wrote:
> As has been indicated, bundle-only can only be used when one knows 
> that the receiver, and possible intermediaries etc, support it.

That's not quite right.

Bundle-only can be sent in any offer. Even if you don't know anything 
about the remote endpoint or other devices along the path.

The bundle-only lines are designed to succeed only when the remote 
endpoint supports bundle. They are designed to fail in a very graceful, 
predictable, backwards-compatible, and well-defined way under other 
circumstances.

> So, based on that assumption, my question is: why do we need port 0? 
> Why not assign the suggested bundle port to the bundle-only m- lines 
> from the beginning? As the bundle port is anyway going to be used 
> (even if the receiver does not want to use bundle), there is no need 
> to reserve additional ports for bundle-only m- lines.

The point of the port-0 mechanism is that it will cause that m-line line 
to fail if you hit a non-bundle endpoint. If we put a valid port there 
that matches other m-lines, then legacy implementations behave in odd, 
unpredictable, and (most importantly) widely varying ways. The reaction 
to port 0 is better defined, and more consistent.

/a

---

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

Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more than
one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile networks.
So, I don't agree with Hadriel claim of 99% system works with same port. The
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before sending
offer, it is fine to send the same port in the offer using bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-
> only m- lines?
> 
> 
> > Another advantage of using different port numbers is that it provides
> a fallback in case the remote endpoint does not support, or does not
> want to use BUNDLE.
> 
> Yes, except as far as I can tell all devices (and even intermediaries)
> handle an offer with the same port number just fine.  But that's just a
> personal observation, and dangerous to assume ALL of them handle it
> fine; that's why I didn't argue for long that we should use the same
> port number in the offer - because it concerned me that someone knew of
> at least one implementation that didn't handle it well. (not that we
> can truly accommodate ALL implementations anyway, but it's got to be a
> heck of a lot higher than simple majority, and as close to 100% as we
> can get)
> 
> 
> > However, for bundle-only m- lines such fallback is not needed - they
> are ONLY going to be used IF the remote endpoint chooses to use BUNDLE.
> > ...and, based on the agreed scope, the Offerer KNOWS that the remote
> endpoint supports BUNDLE, so the "one implementation that doesn't
> handle it" will not be there :)
> 
> For WebRTC sure - but we were talking about using BUNDLE generically.
> Or at least that's what I thought you were asking about.  If we're only
> talking about using BUNDLE for WebRTC, then not only do you not need to
> use a port=0, but you also don't need a second offer/answer, etc.
> 
> 
> >> Also, from a purely protocol perspective, it seems quite logical to
> me to use a port number of 0 for an m-line you literally don't want to
> use if the far-end doesn't support
> > Well, one could also say that it means "Here are some m- lines  I
> want to bundle, with this port, but only if you (the remote endpoint)
> wants to use bundle." :)
> 
> We can certainly change the semantics of SDP offers with port=0 for
> WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
> 
> 
> >> What I think should happen is the UAS should send an SDP answer
> using port=0 for those same m-lines, and the UAC should then send a new
> offer with those m-lines having the real port number of the bundle
> transport, and the far-end should answer that in the same fashion.
> >
> > The problem is that the grouping framework does not allow, in SDP
> Answers, usage of port=0 in grouped m- lines. It would require an
> update of the RFC, and I think we want to avoid that.
> 
> Considering the number of docs the Unified-Plan proposes to either
> create, change, update or whatever... methinks having BUNDLE update the
> grouping framework RFC is rather a minor nit. :)
> 
> -hadriel
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 12:39:51 -0500

On 8/8/13 07:21, Hadriel Kaplan wrote:
> What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines

Why? You're proposing that we remove the mechanism for rejecting media 
streams. Consider the example I put up during the meeting: you have a 
regular audio m-line and a bundle-only video m-line. The other end wants 
to decline the video. You've just taken away the tool for doing so.

There'd better be a heck of an upside to removing this critical protocol 
mechanism. So far, the upside you've described is "Hadriel thinks it's 
not aesthetically pleasing," which doesn't seem to be a very practical 
consideration. Is there a technically compelling argument for your position?

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 18:19:15 +0000

Hi,

Some people suggested that it should be allowed to send the same ports in the first offer, IF it is known that the answerer supports BUNDLE.

However, that is currently not described in the draft, and there were also objections to such approach.

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: &apos;Hadriel Kaplan&apos; [[email-masked]]; Christer Holmberg [[email-masked]]
CC: &apos;mmusic&apos; [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?
Hi Hadriel/Christer,

Thanks
Partha

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 14:21:51 -0400

On Aug 8, 2013, at 1:39 PM, Adam Roach <[email-masked]> wrote:

> Why? You're proposing that we remove the mechanism for rejecting media streams. Consider the example I put up during the meeting: you have a regular audio m-line and a bundle-only video m-line. The other end wants to decline the video. You've just taken away the tool for doing so.
> 
> There'd better be a heck of an upside to removing this critical protocol mechanism. So far, the upside you've described is "Hadriel thinks it's not aesthetically pleasing," which doesn't seem to be a very practical consideration. Is there a technically compelling argument for your position?

Huh?  You either misunderstood my email, or I'm not following your statement above.  I don't believe I'm proposing we remove the mechanism of rejecting media streams.  How/where/when did I propose that?  You lost me.

And I don't think what I'm suggesting is to be "aesthetically pleasing" either... although SDP-based ascii art might be kinda cool.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 18:24:02 +0000

Hi,

I agree with Adam on this one. Port zero is used in answers to reject a stream, and I don't think we should change that.

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 goes UP: Do we need port zero for bundle-only m- lines?

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 18:32:48 +0000

Hi Adam,

Ok, so if we make no assumptions about the receiver, I understand the reasoning for port zero.

However, even if both endpoints support bundle-only, what if there are intermediaries that don't? They may pass the SDP, but unless you send a second offer, with the bundle port, I doubt they will forward any media associated with the bundle-only m- lines towards the Offerer, as they only see a port zero value.

Or, do you assume that intermediaries that don't support bundle-only will reject the first offer?

Regards,

Christer

-----Original Message-----
From: Adam Roach [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

That's not quite right.

Bundle-only can be sent in any offer. Even if you don't know anything about the remote endpoint or other devices along the path.

The bundle-only lines are designed to succeed only when the remote endpoint supports bundle. They are designed to fail in a very graceful, predictable, backwards-compatible, and well-defined way under other circumstances.

The point of the port-0 mechanism is that it will cause that m-line line to fail if you hit a non-bundle endpoint. If we put a valid port there that matches other m-lines, then legacy implementations behave in odd, unpredictable, and (most importantly) widely varying ways. The reaction to port 0 is better defined, and more consistent.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 18:40:56 +0000

Hi Hadriel,

My opinion is also that intermediaries will handle offers with the same port value. But, there were other opinions, so we agreed on the two-O/A mechanism.

Regarding the modified semantics of port zero in bundle-only m- lines, if we want to change the semantics only for WebRTC, it means we can only allow bundle-only for WebRTC. Because, I don't think we want to have different semantics for port zero bundle-only m- lines depending on whether they are used in WebRTC or not...

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 14:42:36 -0400

> indicates one of the possible interop issue with existing mobile networks.

I've only skimmed the draft, but I don't see the problem.  I know there's an issue with multiplexing all the RTP on one 5-tuple, but that's actually an orthogonal issue.  I was talking about whether an SDP offer with multiple m-lines using the same port number would have issues or not.  Am I missing something in the draft?

> current BUNDLE draft mechanism interop in the better way.

Please don't misrepresent what I said - I think if you read my paragraph, it's pretty clear I am not claiming 99% of them work with the same port; nor am I suggesting we go back to using the same port again.  It was in the context of the debates we had back when the issue was debated a couple IETF meetings ago, and I said as far as I knew they can handle an *SDP offer* with it... and I then *immediately* said I didn't argue it for long, because someone else stated they knew of a device which had a problem, and that concerned me.  Since most people generally try not to contradict themselves in the span of a dozen words, I think it's reasonable to assume I no longer believe all devices work.  I mean I may not be smart, but I'm not a complete idiot. (well... not generally an idiot anyway)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 18:45:26 +0000

When both Hadriel and Adam think pot zero in bundle-only m- lines is good, I'll rest my case :)

However, I do still think we need the second offer also for bundle-only m- lines.

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

On Aug 8, 2013, at 2:18 AM, Christer Holmberg <[email-masked]> wrote:

> Sent from Windows using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 13:53:30 -0500

On 8/8/13 13:21, Hadriel Kaplan wrote:
>> Why? You're proposing that we remove the mechanism for rejecting media streams.

You're proposing that "the UAS should send an SDP answer using port=0 
for [bundle-only] m-lines", even if it wants to accept those m-lines. In 
other words:

  * If the answerer wants to accept the m-lines, it does so by setting
    the port to 0
  * If the answerer wants to reject the m-lines, it does so by setting
    the port to 0

I'm having a hard time understanding how the recipient of the answer 
distinguishes between port=0 and port=0.

/a

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 9 Aug 2013 00:26:29 +0530

Hi Christer,

Thanks for the clarification that it is a new requirement for BUNDLE.

In case it should be allowed to send the BUNDLE in the first offer, the
mechanism for understanding answerer support for BUNDLE has to be
standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities).

Thanks

Partha 

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, August 08, 2013 11:49 PM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

Hi,

Some people suggested that it should be allowed to send the same ports in
the first offer, IF it is known that the answerer supports BUNDLE.

However, that is currently not described in the draft, and there were also
objections to such approach.

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: &apos;Hadriel Kaplan&apos; [[email-masked]]; Christer
Holmberg [[email-masked]]
CC: &apos;mmusic&apos; [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

Hi Hadriel/Christer,

Thanks
Partha

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 14:58:47 -0400

> I agree with Adam on this one. Port zero is used in answers to reject a stream, and I don't think we should change that. 

Ahhh - now I think I understand what Adam's angst was. (maybe)  You're thinking that if the UAS' answer keeps the port=0, then that contradicts using port=0 meaning it was rejected?

Well, hate to tell y'all, but a port number of zero means that in the offer TOO.

From RFC 3264:
   A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.

What I'm proposing is we don't break/change that whatsoever.  We have the UAC send port=0 and "a=bundle-only" in the Offer, and UAS send an SDP answer with port=0 too, and ALSO "a=bundle-only" for the m-lines it is ok with using.  Or "a=bundle-only:use" or whatever.  The UAC sees that in the answer, and can send a new Offer with the bundle port number, likewise the UAS in its answer.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 15:00:38 -0400

On Aug 8, 2013, at 2:53 PM, Adam Roach <[email-masked]> wrote:

> You're proposing that "the UAS should send an SDP answer using port=0 for [bundle-only] m-lines", even if it wants to accept those m-lines. In other words:
> 
> 	• If the answerer wants to accept the m-lines, it does so by setting the port to 0
> 	• If the answerer wants to reject the m-lines, it does so by setting the port to 0
> 
> I'm having a hard time understanding how the recipient of the answer distinguishes between port=0 and port=0.
> /a

Sorry, yeah I figured out what you meant a few minutes later after reading Christer's email.  I just responded to that in my reply to him.

-hadriel
p.s. isn't email a fun medium for real-time chat?  :)

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 19:00:59 +0000

Hi,

I don't think the answerer needs a feature tag to indicate BUNDLE support. If it doesn't support BUNDLE, it won't include the BUNDLE group in the answer, nor will it assign a single port value to multiple m- lines.

Or, did I misunderstand your issue?

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: Christer Holmberg [[email-masked]]; &apos;Hadriel Kaplan&apos; [[email-masked]]
CC: &apos;mmusic&apos; [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?
Hi Christer,

In case it should be allowed to send the BUNDLE in the first offer, the mechanism for understanding answerer support for BUNDLE has to be standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities).

Thanks
Partha

Hi,

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: &apos;Hadriel Kaplan&apos; [[email-masked]]; Christer Holmberg [[email-masked]]
CC: &apos;mmusic&apos; [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?
Hi Hadriel/Christer,

Thanks
Partha

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 14:03:00 -0500

On 8/8/13 13:58, Hadriel Kaplan wrote:
> What I'm proposing is we don't break/change that whatsoever. We have 
> the UAC send port=0 and "a=bundle-only" in the Offer, and UAS send an 
> SDP answer with port=0 too, and ALSO "a=bundle-only" for the m-lines 
> it is ok with using. Or "a=bundle-only:use" or whatever.

But why? You're introducing additional mechanism (and hence complexity) 
for no technical advantage.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 19:09:20 +0000

Hi,

So, you suggest that port zero means reject, and port-zero + a=bundle-only means something else - in Offers AND Answers?

Even if that might be doable, my main issue is still that since the Answerer assign the bundle port to all other bundled m- lines, it should also assign it to the bundle-only m- lines.

Also, we need to study whether we need to indicate bundle-only in answers to begin with, as the purpose of the indicator only applies to offers...

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Adam Roach [[email-masked]]; mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 15:11:27 -0400

On Aug 8, 2013, at 3:03 PM, Adam Roach <[email-masked]> wrote:

>> What I'm proposing is we don't break/change that whatsoever. We have the UAC send port=0 and "a=bundle-only" in the Offer, and UAS send an SDP answer with port=0 too, and ALSO "a=bundle-only" for the m-lines it is ok with using. Or "a=bundle-only:use" or whatever.
> 
> But why? You're introducing additional mechanism (and hence complexity) for no technical advantage.

1) To avoid confusing the things that go bump in the night.

2) To avoid updating RFC 3264.

3) Because it's the right thing to do.  If I send a new SDP Offer 10 minutes later during the session, and I set an existing m-line to port 0 in that Offer, does it mean I want to disable the media, or restart bundling, or what?  We're talking about SDP here, and a port=0 means "disabled", or "unwanted", or whatever word you want to use.  It means that in an offer, and it means that in an answer.  It doesn't matter when you got the offer, or when you got the answer.  It's stateless.  I don't see how that adds complexity - seems simpler to me.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 15:32:00 -0400

General question: Are we talking about this for WebRTC only, or for general SDP applications?  I'm worried I'm not in the same context as you guys.  I'm talking about this stuff in terms of using it for SIP.  If you're only talking about it for WebRTC, please let me know.

> So, you suggest that port zero means reject, and port-zero + a=bundle-only means something else - in Offers AND Answers?

I'm suggesting that if we want to use this for SIP, instead of only WebRTC, that RFC 3264 be followed:
   A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness,
   since the answer can contain a zero port indicating a rejected stream
   (Section 6).  Furthermore, existing streams can be terminated by
   setting the port to zero (Section 8).  In general, a port number of
   zero indicates that the media stream is not wanted.

BUNDLE would have an attribute it defines of "a=bundle-only" or whatever, which has a defined semantic of "I am willing to use this media, but only in a BUNDLE RFC multiplex transport thingamajig".  It has that meaning in SDP, period... what does it matter if it's in an offer or answer?  Why have different meanings for it? (I'm not following you on the concern - I must be missing something)

> Even if that might be doable, my main issue is still that since the Answerer assign the bundle port to all other bundled m- lines, it should also assign it to the bundle-only m- lines.

If we're talking about using this for SIP, I think the safest thing to do is have both the initial Offer and initial Answer keep to 3264, and have the Answer use port=0 for any m-lines it received as port=0 in an Offer.  Obviously it's going to take another O/A round, and I hate that... but that's life. (...for SIP - we can optimize WebRTC if we think its necessary)

-hadriel

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 9 Aug 2013 01:02:04 +0530

Hi Christer,

<snip>

</snip>

My question is how offerer will get to know about answerer capabilities in
the first offer?  In case it should be allowed to send the BUNDLE in the
first offer, the mechanism for understanding answerer's BUNDLE capabilities
has to be standardized as well like in Sec 9 of RFC 3264 (Indicating
capabilities). Let us discuss separately how the answerer will indicate
BUNDLE capabilities (BUNDLE group attributes missing,"bundle-only"
attribute) which is not a concern as of now. Hope this clarifies.

Thanks

Partha

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, August 09, 2013 12:31 AM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

Hi,

I don't think the answerer needs a feature tag to indicate BUNDLE support.

 If it doesn't support BUNDLE, it won't include the BUNDLE group in the
answer, nor will it assign a single port value to multiple m- lines.

Regards,

Christer 

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: Christer Holmberg [[email-masked]]; &apos;Hadriel
Kaplan&apos; [[email-masked]]
CC: &apos;mmusic&apos; [[email-masked]]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines? 

Hi Christer,

Thanks

Partha 

Hi,

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: &apos;Hadriel Kaplan&apos; [[email-masked]]; Christer

Hi Hadriel/Christer,

Thanks
Partha

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 14:37:30 -0500

On 8/8/13 14:11, Hadriel Kaplan wrote:
> If I send a new SDP Offer 10 minutes later during the session, and I set an existing m-line to port 0 in that Offer, does it mean I want to disable the media, or restart bundling, or what?

We already talked about that in Berlin: it means you want to disable the 
line. We're assigning special semantics to port=0 in the **FIRST** offer 
of a session. Only. Basically, it's a secret handshake that allows you 
to negotiate bundle at the same time as using it without confusing those 
implementations that have no idea what all this bundle stuff means. Once 
you've established that the other end can understand bundle, you don't 
need the port-0 indication.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 15:41:59 -0400

On Aug 8, 2013, at 3:37 PM, Adam Roach <[email-masked]> wrote:

> We already talked about that in Berlin: it means you want to disable the line. We're assigning special semantics to port=0 in the **FIRST** offer of a session. Only. Basically, it's a secret handshake that allows you to negotiate bundle at the same time as using it without confusing those implementations that have no idea what all this bundle stuff means. Once you've established that the other end can understand bundle, you don't need the port-0 indication.

Figured... so you're treating it different. "But why? You're introducing additional mechanism (and hence complexity) for no technical advantage."
:)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 14:43:20 -0500

> Figured... so you're treating it different. "But why? You're introducing additional mechanism (and hence complexity) for no technical advantage."

The technical advantage is exactly the property I just mentioned: it 
"allows you to negotiate bundle at the same time as using it without 
confusing those implementations that have no idea what all this bundle 
stuff means." That's a pretty important property.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 16:51:57 -0400

On Aug 8, 2013, at 3:43 PM, Adam Roach <[email-masked]> wrote:

> The technical advantage is exactly the property I just mentioned: it "allows you to negotiate bundle at the same time as using it without confusing those implementations that have no idea what all this bundle stuff means." That's a pretty important property.

Yeah, I as being a wise-a$$.  But my point is it won't really have that property, in practice.  As much as we'd like it to be otherwise, there really are things in the middle that will cause this thing to screw up in weird ways.  It's just not as simple as "if they don't understand the new a=bundle-only attribute, then they'll reject the request".[1]

It's not unlike the need to use different port numbers for normal bundle lines.

-hadriel
[1] BTW, I'm not speaking about my employer's SBCs in particular - I actually have no idea what we'll do with an UP bundle-only thing lying about a port=0.  We could handle it all correctly, or tear the call down later, or call WOPR and tell it to play Global Thermonuclear War.  If something's broken in our implementation, we'll fix it... eventually.  I'm more worried about other systems, from vendors who don't attend the IETF; and I'm worried about the people who have to run SIP networks, for whom this stuff is not a greenfield.

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Aug 2013 16:02:19 -0500

On 8/8/13 15:51, Hadriel Kaplan wrote:
> BTW, I'm not speaking about my employer's SBCs in particular - I actually have no idea what we'll do with an UP bundle-only thing lying about a port=0.  We could handle it all correctly, or tear the call down later, or call WOPR and tell it to play Global Thermonuclear War.  If something's broken in our implementation, we'll fix it... eventually.  I'm more worried about other systems, from vendors who don't attend the IETF; and I'm worried about the people who have to run SIP networks, for whom this stuff is not a greenfield.

The thing is: no matter what we do here, it's not going to look 100% 
like the stuff that came before it. All we can do is look at the 
products we know about, look at the existing published semantics for 
protocol elements, and make educated guesses about what is likely to 
cause the fewest problems. We *know* that using the same port numbers 
for multiple m-lines causes bad behavior in more than a few endpoints, 
so that's out. On the other hand, the semantics of port=0 are pretty 
well defined, elicit the exact response we want for remote endpoints, 
and avoid egregiously large port allocations during call setup (which is 
an important goal).

I think that's a lot more solid set of reasons than the opposing 
rationale you proffer of "there may or may not be products somewhere in 
the world that don't really like this approach," not least of all 
because that statement is true of any approach we come up with.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 21:35:00 +0000

Hadriel,

I'm a little confused. I thought you wanted port zero in the Answer, but the discussion now seems to be around port zero in the Offer.

Or, have I missed something?

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 goes UP: Do we need port zero for bundle-only m- lines?

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 17:40:27 -0400

> Or, have I missed something?

Sorry for the confusion - the thing I'm arguing against is the Offer having port=0, while the Answer having port=N.

I'm fine with the Offer having port=0 and the Answer having port=0 (i.e., sticking to RFC 3264).

[yeeesh this topic is hard to discuss in email!]

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2013 21:51:32 +0000

Maybe we should create persistent chat rooms to discuss specific topics, or something...

Anyway, so you are saying that a port-zero Offer + a non-port zero Answer will cause problems, and/or will require an update of 3264?

Regarding the possible problem, I believe (I haven't checked how the products my company make behave, though) that intermediaries simply would not care about the port value in the Answer, as it was zero in the Offer. They would consider the associated media disabled/removed - which is why I believe a second offer is needed also for bundle-only...

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Adam Roach [[email-masked]]; mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

---

From: Mary Barnes <[email-masked]>
Date: Thu, 8 Aug 2013 16:59:01 -0500

There is already a chatroom configured for each of the WGs:
http://www.ietf.org/jabber/index.html
It's the same one you would join during a meeting.  You can access it via
the tools page:
http://tools.ietf.org/wg/mmusic/

Logs are permanent, etc.  And, of course subject to IETF IPR rules ;)

Mary.

On Thu, Aug 8, 2013 at 4:51 PM, Christer Holmberg <
[email-masked]> wrote:

> Anyway, so you are saying that a port-zero Offer + a non-port zero Answer
> will cause problems, and/or will require an update of 3264?
>
> Regarding the possible problem, I believe (I haven't checked how the
> products my company make behave, though) that intermediaries simply would
> not care about the port value in the Answer, as it was zero in the Offer.
> They would consider the associated media disabled/removed - which is why I
> believe a second offer is needed also for bundle-only...
>
> Regards,
>
> Christer
>
>
> Sent from *Windows* using *TouchDown* (www.nitrodesk.com)
>
> *From:* Hadriel Kaplan [[email-masked]]
> *To:* Christer Holmberg [[email-masked]]
> *CC:* Adam Roach [[email-masked]]; mmusic [[email-masked]]
> *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for
> bundle-only m- lines?
>
> > I'm a little confused. I thought you wanted port zero in the Answer, but
> the discussion now seems to be around port zero in the Offer.
> Sorry for the confusion - the thing I'm arguing against is the Offer
> having port=0, while the Answer having port=N.
>
> > > BTW, I'm not speaking about my employer's SBCs in particular - I
> actually have no idea what we'll do with an UP bundle-only thing lying
> about a port=0.  We could handle it all correctly, or tear the call down
> later, or call WOPR and tell it to play Global Thermonuclear War.  If
> something's broken in our implementation, we'll fix it... eventually.  I'm
> more worried about other systems, from vendors who don't attend the IETF;
> and I'm worried about the people who have to run SIP networks, for whom
> this stuff is not a greenfield.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 18:07:07 -0400

On Aug 8, 2013, at 5:02 PM, Adam Roach <[email-masked]> wrote:

> The thing is: no matter what we do here, it's not going to look 100% like the stuff that came before it. All we can do is look at the products we know about, look at the existing published semantics for protocol elements, and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same port numbers for multiple m-lines causes bad behavior in more than a few endpoints, so that's out. On the other hand, the semantics of port=0 are pretty well defined, elicit the exact response we want for remote endpoints, and avoid egregiously large port allocations during call setup (which is an important goal).

The semantics of using port=0 are well defined, as you say - those semantics are that you MUST NOT use the media.  You are changing those semantics, if the far-end supports BUNDLE.  You feel it's safe to change those semantics, because you feel that SDP is only being processed by the local and remote endpoints.  I'm saying that's a really bad assumption, because I know that in fact it is not the case.

> I think that's a lot more solid set of reasons than the opposing rationale you proffer of "there may or may not be products somewhere in the world that don't really like this approach," not least of all because that statement is true of any approach we come up with.

Do you honestly believe that using a port number of 0 in an offer, while the answer uses a port number of N, is equally impacting on interoperability as using an attribute for capability discovery and then a second O/A round of the real numbers?  C'mon man.  You've seen the stuff that's out there.  The SDP Offer and Answer's m-line port number is used by all kinds of whacky equipment, to determine the RTP/RTCP flow information.  It's used by passive monitoring systems, NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what else.  Even just in my own employer, we've got five different types of equipment that look at the the m-line port numbers, only one of which is our SBCs (and we've got multiple flavors of them too, fwiw).

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 04:38:46 +0000

Hi,

An alternative way, using BUNDLE as currently specified, is the add the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been negotiated. Then one does not need port zero. Of course, that would a "third" Offer (technically it could be done already in the "second" Offer, but BUNDLE recommends against that).

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [[email-masked]]
To: Adam Roach [[email-masked]]
CC: Christer Holmberg [[email-masked]]; mmusic [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 08:30:02 -0400

On Aug 9, 2013, at 12:38 AM, Christer Holmberg <[email-masked]> wrote:

> An alternative way, using BUNDLE as currently specified, is the add the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been negotiated. Then one does not need port zero.

Yup, that makes a lot of sense.

> Of course, that would a "third" Offer (technically it could be done already in the "second" Offer, but BUNDLE recommends against that).

Why does BUNDLE recommend against it, such that it needs a third round?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 13:20:53 +0000

Hi,

> Why does BUNDLE recommend against it, such that it needs a third round?

I don't have the exact wording in front of me, but as the second offer is meant mainly for "port synchronizing", one should not put lots of extra stuff to it, which raises the chance for the offer being rejected.

But, of course, you don't have to reject the whole offer if you don't like the new m- lines, as you can reject them with port zero...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 09:43:02 -0400

On Aug 9, 2013, at 9:20 AM, Christer Holmberg <[email-masked]> wrote:

> But, of course, you don't have to reject the whole offer if you don't like the new m- lines, as you can reject them with port zero…

Yup.  And the advantage with this whole idea is there is no "a=bundle-only" attribute needed whatsoever, no change in port=0 behavior, etc.  It just goes back to the semantics we have today, which is arguably the safest thing to do.  I like your idea a lot.

The concept of "change as little as possible in the second offer" makes some pragmatic sense, but a UAC could be more aggressive/optimistic by having the second offer do it all, and if that Offer gets rejected entirely then do it piecemeal.  In other words, have the initial Offer advertise the current bundle stuff (without bundle-only m-lines), and if the Answer says bundle, then a second offer sends the original m-lines with corrected port numbers as well as new bundled m-lines - the ones it was only willing to use if the other end supported BUNDLE.  And if that Offer fails completely, then send an Offer of only the original bundle lines with corrected port numbers.

Or we could even just leave that type of decision up to local policy.  We don't usually say what to do if a whole Offer gets rejected.  Of course we should remind the implementor that it might happen, and how they could handle it, but it doesn't have to be normative at all.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 15:03:10 +0000

Hi,

> Yup.  And the advantage with this whole idea is there is no "a=bundle-only" attribute needed whatsoever, no change in port=0 behavior, etc.  It just goes back to the semantics we have today, which…

But, that doesn't mean you will put my picture on one of your future meeting slides, does it? ;)

> The concept of "change as little as possible in the second offer" makes some pragmatic sense, but a UAC could be more aggressive/optimistic by having the second offer do it all, and if that Offer gets rejected entirely then do it piecemeal.  In other 
> words, have the initial Offer advertise the current bundle > stuff (without bundle-only m-lines), and if the Answer says bundle, then a second offer sends the original m-lines with corrected port numbers as well as new bundled m-lines - the ones it 
> was only willing to use if the other end supported BUNDLE.  And if that Offer fails completely, then send an Offer of only the original bundle lines with corrected port numbers.

Yes.

> Or we could even just leave that type of decision up to local policy.  We don't usually say what to do if a whole Offer gets rejected.  Of course we should remind the implementor that it might happ…

Currently, the only thing the standard (RFC 3264) says is that, if the Offer gets rejected, the previous SDP state apply. However, in the case of BUNDLE, as the second offer is very much "bound" to the first one, since it completes the BUNDLE negotiation, we may need to say something (the draft may already say something) on how to behave.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Aug 2013 08:28:11 -0700

Uh, just say no to this.

We can't design a system under the constraint that it doesn't annoy
any middlebox in the world.

-Ekr

On Thu, Aug 8, 2013 at 9:38 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> An alternative way, using BUNDLE as currently specified, is the add the
> bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been
> negotiated. Then one does not need port zero. Of course, that would a
> "third" Offer (technically it could be done already in the "second" Offer,
> but BUNDLE recommends against that).
>
> Regards,
>
> Christer
>
>
>
> *To:* Adam Roach [[email-masked]]
> *CC:* Christer Holmberg [[email-masked]]; mmusic [
> [email-masked]]
> like the stuff that came before it. All we can do is look at the products
> we know about, look at the existing published semantics for protocol
> elements, and make educated guesses about what is likely to cause the
> fewest problems. We *know* that using the same port numbers for multiple
> m-lines causes bad behavior in more than a few endpoints, so that's out. On
> the other hand, the semantics of port=0 are pretty well defined, elicit the
> exact response we want for remote endpoints, and avoid egregiously large
> port allocations during call setup (which is an important goal).
>
> The semantics of using port=0 are well defined, as you say - those
> semantics are that you MUST NOT use the media.  You are changing those
> semantics, if the far-end supports BUNDLE.  You feel it's safe to change
> those semantics, because you feel that SDP is only being processed by the
> local and remote endpoints.  I'm saying that's a really bad assumption,
> because I know that in fact it is not the case.
>
>
>
> rationale you proffer of "there may or may not be products somewhere in the
> world that don't really like this approach," not least of all because that
> statement is true of any approach we come up with.
>
> Do you honestly believe that using a port number of 0 in an offer, while
> the answer uses a port number of N, is equally impacting on
> interoperability as using an attribute for capability discovery and then a
> second O/A round of the real numbers?  C'mon man.  You've seen the stuff
> that's out there.  The SDP Offer and Answer's m-line port number is used by
> all kinds of whacky equipment, to determine the RTP/RTCP flow information.
> It's used by passive monitoring systems, NATs, CGNs, Firewalls, Routers,
> PDGs, x-CSCFs, SBCs, App servers, and god knows what else.  Even just in my
> own employer, we've got five different types of equipment that look at the
> the m-line port numbers, only one of which is our SBCs (and we've got
> multiple flavors of them too, fwiw).
>
> -hadriel
>
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 9 Aug 2013 21:46:32 +0530

I agree with Hadriel that offer with port 0 and answer with non-zero 
Port is harmful and leads to interop issues. This approach also
Violates Sec 8.2 of RFC 3264 requirement

" A stream that is offered with a port of zero MUST be marked with port
   zero in the answer."

Thanks
Partha

> Sent: Friday, August 09, 2013 3:37 AM
> To: Adam Roach
> Cc: mmusic; Christer Holmberg
> about a port=0.  We could handle it all correctly, or tear the call
> down later, or call WOPR and tell it to play Global Thermonuclear War.
> If something's broken in our implementation, we'll fix it...
> eventually.  I'm more worried about other systems, from vendors who
> don't attend the IETF; and I'm worried about the people who have to run
> SIP networks, for whom this stuff is not a greenfield.
> >
> and avoid egregiously large port allocations during call setup (which
> is an important goal).
> 
> semantics, if the far-end supports BUNDLE.  You feel it's safe to
> change those semantics, because you feel that SDP is only being
> processed by the local and remote endpoints.  I'm saying that's a
> really bad assumption, because I know that in fact it is not the case.
> 
> 
> 
> Do you honestly believe that using a port number of 0 in an offer,
> while the answer uses a port number of N, is equally impacting on
> interoperability as using an attribute for capability discovery and
> then a second O/A round of the real numbers?  C'mon man.  You've seen
> the stuff that's out there.  The SDP Offer and Answer's m-line port
> number is used by all kinds of whacky equipment, to determine the
> RTP/RTCP flow information.  It's used by passive monitoring systems,
> NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and
> god knows what else.  Even just in my own employer, we've got five
> different types of equipment that look at the the m-line port numbers,
> only one of which is our SBCs (and we've got multiple flavors of them
> too, fwiw).
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Aug 2013 18:42:55 +0200

Wow! I ignore this thread for a day and it goes wild!
I get the advantage of looking at the long discussion and only replying 
selectively.

On 8/8/13 9:37 PM, Adam Roach wrote:
>> If I send a new SDP Offer 10 minutes later during the session, and I
>> set an existing m-line to port 0 in that Offer, does it mean I want to
>> disable the media, or restart bundling, or what?
>
> of a session.

IMO this is the wrong way to think of this special case.
Rather, it is special to the first offer that proposes a new bundle.
It need not be the first offer of the session. It may be that you have 
many offers in the session that don't use bundle at all. And then 
eventually you get into a state where you need a bundle. (Yes, I know 
that is not the WebRTC use case.)

	Thanks,
	Paul

> Only. Basically, it's a secret handshake that allows you

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Aug 2013 18:47:08 +0200

On 8/9/13 6:38 AM, Christer Holmberg wrote:
> "third" Offer (technically it could be done already in the "second"
> Offer, but BUNDLE recommends against that).

I quite like this, but prefer that it be allowed in the 2nd O/A.
It is consistent with my desire to make many of these "rules" a bit more 
lenient.

If done in the 2nd O/A, which is required anyway, then that should 
eliminate much (not all) of the objections that are likely to come from 
RTCWEB.

	Thanks,
	Paul

> Regards,
> Christer
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> *CC:* Christer Holmberg [[email-masked]]; mmusic
> [[email-masked]]
>>> BTW, I'm not speaking about my employer's SBCs in particular - I actually have no idea what we'll do with an UP bundle-only thing lying about a port=0.  We could handle it all correctly, or tear the call down later, or call WOPR and tell it to play Global  Thermonuclear War.  If something's broken in our implementation, we'll
> fix it... eventually.  I'm more worried about other systems, from
> vendors who don't attend the IETF; and I'm worried about the people who
> have to run SIP networks, for whom this stuff is not a greenfield.
>>
>> The thing is: no matter what we do here, it's not going to look 100% like the stuff that came before it. All we can do is look at the products we know about, look at the existing published semantics for protocol elements, and make educated guesses about what  is likely to cause the fewest problems. We *know* that using the same
> port numbers for multiple m-lines causes bad behavior in more than a few
> endpoints, so that's out. On the other hand, the semantics of port=0 are
> pretty well defined, elicit the exact response we want for remote
> endpoints, and avoid egregiously large port allocations during call
> setup (which is an important goal).
>
> those semantics, because you feel that SDP is only being processed by
> the local and remote endpoints.  I'm saying that's a really bad
> assumption, because I know that in fact it is not the case.
>
>
>
> interoperability as using an attribute for capability discovery and then
> a second O/A round of the real numbers?  C'mon man. You've seen the
> stuff that's out there.  The SDP Offer and Answer's m-line port number
> is used by all kinds of whacky equipment, to determine the RTP/RTCP flow
> information.  It's used by passive monitoring systems, NATs, CGNs,
> Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what
> else.  Even just in my own employer, we've got five different types of
> equipment that look at the the m-line port numbers, only one of which is
> our SBCs (and we've got multiple flavors of them too, fwiw).
>
> -hadriel
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 09 Aug 2013 11:53:03 -0500

On 8/9/13 11:42, Paul Kyzivat wrote:
> I get the advantage of looking at the long discussion and only 
> replying selectively.
>

Yes, that's a good point. Basically, it's got to be the first message 
that tries to use bundle.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 12:57:28 -0400

> any middlebox in the world.

If we're talking about solely for WebRTC usage, I agree: we have a greenfield playground, in an early phase of life.

If we're talking about SIP, it's a widely deployed critical infrastructure - we can make changes, but we really do have to be super cautious about what the changes are and what they impact.  Not only have we previously done exactly that for exactly these reasons for very similar situations for SIP including SDP changes... but we do the same for other IETF protocols that are no longer in incubation phases but rather widely deployed and critical for users that they don't break: for example DNS, SMTP, and even HTTP.  The IETF recognizes that there are undefined middleboxes (both active and passive), in various deployment models, which constrain the types of changes that can be safely made to those protocols; and we recognize that breaking things isn't in the best interest of the users of the Internet, nor the admins which have to run it.

I'm not saying we can't ever make changes to SIP - of course we can, and we do - but we really do need to consider the implications of what we're changing on the deployed infrastructure, and in way more than a one month "let us know if we break stuff" review period.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 19:44:16 +0000

Hi,

Also keep in mind that what I am suggesting *IS* already supported by BUNDLE. There is nothing we need to change - not in BUNDLE, not in 3264, not anywhere else :)

And, as the second offer is needed anyway, we are not adding any extra delay etc either.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Hadriel Kaplan
Lähetetty: 9. elokuuta 2013 19:57
Vastaanottaja: Eric Rescorla
Kopio: mmusic
Aihe: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 19:49:43 +0000

Hi,
,
>> An alternative way, using BUNDLE as currently specified, is the add 
>> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has 
>> been negotiated. Then one does not need port zero. Of course, that 
>> would a "third" Offer (technically it could be done already in the "second"
> It is consistent with my desire to make many of these "rules" a bit more lenient.
>
> If done in the 2nd O/A, which is required anyway, then that should eliminate much (not all) of the objections that are likely to come from RTCWEB.

Yes.

And, the 2nd O/A should be fine, as the new bundle-only m- lines can be rejected (using port zero in the Answer) without having to reject the whole Offer (i.e. it won't affect the "port synchronization" of the other m- lines in the Offer).

Regards,

Christer

>>> actually have no idea what we'll do with an UP bundle-only thing 
>>> lying about a port=0.  We could handle it all correctly, or tear the 
>>> call down later, or call WOPR and tell it to play Global  
>>> Thermonuclear War.  If something's broken in our implementation, 
>>> we'll
> vendors who don't attend the IETF; and I'm worried about the people 
> who have to run SIP networks, for whom this stuff is not a greenfield.
>>
>> cause the fewest problems. We *know* that using the same
> port numbers for multiple m-lines causes bad behavior in more than a 
> few endpoints, so that's out. On the other hand, the semantics of 
> port=0 are pretty well defined, elicit the exact response we want for 
> remote endpoints, and avoid egregiously large port allocations during 
> call setup (which is an important goal).
>
> only one of which is our SBCs (and we've got multiple flavors of them too, fwiw).
>
> -hadriel
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 19:55:29 +0000

Hi,

> I get the advantage of looking at the long discussion and only replying selectively.

We should have someone "taking notes" of the e-mail discussions, and then post a week-everyone-who-cares-need-to-know summary once a week :)

>>> set an existing m-line to port 0 in that Offer, does it mean I want 
>>> to disable the media, or restart bundling, or what?
>>
>> We already talked about that in Berlin: it means you want to disable 
>> the line. We're assigning special semantics to port=0 in the **FIRST** 
>> offer of a session.
>
> It need not be the first offer of the session. It may be that you have many offers in the session that don't use bundle at all. And then eventually you get into a state where you need a bundle. (Yes, I know that is not the WebRTC use case.)

Can't you have a WebRTC use case with only one m- line, which obviously wouldn't require usage of BUNDLE? Then,  when you later add new m- lines, you also want to use BUNDLE...

Regards,

Christer

> Only. Basically, it's a secret handshake that allows you to negotiate 
> bundle at the same time as using it without confusing those 
> implementations that have no idea what all this bundle stuff means. 
> Once you've established that the other end can understand bundle, you 
> don't need the port-0 indication.
>
> /a

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Aug 2013 16:20:37 -0700

Requiring a second offer to add the bundle-only m-lines defeats the purpose
of bundle-only.
a) The delay to do an O/A will often exceed the time to allocate
candidates, for small numbers of streams; bundle-only was meant to avoid
this candidate latency.
b) Once you have the initial answer, you know whether the other side
supports BUNDLE, so you can take the appropriate action (and so there is no
need for bundle-only).

If SIP can't deal with the bundle-only concept, then WebRTC apps that care
about latency will have to decide whether they are running in WebRTC-only
mode or compatibility mode. In WebRTC-only mode, streams will be bundled in
the initial offer; in compatibility mode, 2 offer-answers will be needed.

This would be a somewhat unfortunate outcome, so I'd like to see
bundle-only (or something like it) work.

On Fri, Aug 9, 2013 at 12:49 PM, Christer Holmberg <
[email-masked]> wrote:

> And, the 2nd O/A should be fine, as the new bundle-only m- lines can be
> rejected (using port zero in the Answer) without having to reject the whole
> Offer (i.e. it won't affect the "port synchronization" of the other m-
> lines in the Offer).
>
> Regards,
>
> Christer
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2013 23:36:10 +0000

Hi Justin,

> Requiring a second offer to add the bundle-only m-lines defeats the purpose of bundle-only.

We already require a second offer. I know that some people, including yourself, want to change that, but that is nothing we have agreed on. 

> a) The delay to do an O/A will often exceed the time to allocate candidates, for small numbers of streams; bundle-only was meant to avoid this candidate latency.

You do not have to allocate ports for the bundle-only m- lines.

> b) Once you have the initial answer, you know whether the other side supports BUNDLE, so you can take the appropriate action (and so there is no need for bundle-only).
>
> If SIP can't deal with the bundle-only concept, then WebRTC apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed.

There are no "modes" in BUNDLE today :)

> This would be a somewhat unfortunate outcome, so I'd like to see bundle-only (or something like it) work.

I don't think the second offer is going to cause any latency. Also, keep in mind that you only need the 2nd Offer/Answer during the session establishment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer/answers.

Regards,

Christer

On Fri, Aug 9, 2013 at 12:49 PM, Christer Holmberg <[email-masked]> wrote:
Hi,
,
Yes.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Aug 2013 17:02:46 -0700

On Fri, Aug 9, 2013 at 4:36 PM, Christer Holmberg <
[email-masked]> wrote:

> We already require a second offer. I know that some people, including
> yourself, want to change that, but that is nothing we have agreed on.
>

> > If SIP can't deal with the bundle-only concept, then WebRTC apps that
> care about latency will have to decide whether they are running in
> WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will
> be bundled in the initial offer; in compatibility mode, 2 offer-answers
> will be needed.
>

Of course there are. The handling in a reinvite case is distinct from the
initial offer, so that is modal behavior.

> I don't think the second offer is going to cause any latency. Also, keep
> in mind that you only need the 2nd Offer/Answer during the session
> establishment. As agreed in Berlin, in mid-session changes you do NOT need
> 2 offer/answers.
>

Please provide support for this statement. It seems clear that a 2nd offer
adds _at least_ 1 RTT latency.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 20:13:07 -0400

> a) The delay to do an O/A will often exceed the time to allocate candidates, for small numbers of streams; bundle-only was meant to avoid this candidate latency.

You lost me - I thought the "bundle-only" lines do not use their own transport, and instead require a regular "bundle" line to use its transport info.  Afaict, that means the bundle-only have no candidates.  No?  (or I could be misunderstanding your point)

We're really only talking about the bundle-only lines in this discussion, I think.

> b) Once you have the initial answer, you know whether the other side supports BUNDLE, so you can take the appropriate action (and so there is no need for bundle-only).

Christer's proposal is to send the regular m-lines, including regular bundle m-lines, in the initial Offer.  The Answer comes back for those, and tells you if the far-end does bundle.  You then send another Offer, with more *bundle* m-lines.  There is no "bundle-only" needed anymore.

> If SIP can't deal with the bundle-only concept, then WebRTC apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode,…

Sure, that's WebRTC's decision.  Certainly for a JS<->Browser API, doing 2 offer-answers seems silly to me.

I don't know what you mean by "compatibility" mode.  What is a JS<->Browser API that's *not* "WebRTC-only" mode?  Shouldn't a Browser just always be in "WebRTC" mode?  If some specific *application* needs to do something else, I would think that's what JavaScript is for.

Wasn't the premise supposed to be WebRTC does the basic things by default in SDP to make simple things easy to write in JS; but lets the advanced applications be possible by munging SDP and doing other things in JS?  Surely an application developer who wishes to interface to SIP-land for more than just the basic audio+video calls can figure out how to write some Javascript to do a double offer/answer, no?

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Aug 2013 17:42:03 -0700

On Fri, Aug 9, 2013 at 5:13 PM, Hadriel Kaplan <[email-masked]>wrote:

> You lost me - I thought the "bundle-only" lines do not use their own
> transport, and instead require a regular "bundle" line to use its transport
> info.  Afaict, that means the bundle-only have no candidates.  No?  (or I
> could be misunderstanding your point)
>

I agree with what you are saying - I am just saying the latency effect of
the second O/A may be worse than the problem that bundle-only was trying to
solve.

> Christer's proposal is to send the regular m-lines, including regular
> bundle m-lines, in the initial Offer.  The Answer comes back for those, and
> tells you if the far-end does bundle.  You then send another Offer, with
> more *bundle* m-lines.  There is no "bundle-only" needed anymore.
>

Agree - there is no need for bundle-only with 2 O/As.

> I don't know what you mean by "compatibility" mode.  What is a
> JS<->Browser API that's *not* "WebRTC-only" mode?  Shouldn't a Browser just
> always be in "WebRTC" mode?  If some specific *application* needs to do
> something else, I would think that's what JavaScript is for.
>
> Wasn't the premise supposed to be WebRTC does the basic things by default
> in SDP to make simple things easy to write in JS; but lets the advanced
> applications be possible by munging SDP and doing other things in JS?
>  Surely an application developer who wishes to interface to SIP-land for
> more than just the basic audio+video calls can figure out how to write some
> Javascript to do a double offer/answer, no?

There has been resistance to the idea that the app needs to decide if it's
interfacing with SIP-land or not. Which is understandable, but perhaps this
goal of app agnosticism is unattainable.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 10 Aug 2013 22:08:35 +0000

Hi,

> Of course there are. The handling in a reinvite case is distinct from the initial offer, so that is modal behavior. 

Sure, but you were talking about "WebRTC-only mode" and "compatibility mode", and my point is that currently the procedures for initial offers, subsequent offers etc are the same.

> Please provide support for this statement. It seems clear that a 2nd offer adds _at least_ 1 RTT latency. 

Sure, but I don't think that is going to be a practical problem.

First, there are deployed legacy SIP systems that use even more O/A transactions during session establishment. And, in your case I assume you are even going to use something more "lightweight" than SIP to carry your Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subsequent O/A anyway.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 10 Aug 2013 22:15:30 +0000

Hi,

> Agree - there is no need for bundle-only with 2 O/As. 

There may not be a need for an explicit bundle-only attribute, but the 2 O/A DOES allow you add send m- lines and request the receiver to reject them unless they are put into the BUNDLE group - which is exactly what you want to achieve with bundle-only :)

So, you would still have support for the bundle-only concept.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Aug 2013 18:52:04 -0700

On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <
[email-masked]> wrote:

> > Of course there are. The handling in a reinvite case is distinct from
> the initial offer, so that is modal behavior.
>
> Sure, but you were talking about "WebRTC-only mode" and "compatibility
> mode", and my point is that currently the procedures for initial offers,
> subsequent offers etc are the same.
>
> >> I don't think the second offer is going to cause any latency. Also,
> keep in mind that you only need the 2nd Offer/Answer during the session

Well, I'd like to see a more convincing argument than "some middleboxes are
sad" when you
do that.

First, there are deployed legacy SIP systems that use even more O/A
> transactions during session establishment. And, in your case I assume you
> are even going to use something more "lightweight" than SIP to carry your
> Offer/Answers.
>

It's important to distinguish between round-trips that are in the critical
path for media
flowing and those which are not.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2013 07:39:45 +0000

Hi,

I think making sure all entities have the correct port numbers is critical in making sure the media will flow.

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Justin Uberti [[email-masked]]; [email-masked] [[email-masked]]; Paul Kyzivat [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Well, I'd like to see a more convincing argument than "some middleboxes are sad" when you
do that.

It's important to distinguish between round-trips that are in the critical path for media
flowing and those which are not.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Aug 2013 04:15:49 -0700

> in making sure the media will flow.

There is a difference between "making sure the media will flow" and "before
media can
flow at all". For instance, Neither Firefox nor Chrome current does a
second O/A
transaction and yet media flows just fine in most cases, since they are
operating
in an unmediated environment. Obviously, this is a best-case scenario, but
similarly
there are going to be mediated environments which are perfectly happy with
a second
O/A exchange with non-zero ports.

This argues against designing a system in which none of the secondary media
flows
without a second O/A exchange.

-Ekr

-----Original Message-----
> *From:* Eric Rescorla [[email-masked]]
> *CC:* Justin Uberti [[email-masked]]; [email-masked] [[email-masked]];
> Paul Kyzivat [[email-masked]]

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2013 13:11:06 +0000

Hi,

> There is a difference between "making sure the media will flow" and "before media can
> flow at all".
> For instance, Neither Firefox nor Chrome current does a second O/A
> transaction and yet media flows just fine in most cases, since they are operating
> in an unmediated environment. Obviously, this is a best-case scenario, but similarly
> there are going to be mediated environments which are perfectly happy with a second

There are also environements where a single offer, with identical port numbers, work just fine, because the receiver will be able to handle it even if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in different environments. 

But, sure, if the community thinks that we shall define different options, depending on environments etc, we can do that... 

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [[email-masked]]
To: Christer Holmberg [[email-masked]]

On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <[email-masked]> wrote:

Hi,

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Aug 2013 09:24:29 -0400

On Aug 11, 2013, at 7:15 AM, Eric Rescorla <[email-masked]> wrote:

> flow at all". For instance, Neither Firefox nor Chrome current does a second O/A
> This argues against designing a system in which none of the secondary media flows

Actually I think it argues against designing a system which treats an Application Programming Interface the same as an on-the-wire Internet-wide negotiation mechanism, with a deployed infrastructure that has been growing larger for the past 10 years.  It also argues against tying the fate of WebRTC to SIP, with regards to SDP O/A.

One thing we could do, for example, is define BUNDLE as we've been describing (which is essentially no change, afaik) and define its usage for SDP O/A as we've been describing.  But we put a "unless the sender has specific knowledge otherwise, as it could in [jsep] for example".  Or something like that.  Then the JSEP draft could say what to do for WebRTC usage.

Take a step back and ignore this particular port-numbering issue for a second: in what context would it make sense for an API to need two separate rounds of "Offer/Answer" between the Javascript and the Browser?  I.e., if we weren't using SDP at all, and had never heard of RFC 3264, and just used a native Javascript API... what use-cases would require the JS script and Browser to communicate multiple times between each other for the same action?  I think error cases might, for example.  And I think if the JS hooked into a callback for ICE transport selection changes, then the Browser would need to tell it when those things changed, for example.  Can you think of any others?

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Aug 2013 07:50:41 -0700

On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >> I think making sure all entities have the correct port numbers is
> critical in making sure the media will flow.
> >
> There are also environements where a single offer, with identical port
> numbers, work just fine, because the receiver will be able to handle it
> even if it doesn't support BUNDLE.
>

"different environments" != "arbitrary lossage by any middlebox in the
universe"

Again, you need to distinguish between *endpoints* and filtering
middleboxes.

> But, sure, if the community thinks that we shall define different options,
> depending on environments etc, we can do that...
>

Which is not what I said.

-Ekr

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2013 16:29:31 +0000

Hi,

> "different environments" != "arbitrary lossage by any middlebox in the universe"
>
> Again, you need to distinguish between *endpoints* and filtering middleboxes.

It depends on what you mean by "filtering". If a middlebox removes stuff from the signaling, there is nothing we can do about that.

The most simple case I am thinking about is a middlebox forwarding media based on information in the SDP.

> Which is not what I said.

You did talk about different environments. Wouldn't we need to define the procedures for each environment?

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [[email-masked]]
To: Christer Holmberg [[email-masked]]

Hi,

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2013 16:35:15 +0000

Hi,

>> There is a difference between "making sure the media will flow" and 
>> "before media can flow at all". For instance, Neither Firefox nor 
>> Chrome current does a second O/A transaction and yet media flows just 
>> fine in most cases, since they are operating in an unmediated 
>> environment. Obviously, this is a best-case scenario, but similarly 
>> there are going to be mediated environments which are perfectly happy with a second O/A exchange with non-zero ports.
>> 
>> This argues against designing a system in which none of the secondary 
>> media flows without a second O/A exchange.
>
> Actually I think it argues against designing a system which treats an Application Programming Interface the same as an on-the-wire Internet-wide 
> negotiation mechanism, with a deployed infrastructure that has been growing larger for the past 10 years.  It also argues against tying the fate of 
> WebRTC to SIP, with regards to SDP O/A.
>
> One thing we could do, for example, is define BUNDLE as we've been describing (which is essentially no change, afaik) and define its usage for SDP O/A as we've been describing.  
> But we put a "unless the sender has specific knowledge otherwise, as it could in [jsep] for example".  Or something like that.  Then the JSEP draft could say what to do for WebRTC usage.

You need to convince the people who have been against unless-the-sender-has-specific-knowledge procedures :)

> Take a step back and ignore this particular port-numbering issue for a second: in what context would it make sense for an API to need two separate 
> rounds of "Offer/Answer" between the Javascript and the Browser?  I.e., if we weren't using SDP at all, and had never heard of RFC 3264, and just used a 
> native Javascript API... what use-cases would require the JS script and Browser to communicate multiple times between each other for the same action? 
> I think error cases might, for example.  And I think if the JS hooked into a callback for ICE transport selection changes, then the Browser would need to 
> tell it when those things changed, for example.  Can you think of any others?

We need to remember that there is other information than the port in the SDP.

For example, there are attributes which will apply to the whole bundle, and the value set for those attribute may depend on how many m- lines there will be in the bundle (which, obviously, you don't know until you get the first answer).

Regards,

Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 11 Aug 2013 22:46:27 +0530

Eric,

<snip>

</snip>

IMO, it is not possible to identify "endpoint" and "filtering middleboxes"
based on the protocol exchanges. Both webrtc browser and webrtc gateway
handles ICE, SRTP-DTLS, same codecs, SDP in the same way. There is no way to
identify WebRTC browser to distinguish whether the remote side is a browser
or media gateway during WebRTC session. Please explain in case it is
possible to distinguish the remote side is WebRTC browser or WebRTC GW from
the originating browser.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rescorla
Sent: Sunday, August 11, 2013 8:21 PM
To: Christer Holmberg
Cc: mmusic_ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg
<[email-masked]> wrote:

Hi,

> There is a difference between "making sure the media will flow" and
"before media can
operating
similarly
a second

There are also environements where a single offer, with identical port
numbers, work just fine, because the receiver will be able to handle it even
if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in different
environments.

 

-Ekr

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [[email-masked]]
To: Christer Holmberg [[email-masked]]

CC: Justin Uberti [[email-masked]]; [email-masked] [[email-masked]];
Paul Kyzivat [[email-masked]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg
<[email-masked]> wrote:

Hi,

care about latency will have to decide whether they are running in
WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be
bundled in the initial offer; in compatibility mode, 2 offer-answers will be
needed.

in mind that you only need the 2nd Offer/Answer during the session
establishment. As agreed in Berlin, in mid-session changes you do NOT need 2
offer/answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a
subsequent O/A anyway.

-Ekr

---

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

> As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it.

I don't think that is the case. It can be used in an offer regardless of if you know the answer can support it or not. 

Related to other messages on the thread. Yes, I understand that ICE will have a "clean up O/A" to fix all the ports to be the ones actually in use but media flows before that "clean up". I have zero interest in exploding all this again to discuss a solution that would require more round trips before media could flow and be less likely to work with existing SIP stuff. I think the current design is better than one that would require multiple O/A to get media to flow.

---

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

On Aug 9, 2013, at 10:16 AM, Parthasarathi R <[email-masked]> wrote:

> This approach also

No this would not be violated. When one side was 3264 only, this would still happen. But when both sides support bundle-only, then this restriction no longer holds. The bundle draft as an extension to 3264 needs to clearly define all that.

---

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

> I don't think that is the case. It can be used in an offer regardless of if you know the answer can support it or not.

Agreed.

> Related to other messages on the thread. Yes, I understand that ICE will have a "clean up O/A" to fix all the ports to be the ones actually in use but media flows before that "clean up".

It may in some cases, not in others. (When intermediaries gate flows 
based on the answer then the media may not flow immediately.
Or maybe it will if the intermediary is sufficiently bundle-aware.

> I have zero interest in exploding all this again to discuss a solution that would require more round trips before media could flow and be less likely to work with existing SIP stuff. I think the current design is better than one that would require multiple O/A to get media to flow.

Exploring *what* again?
Its not like bundle-only has had such deep discussion.

What's clear is that bundle-only is a somewhat complex mechanism.
It isn't required if you are willing to do a 2nd o/a for the m-lines 
that would otherwise be bundle-only. It would indeed require another 
round trip before media could flow for *those* m-lines. Presumably they 
are "lower priority", so is that really a big deal? Is the extra 
machinery of bundle-only justified for this case?

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 15 Aug 2013 22:18:19 +0530

Cullen,

The violation of RFC 3264 happens as follows:

1) In case m line has port "0" and bundle-only attribute exists in the
Answer, it is possible to interpret by the offerer in two ways as
	a) Answer is rejected by the answerer wherein bundle-only attribute
has to be ignored. This in inline with RFC 3264. Here, there is a need for
extra offer/answer to confirm bundle is supported or not.
	b) Answer is rejected by the answerer wherein bundle-only attribute
is supported. Here, there is no need of one more offer/answer but the
interop issues with SIP entities will happen.

2) There are middle-boxes which provides QoS based on the current
offer/answer. In case of WebRTC, the simplified topology shall be 

 "Browser----SIP server-----Browser/SIP UA"

In these scenario, SIP server initiates Qos based on offer/answer exchange
between browsers. These SIP servers will fail in case an optional attribute
like "bundle-only" updates RFC 3264 behavior like offer with port 0 and
answer with proper port.

Thanks
Partha

> From: Cullen Jennings (fluffy) [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2013 4:59 AM
> To: Parthasarathi R
> Cc: mmusic WG
> No this would not be violated. When one side was 3264 only, this would
> still happen. But when both sides support bundle-only, then this
> restriction no longer holds. The bundle draft as an extension to 3264
> needs to clearly define all that.

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 15 Aug 2013 22:43:26 +0530

Eric,

<snip>

operating
> in an unmediated environment.

<snip>

Till now, my understanding is that Firefox & Chrome provides the running
code which is not fully compliant with all WebRTC specification. In fact, I
had come across the scenario wherein it is not clear in the signaling which
candidate pair is selected by the browser for media. Please correct me in
case the specification is not mandated to perform second O/A to confirm the
port selected for the media.

Thanks

Partha

 

Hi,

"before media can
operating
similarly
a second

 

-Ekr

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [[email-masked]]
To: Christer Holmberg [[email-masked]]

Hi,

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Aug 2013 07:24:11 +0000

Hi,

>  Related to other messages on the thread. Yes, I understand that ICE will have a "clean up O/A" to fix all the ports to be the ones actually in use but media flows before 
> that "clean up". I have zero interest in exploding all this again to discuss a solution that would require more round trips before media could flow and be less likely to work 
> with existing SIP stuff. I think the current design is better than one that would require multiple O/A to get media to flow. 

Discuss what???

In general, the current version of BUNDLE is based on the usage of 2 Offer/Answers - which is something you have agreed to.

If you only refer to bundle-only lines, that is a discussion that has just started...

Regards,

Christer