Subject: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

From: Peter Thatcher <[email-masked]>
Date: Fri, 7 Aug 2015 14:39:06 -0700

After lots of discussion, it appears we have three options:

1.  Endpoints MAY implement rtcp-non-mux (we change the spec and can delete
the ugly code)

2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must
delete the ugly code, and our non-compliant until we do)

3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec and
keep around the ugly code)

My reading of the discussion is that most people want #1 or #2, and very
few people still want #3.   Between #1 and #2, while some people would
prefer #2, there are good reasons to just do #1, and most seem to prefer
#1.  Further, I'm guessing that most people who wanted #2 could live with
#1.

TL;DR:  I think we may have rough consensus on #1, saying endpoints MAY
rtcp-non-mux (but may choose to delete all that ugly code instead).

So, is everyone happy with #1?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Aug 2015 15:19:00 -0700

Yes, #1.  It might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <[email-masked]> wrote:
> 3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and very few
> people still want #3.   Between #1 and #2, while some people would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.
> Further, I'm guessing that most people who wanted #2 could live with #1.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Aug 2015 15:26:12 -0700

#1 is fine with me.

-Ekr

On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <[email-masked]>
wrote:

> few

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 7 Aug 2015 22:29:34 +0000

The same here.

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Friday, August 7, 2015 6:26 PM
To: Martin Thomson
Cc: <[email-masked]>
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

#1 is fine with me.

-Ekr

On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Yes, #1.  It might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 7 Aug 2015 18:50:32 -0400

I would vote for 1 with the caveat that implementations MUST accept
rtcp-mux if offered.

_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Aug 2015 16:09:08 -0700

On 7 August 2015 at 15:50, Roman Shpount <[email-masked]> wrote:
> I would vote for 1 with the caveat that implementations MUST accept rtcp-mux
> if offered.

I'd be OK with an additional stipulation, though I'll note that we
don't actually need more inventive to select rtcp-mux.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 7 Aug 2015 19:35:55 -0400

On Fri, Aug 7, 2015 at 7:09 PM, Martin Thomson <[email-masked]>
wrote:

> rtcp-mux

What I was trying to say is that endpoints MAY implement rtcp-non-mux but
MUST not use it if rtcp-mux is available from the remote end point. Which
means MUST offer rtcp-mux and MUST accept rtcp-mux if offered. At this
point we can delete the ugly code.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Aug 2015 17:49:45 -0700

+1.

> On Aug 7, 2015, at 3:26 PM, Eric Rescorla <[email-masked]> wrote:
> 
> #1 is fine with me.
> 
> -Ekr
> 
> 
>> On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <[email-masked]> wrote:

---

From: Michael Davey <[email-masked]>
Date: Sat, 8 Aug 2015 07:47:36 +0100

Isn't MAY implicit anyway?  Vendors are free to extend as they wish as long
as they remain compliant with the spec and compatible with products that
strictly conform to the spec. and don't extend it.

Sounds like we are making the spec. needlessly complicated.

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sat, 08 Aug 2015 13:19:59 +0200

>> 3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep

I support option #1

/alfred

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Aug 2015 08:19:54 -0700

On Aug 7, 2015, at 23:47, Michael Davey <[email-masked]> wrote:
> Isn't MAY implicit anyway? 
> 
[BA] No, it is not because the RTP-Usage document makes support for RTP/RTCP non-mux mandatory.  We are talking about changing that text from MUST to MAY.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 09 Aug 2015 09:05:15 +0200

I am happy to live with #1.

There's a particular style of gateway (one that takes calls from WebRTC
devices and non-WebRTC, non-RTCP-mux devices at the same responding
port) that would have a hard time claiming WebRTC conformance under #2;
not a huge argument, but makes me a little more happy with #1 than #2.

On 08/07/2015 11:39 PM, Peter Thatcher wrote:
> 1.  Endpoints MAY implement rtcp-non-mux (we change the spec and can
> delete the ugly code)
>
> 2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec and
> must delete the ugly code, and our non-compliant until we do)
>
> 3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec
> and keep around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and
> very few people still want #3.   Between #1 and #2, while some people
> would prefer #2, there are good reasons to just do #1, and most seem
> to prefer #1.  Further, I'm guessing that most people who wanted #2
> could live with #1.
>
>
> TL;DR:  I think we may have rough consensus on #1, saying endpoints
> MAY rtcp-non-mux (but may choose to delete all that ugly code instead).  
>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 10 Aug 2015 09:10:56 +0000

If we have consensus for #1 then I assume we need to pull the -rtp-usage- draft back from the RFC Editor Queue (See https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 )

Andy

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 09 August 2015 08:05
To: [email-masked]
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

There's a particular style of gateway (one that takes calls from WebRTC devices and non-WebRTC, non-RTCP-mux devices at the same responding port) that would have a hard time claiming WebRTC conformance under #2; not a huge argument, but makes me a little more happy with #1 than #2.

1.  Endpoints MAY implement rtcp-non-mux (we change the spec and can delete the ugly code)

2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must delete the ugly code, and our non-compliant until we do)

3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep around the ugly code)

My reading of the discussion is that most people want #1 or #2, and very few people still want #3.   Between #1 and #2, while some people would prefer #2, there are good reasons to just do #1, and most seem to prefer #1.  Further, I'm guessing that most people who wanted #2 could live with #1.

TL;DR:  I think we may have rough consensus on #1, saying endpoints MAY rtcp-non-mux (but may choose to delete all that ugly code instead).

rtcweb mailing list

--

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Aug 2015 09:18:10 +0000

Hi,

As there are still people on vacation, I'd like to wait for a while before making the decision. There are e.g. radio folks that I'd like to get some input from.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: 10. elokuuta 2015 12:11
To: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

Andy

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 09 August 2015 08:05
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

rtcweb mailing list

--

---

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Aug 2015 11:43:43 +0100

We might be able to make the edits in AUTH48, with AD approval, rather than pull the draft back from the RFC Editor, but those are process steps we'll figure out. 

What I'd most like to understand is the exact text change that is being proposed for the rtp-usage draft. Can someone state what is believed to be the consensus?

Colin

On 10 Aug 2015, at 10:10, Hutton, Andrew <[email-masked]> wrote:

> If we have consensus for #1 then I assume we need to pull the –rtp-usage- draft back from the RFC Editor Queue (See  https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 )
>  
> Andy
>  
>  
>  
>  

-- 
Colin Perkins
https://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Aug 2015 13:29:02 +0200

Den 10. aug. 2015 12:43, skrev Colin Perkins:
> We might be able to make the edits in AUTH48, with AD approval, rather
> than pull the draft back from the RFC Editor, but those are process
> steps we'll figure out. 
> 
> What I'd most like to understand is the exact text change that is being
> proposed for the rtp-usage draft. Can someone state what is believed to
> be the consensus?

This sentence (4.5) needs to be deleted for all variants proposed:

   For
   backwards compatibility, implementations are also REQUIRED to support
   RTP and RTCP sent on separate transport-layer flows.

I *think* that my favorite solution, #1, can replace it with

   Implementations MAY support
   RTP and RTCP sent on separate transport-layer flows. They MAY also
   refuse to do so, in which case any negotiation that results in
   multiplexing not being negotiated is treated as a failure.

This is based on the theory that "failure is always an option", which
saves us from adding extra protocol machinery to deal with this case.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Aug 2015 09:04:53 -0400

> saves us from adding extra protocol machinery to deal with this case.

+1

Simon

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 10 Aug 2015 15:33:38 +0200

+1

On Sat, Aug 8, 2015 at 12:26 AM, Eric Rescorla <[email-masked]> wrote:

>> delete
>> must
>> very few

-- 
Victor Pascual Ávila

---

From: Göran Eriksson AP <[email-masked]>
Date: Mon, 10 Aug 2015 13:39:40 +0000

Personal opinion:

Might be an issue for low-bitrate audio use cases in wireless networks. I
can imagine scenarios where the rtp and rtcp packets are best carried on
different radio bearers, which is tricky of they are multiplexed onto the
same 5-tuple (and I am not sure I dare rely on DS marking to solve this).
I do not have more data in the actual impact easily at hand.

Since low-bitrate audio use cases, e.g. RTCWeb-2-RTCWeb, has not been a
prioritised category in WebRTC1.0, perhaps it is OK with #1 (in the RTCWeb
stack WebRTC1.0 API).

Regards
Göran

>Hi,
> 
>As there are still people on vacation, I’d like to wait for a while
>before making the decision. There are e.g. radio folks that I’d like to
>get
> some input from.
> 
>Regards,
> 
>Christer
> 
>If we have consensus for #1 then I assume we need to pull the –rtp-usage-
>draft back from the RFC Editor Queue (See
>
>https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5
><https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5> )
> 
>Andy
> 
> 
> 
> 
>devices and non-WebRTC, non-RTCP-mux devices at the same responding port)
>that would have a hard time claiming WebRTC conformance under #2; not a
>huge argument, but makes me a little more
> happy with #1 than #2.
>
>prefer #2, there are good reasons
> to just do #1, and most seem to prefer #1.  Further, I'm guessing that
>most people who wanted #2 could live with #1.
>
> 
>
> 
>
>_______________________________________________rtcweb mailing
>[email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>-- Surveillance is pervasive. Go Dark.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Aug 2015 14:45:45 +0000

#1 seems best to me, but there needs to be some well-specified way for JS applications and offer/answer peers to discover/understand whether rtcp-non-mux is indeed supported.  Otherwise there’s no practical difference between #1 and #2.

On Aug 7, 2015, at 5:39 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Aug 2015 15:39:33 +0000

Hi Jonathan,

Why can't we simply say that entities MUST insert the SDP attribute in offers and answers?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Jonathan Lennox<mailto:[email-masked]>
Sent: ‎10/‎08/‎2015 17:46
To: Google-Peter Thatcher<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Aug 2015 15:47:08 +0000

The whole point of supporting non-MUX mode is to allow answerers to choose not to insert the SDP attribute.

With option 1, the idea is that some endpoints will offer MUX, but support fallback to non-MUX if the peer chooses not to do it.

Some other endpoints will require that MUX be supported, and if a peer doesn’t understand this then things will fail in interesting ways.

If I’m (say) a gateway that would rather do non-MUX (to keep my life easier when gatewaying to legacy equipment), but is willing to do MUX if necessary, I need to know which sort of endpoint I’m talking to.

However, both types of endpoints will have inserted the attribute in their offer.

If you require that all entities MUST always insert the SDP attribute in both offers *and answers*, then you’re choosing option 2. (A standard that says “you MAY have code that implements this mode, but you MUST NOT ever use it” is pretty pointless.)

On Aug 10, 2015, at 11:39 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jonathan,

Regards,

Christer

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 10 Aug 2015 17:00:11 +0000

Harald's proposal sounds good to me. It economically and gracefully reflects my understanding of the current (rough) consensus.

Thanks,
Tolga

> -----Original Message-----
> Sent: Monday, August 10, 2015 7:29 AM
> To: Colin Perkins <[email-masked]>; Hutton, Andrew
> <[email-masked]>
> Cc: [email-masked]
> > What I'd most like to understand is the exact text change that is
> > being proposed for the rtp-usage draft. Can someone state what is
> > believed to be the consensus?
> 
> This is based on the theory that "failure is always an option", which saves us
> from adding extra protocol machinery to deal with this case.
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 10 Aug 2015 13:03:37 -0400

+1
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Aug 2015 18:02:07 +0000

Hi,

>The whole point of supporting non-MUX mode is to allow answerers to choose not to insert the SDP attribute.

From a protocol perspective, yes. But, if we say that a WebRTC entity MUST support/use rtcp-mux, then it means that it MUST include the attribute – EVEN if the protocol allows it not to.

>With option 1, the idea is that some endpoints will offer MUX, but support fallback to non-MUX if the peer chooses not to do it.

My understanding of option 1 is that some endpoints will *ONLY* implement MUX, and will NOT fallback to non-MUX if the peer (a non-WebRTC entity) chooses not to do it.

>Some other endpoints will require that MUX be supported, and if a peer doesn’t understand this then things will fail in interesting >ways.

Well, the endpoint that wants MUX will have to terminate the call.

>If I’m (say) a gateway that would rather do non-MUX (to keep my life easier when gatewaying to legacy equipment), but is willing to >do MUX if necessary, I need to know which sort of endpoint I’m talking to.

My understanding of #1 is that there is no such things as “would rather do non-MUX”. As a WebRTC gateway, you would always do MUX (at least towards the WebRTC endpoints).

>However, both types of endpoints will have inserted the attribute in their offer.

And, as a WebRTC endpoint, you will always insert the attribute in the answer.

>If you require that all entities MUST always insert the SDP attribute in both offers *and answers*, then you’re choosing option 2. (A >standard that says “you MAY have code that implements this mode, but you MUST NOT ever use it” is pretty pointless.)

Regarding #2, endpoints can implement whatever they want. The point is that they would never *USE* non-MUX.

Regards,

Christer

Hi Jonathan,

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Aug 2015 18:24:14 +0000

Are you seriously advocating “MAY implement, MUST NOT use”?  How does that make any sense at all?

As I understood Peter’s original option 1, he was proposing to change the spec to allow two types of implementations:

1. Endpoints that always offer mux, but are prepared for an answer that declines to do it, at which point they fall back to non-mux. (The current default behavior, and the behavior required by RFC 5761.)

2. Endpoints that always offer mux, in a way such that there is no way to fall back to non-mux.  Naive interop with a non-rtcp-mux endpoint, or with an endpoint that doesn’t want to do mux, will fail. (The current rtcpMuxPolicy:"require" behavior.)

If you say that no endpoint can ever do fallback to non-MUX, I don’t see what the point is.  You’re instead advocating for Peter’s option 2.

As I mentioned earlier in this thread, one solution to my problem — which I don’t like this because it’s mixing up features which IMO should be orthogonal, but I would be okay with — would be to say something like “offers that support fallback to non-RTCP-mux MUST include separate ICE candidates for RTCP, i.e. on component 2; offers that do not support such fallback MUST NOT include such candidates.”

The only difficulty with this solution is that it can be ambiguous when trickle ICE is being used, since an offer might not include any candidates at all.

On Aug 10, 2015, at 2:02 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Hi Jonathan,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Aug 2015 18:43:37 +0000

Hi,

>1. Endpoints that always offer mux, but are prepared for an answer that declines to do it, at which point they fall back to non-mux. >(The current default behavior, and the behavior required by RFC 5761.)
>
>2. Endpoints that always offer mux, in a way such that there is no way to fall back to non-mux.  Naive interop with a non-rtcp-mux >endpoint, or with an endpoint that doesn’t want to do mux, will fail. (The current rtcpMuxPolicy:"require" behavior.)
>
>If you say that no endpoint can ever do fallback to non-MUX, I don’t see what the point is.  You’re instead advocating for Peter’s >option 2.

Fair enough, I hear what you’re saying.

So, if we want to allow fallback to non-MUX, then I DO agree with you that we need a way for an entity to indicate that it also supports non-mux.

>As I mentioned earlier in this thread, one solution to my problem — which I don’t like this because it’s mixing up features which IMO >should be orthogonal, but I would be okay with — would be to say something like “offers that support fallback to non-RTCP-mux >MUST include separate ICE candidates for RTCP, i.e. on component 2; offers that do not support such fallback MUST NOT include >such candidates.”

That would be an option – OR you include RTP and RTCP candidates with identical values.

>The only difficulty with this solution is that it can be ambiguous when trickle ICE is being used, since an offer might not include any >candidates at all.

<This is the place where Emil will reply, saying that he sees no issue, and explain how it would work> :)

Regards,

Christer

Hi,

Regards,

Christer

Hi Jonathan,

Regards,

Christer

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 11 Aug 2015 15:38:36 +0800

+1 for #1

On Tue, Aug 11, 2015 at 2:43 AM, Christer Holmberg <
[email-masked]> wrote:

> >As I understood Peter’s original option 1, he was proposing to change the
> spec to allow two types of implementations:
>
> >
>
> >1. Endpoints that always offer mux, but are prepared for an answer that
> declines to do it, at which point they fall back to non-mux. >(The current
> default behavior, and the behavior required by RFC 5761.)
>
> >
>
> >2. Endpoints that always offer mux, in a way such that there is no way to
> fall back to non-mux.  Naive interop with a non-rtcp-mux >endpoint, or with
> an endpoint that doesn’t want to do mux, will fail. (The current
> rtcpMuxPolicy:"require" behavior.)
>
> >
>
> >If you say that no endpoint can ever do fallback to non-MUX, I don’t see
> what the point is.  You’re instead advocating for Peter’s >option 2.
>
>
>
> So, if we want to allow fallback to non-MUX, then I DO agree with you that
> we need a way for an entity to indicate that it also supports non-mux.
>
>
>
> >As I mentioned earlier in this thread, one solution to my problem — which
> I don’t like this because it’s mixing up features which IMO >should be
> orthogonal, but I would be okay with — would be to say something like
> “offers that support fallback to non-RTCP-mux >MUST include separate ICE
> candidates for RTCP, i.e. on component 2; offers that do not support such
> fallback MUST NOT include >such candidates.”
>
>
>
> >The only difficulty with this solution is that it can be ambiguous when
> trickle ICE is being used, since an offer might not include any >candidates
> at all.
>
>
>
> On Aug 10, 2015, at 2:02 PM, Christer Holmberg <
> [email-masked]> wrote:
>
>
>
> Hi,
>
>
>
> From a protocol perspective, yes. But, if we say that a WebRTC entity MUST
> support/use rtcp-mux, then it means that it MUST include the attribute –
> EVEN if the protocol allows it not to.
>
>
>
> >With option 1, the idea is that some endpoints will offer MUX, but
> support fallback to non-MUX if the peer chooses not to do it.
>
>
>
> My understanding of option 1 is that some endpoints will **ONLY**
> implement MUX, and will NOT fallback to non-MUX if the peer (a non-WebRTC
> entity) chooses not to do it.
>
>
>
> >Some other endpoints will require that MUX be supported, and if a peer
> doesn’t understand this then things will fail in interesting >ways.
>
>
>
> >If I’m (say) a gateway that would rather do non-MUX (to keep my life
> easier when gatewaying to legacy equipment), but is willing to >do MUX if
> necessary, I need to know which sort of endpoint I’m talking to.
>
>
>
> My understanding of #1 is that there is no such things as “would rather do
> non-MUX”. As a WebRTC gateway, you would always do MUX (at least towards
> the WebRTC endpoints).
>
>
>
> >If you require that all entities MUST always insert the SDP attribute in
> both offers *and answers*, then you’re choosing option 2. (A >standard that
> says “you MAY have code that implements this mode, but you MUST NOT ever
> use it” is pretty pointless.)
>
>
>
> Regarding #2, endpoints can implement whatever they want. The point is
> that they would never **USE** non-MUX.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> On Aug 10, 2015, at 11:39 AM, Christer Holmberg <
> [email-masked]> wrote:
>
>
>
> Hi Jonathan,
>
> ------------------------------
>
> *From: *Jonathan Lennox <[email-masked]>
> *Sent: *‎10/‎08/‎2015 17:46
> *To: *Google-Peter Thatcher <[email-masked]>
> *Cc: [email-masked]
> *Subject: *Re: [rtcweb] Do we have consensus on not requiring
> rtcp-non-mux?
>
> #1 seems best to me, but there needs to be some well-specified way for JS
> applications and offer/answer peers to discover/understand whether
> rtcp-non-mux is indeed supported.  Otherwise there’s no practical
> difference between #1 and #2.
>
>
>
>
> On Aug 7, 2015, at 5:39 PM, Peter Thatcher <[email-masked]> wrote:
>
>
>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Aug 2015 08:22:41 -0700

I think you are confusing two discussions here. One is what we do ice bis and one is rtcweb. They are a bit different. 

> On Aug 7, 2015, at 2:39 PM, Peter Thatcher <[email-masked]> wrote:
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Aug 2015 08:26:23 -0700

> On Aug 10, 2015, at 3:43 AM, Colin Perkins <[email-masked]> wrote:
> 

There was a discussion at last IETF about what we do with ice bis where this can make sense but I think we would want to talk to the WebRTC GW vendors a bit before changing the RTCWeb stuff.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Aug 2015 13:43:51 -0700

I am happy with proposal #1 and Harald's proposed text change.

On Tue, Aug 11, 2015 at 12:38 AM, Alexandre GOUAILLARD <
[email-masked]> wrote:

>> >As I understood Peter’s original option 1, he was proposing to change
>> the spec to allow two types of implementations:
>>
>> >
>>
>> >2. Endpoints that always offer mux, in a way such that there is no way
>> to fall back to non-mux.  Naive interop with a non-rtcp-mux >endpoint, or
>> with an endpoint that doesn’t want to do mux, will fail. (The current
>> So, if we want to allow fallback to non-MUX, then I DO agree with you
>> that we need a way for an entity to indicate that it also supports non-mux.
>>
>>
>>
>> >As I mentioned earlier in this thread, one solution to my problem —
>> which I don’t like this because it’s mixing up features which IMO >should
>> be orthogonal, but I would be okay with — would be to say something like
>> From a protocol perspective, yes. But, if we say that a WebRTC entity
>> MUST support/use rtcp-mux, then it means that it MUST include the attribute
>> – EVEN if the protocol allows it not to.
>>
>>
>>
>> My understanding of #1 is that there is no such things as “would rather
>> do non-MUX”. As a WebRTC gateway, you would always do MUX (at least towards
>> the WebRTC endpoints).
>>
>>
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 16 Aug 2015 09:24:54 +0200

Hi,

I am on vacation and just happened to see this. I will not follow up on 
on this until I am back in 1.5 weeks time (27th of Aug). So I do request 
that no conclusions are made until after I have had time to follow up on 
the discussion.

I object to this change. It appears that no one remembers why it is 
important for a WebRTC endpoint to support the non-muxed mode for RTP 
and RTCP. Yes, this was discussed 3 years back and motivated. I think 
the interim in Stockholm is when we made this decision.

The reason is why I see it is as very important that WebRTC endpoints 
support non-mux is that otherwise one creates an interoperability issue, 
possible future one. RTCP Mux can only work under some restrictions 
regarding the Payload Type (PT) assignment. A gateway between an 
endpoint doing mux and one not doing it will thus have be capable of 
rewriting PTs. As PTs sometimes have been included in RTCP formats, that 
requires the Gateway to understand and be capable of rewriting them. 
Thus, the gateway MUST understand everything that goes into the RTCP 
packet. This requirement prevents changes or additions to RTCP across 
gateways as it means that also the gateway has to be updated, not only 
having the capability in both endpoints. It also increases the 
complexity of the gateway.

Cheers

Magnus

Den 2015-08-07 kl. 23:39, skrev Peter Thatcher:
> #1.  Further, I'm guessing that most people who wanted #2 could live
> with #1.
>
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Aug 2015 15:53:41 -0700

On Sun, Aug 16, 2015 at 12:24 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> I am on vacation and just happened to see this. I will not follow up on on
> this until I am back in 1.5 weeks time (27th of Aug). So I do request that
> no conclusions are made until after I have had time to follow up on the
> discussion.
>
> important for a WebRTC endpoint to support the non-muxed mode for RTP and
> RTCP. Yes, this was discussed 3 years back and motivated. I think the
> interim in Stockholm is when we made this decision.
>

​There are meaningful differences between then and now that made this
discussion appropriate:

1.  DTLS is mandatory.

2.  At IETF 93, Cullen said he looked into it thoroughly and found that
every endpoint that he could find that can speak DTLS can also speak
RTCP-mux.

3.  Our multi-year implementation experience is that RTCP non-mux has a
very significant code complexity cost.

> regarding the Payload Type (PT) assignment. A gateway between an endpoint
> doing mux and one not doing it will thus have be capable of rewriting PTs.
> As PTs sometimes have been included in RTCP formats, that requires the
> Gateway to understand and be capable of rewriting them. Thus, the gateway
> MUST understand everything that goes into the RTCP packet. This requirement
> prevents changes or additions to RTCP across gateways as it means that also
> the gateway has to be updated, not only having the capability in both
> endpoints. It also increases the complexity of the gateway.
>
>
​Please correct me if I'm wrong, but I believe this is only a problem if
the RTP endpoints choose PTs in the range 64-95.  RFC 5761 says "for the
choice of RTP payload type values ... values in the range 64-95 MUST NOT be
used".  If so, are we really only concerning ourselves with code complexity
for gateways that speak to RTCWEB endpoints one end and legacy RTP
endpoints that don't follow 5761 on the other end?

If it's a question of "possible future" code complexity in gateways versus
very real code complexity that is slowing down RTCWEB implementations
today, I'm in favor of removing the real code complexity we have now and
taking the chance on the possible future code complexity, because it's a
very real possibility that possible future code complexity will never be
necessary.   In the end, it might be easier to just not choose PTs inside
the range 64-95.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Aug 2015 11:16:28 +0200

On 08/18/2015 12:53 AM, Peter Thatcher wrote:
<snip>
> .
>
>  
>
>     The reason is why I see it is as very important that WebRTC
>     endpoints support non-mux is that otherwise one creates an
>     interoperability issue, possible future one. RTCP Mux can only
>     work under some restrictions regarding the Payload Type (PT)
>     assignment. A gateway between an endpoint doing mux and one not
>     doing it will thus have be capable of rewriting PTs. As PTs
>     sometimes have been included in RTCP formats, that requires the
>     Gateway to understand and be capable of rewriting them. Thus, the
>     gateway MUST understand everything that goes into the RTCP packet.
>     This requirement prevents changes or additions to RTCP across
>     gateways as it means that also the gateway has to be updated, not
>     only having the capability in both endpoints. It also increases
>     the complexity of the gateway.
>
>
> ​Please correct me if I'm wrong, but I believe this is only a problem
> if the RTP endpoints choose PTs in the range 64-95.  RFC 5761 says
> "for the choice of RTP payload type values ... values in the range
> 64-95 MUST NOT be used".  If so, are we really only concerning
> ourselves with code complexity for gateways that speak to RTCWEB
> endpoints one end and legacy RTP endpoints that don't follow 5761 on
> the other end? 
>
> If it's a question of "possible future" code complexity in gateways
> versus very real code complexity that is slowing down RTCWEB
> implementations today, I'm in favor of removing the real code
> complexity we have now and taking the chance on the possible future
> code complexity, because it's a very real possibility that possible
> future code complexity will never be necessary.   In the end, it might
> be easier to just not choose PTs inside the range 64-95.

I believe the conclusion of Cullen's review was that there was no
implementation that offered ICE and not RTCPMUX. Thus, anything that
creates issues must come in via a gateway.

For argument's sake, let's say it's a gateway where the non-WebRTC side
is using SDP offer/answer.

In the case where the offer comes from WebRTC, there is no problem; the
WebRTC-generated offer will never contain PT values in the range 64-95,
and therefore the answer will not either.

In the case where the offer comes from the other side, there are two cases:

- Offer contains RTCPMUX, and does not use PT values in the 64-95 range.
Not A Problem.
- Offer does not contain RTCPMUX, but does not use PT values in the
64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets
during the call. Not A Problem.
- Offer does not contain RTCPMUX, and uses PT values in the 64-95 range.
This may be a problem.

A protocol-valid implementation choice is for the gateway to strip out
those PT values from the offer. This will likely result in an useless
offer (because the payload one wants to send can't be sent).

If the "outside" system is able to handle a reversing of the
offer/answer direction, a valid response is to reject the outside offer
and let the gateway construct a counteroffer without the "wrong" PT values.

If the "outside" system isn't able to do so, AND the gateway isn't
capable of doing the RTCP manipulation that Magnus alludes to, the offer
just has to be rejected at the gateway.

How important is this case?
And over time - will this case become more or less important?
(My bet is on "less important" - any new product will have RTCPMUX from
the get-go. I could be wrong.)

Harald

---

From: Tim Panton <[email-masked]>
Date: Tue, 18 Aug 2015 10:28:36 +0100

> On 18 Aug 2015, at 10:16, Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> The reason is why I see it is as very important that WebRTC endpoints support non-mux is that otherwise one creates an interoperability issue, possible future one. RTCP Mux can only work under some restrictions regarding the Payload Type (PT) assignment. A gateway between an endpoint doing mux and one not doing it will thus have be capable of rewriting PTs. As PTs sometimes have been included in RTCP formats, that requires the Gateway to understand and be capable of rewriting them. Thus, the gateway MUST understand everything that goes into the RTCP packet. This requirement prevents changes or additions to RTCP across gateways as it means that also the gateway has to be updated, not only having the capability in both endpoints. It also increases the complexity of the gateway.
>> 
>> 
>> ​Please correct me if I'm wrong, but I believe this is only a problem if the RTP endpoints choose PTs in the range 64-95.  RFC 5761 says "for the choice of RTP payload type values ... values in the range 64-95 MUST NOT be used".  If so, are we really only concerning ourselves with code complexity for gateways that speak to RTCWEB endpoints one end and legacy RTP endpoints that don't follow 5761 on the other end? 
>> 
>> If it's a question of "possible future" code complexity in gateways versus very real code complexity that is slowing down RTCWEB implementations today, I'm in favor of removing the real code complexity we have now and taking the chance on the possible future code complexity, because it's a very real possibility that possible future code complexity will never be necessary.   In the end, it might be easier to just not choose PTs inside the range 64-95.
> 
> I believe the conclusion of Cullen's review was that there was no implementation that offered ICE and not RTCPMUX. Thus, anything that creates issues must come in via a gateway.
> 
> For argument's sake, let's say it's a gateway where the non-WebRTC side is using SDP offer/answer.
> 
> In the case where the offer comes from WebRTC, there is no problem; the WebRTC-generated offer will never contain PT values in the range 64-95, and therefore the answer will not either.
> 
> - Offer contains RTCPMUX, and does not use PT values in the 64-95 range. Not A Problem.
> - Offer does not contain RTCPMUX, but does not use PT values in the 64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets during the call. Not A Problem.
> - Offer does not contain RTCPMUX, and uses PT values in the 64-95 range. This may be a problem.
> 
> A protocol-valid implementation choice is for the gateway to strip out those PT values from the offer. This will likely result in an useless offer (because the payload one wants to send can't be sent).
> 
> If the "outside" system is able to handle a reversing of the offer/answer direction, a valid response is to reject the outside offer and let the gateway construct a counteroffer without the "wrong" PT values.
> 
> If the "outside" system isn't able to do so, AND the gateway isn't capable of doing the RTCP manipulation that Magnus alludes to, the offer just has to be rejected at the gateway.
> 
> (My bet is on "less important" - any new product will have RTCPMUX from the get-go. I could be wrong.)

Agreed. What’s more the gateway can always be configured to work around the problem by:
a) transcoding - the chances are that such a gateway is probably capable of transcoding from amr-wb to opus (or similar) - it can transcode and
fix the pt value as a side effect.
b) just re-write the the ptype - in effect transcoding from ulaw to ulaw but updating the ptype. 
(If I remember correctly we wrote a gateway that did this 3 years ago).

Tim.

> [email-masked] <mailto:[email-masked]>

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 18 Aug 2015 12:40:03 +0000

Concur to the evaluation of Tim, Harald and Cullen.
The media plane WebRTC gateway provides a specific “RTP topology” for the interworking of all RTP-based WebRTC service components.
Either an
a) RTP Media Translator (RTPMT) or Back-to-Back RTP Endsystem (B2BRE) in case of media processing (such as transcoding)
=> no issue
b) RTP Transport Translator (RTPMT) (which may be also covered by a Back-to-Back RTP Endsystem (B2BRE))
=> no issue (because PT mapping is included in this mode)
or
c) RTP Transparent Forwarding (TF) …

The particular RTP topology depends on the two “RTP profiles” applied in the WebRTC and non-WebRTC domain.
The selected RTP topology is media-type dependent, i.e. there’ll be a specific RTP topology for audio and video (“and both might be different”).

Thus, also fail to see any real issues,
Albrecht

From: rtcweb [mailto:[email-masked]] On Behalf Of Tim Panton
Sent: Dienstag, 18. August 2015 11:29
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

On 18 Aug 2015, at 10:16, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

.

Tim.

Harald

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk<http://www.westhawk.co.uk>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Aug 2015 07:35:32 -0700

> (My bet is on "less important" - any new product will have RTCPMUX from the get-go. I could be wrong.)

[BA] The case you describe *could* be encountered in a situation where each simulcast/SVC stream in a conference needed to use a distinct payload type. Luckily, no conferencing system I am aware of uses PTs in that profligate way (multiplexing by SSRC is much more common) - though the suggestion has now been introduced into the WEBRTC WG.

As the old joke says:

Patient: It hurts when I do this.
Doctor: Then don't do that.

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 18 Aug 2015 10:23:21 -0700

On Tue, Aug 18, 2015 at 7:35 AM, Bernard Aboba <[email-masked]>
wrote:

> [BA] The case you describe *could* be encountered in a situation where
> each simulcast/SVC stream in a conference needed to use a distinct payload
> type. Luckily, no conferencing system I am aware of uses PTs in that
> profligate way (multiplexing by SSRC is much more common) - though the
> suggestion has now been introduced into the WEBRTC WG.
>
> As the old joke says:
>

​That's exactly the joke I think of whenever someone says "but what about
PTs in the range 64-95?"​.

I hope someday (soon?) that joke will apply to non-muxed RTCP.

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Aug 2015 14:34:28 -0500

On 8/18/15 9:35 AM, Bernard Aboba wrote:
> [BA] The case you describe*could*  be encountered in a situation where each simulcast/SVC stream in a conference needed to use a distinct payload type. Luckily, no conferencing system I am aware of uses PTs in that profligate way (multiplexing by SSRC is much more common) - though the suggestion has now been introduced into the WEBRTC WG.

You misspelled "MMUSIC."

/a