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

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Sep 2015 12:38:31 +0000

Hi,

What is the status on this issue?

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 18. elokuuta 2015 22:34
To: Bernard Aboba; Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 3 Sep 2015 13:37:14 +0000

My understanding is the *current rough consensus* is to go with the following (depending on how many “I agree”+”I am fine with it” answers it got) but hopefully WG chairs can declare the official decision.

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

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, September 03, 2015 8:39 AM
To: Adam Roach <[email-masked]>; Bernard Aboba <[email-masked]>; Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux?

Hi,

Regards,

Christer

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

You misspelled "MMUSIC."

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Sep 2015 15:52:57 +0200

Hi,

I have now reviewed the discussion on this topic. It is not my 
preference to make this change but I don't see a reason preventing one 
to make the change. I also think option 1, is the best one.

However, I do hope that people correctly understands the implication 
this has. In cases when an WebRTC endpoint not supporting non RTCP mux 
talks to a non-WebRTC endpoint using a gateway and that endpoint does 
not support RTCP mux, there are the potential need for translation of 
RTP payload type numbers. If that translation occurs it MUST be stressed 
that it may not only be RTP that needs to be translated, also RTCP. This 
translation needs to occur in the gateway, thus pushing the complexity 
onto this entity.

There exist two RTCP feedback messages that I am aware of that contains 
payload type numbers:
- Reference Picture Selection Indication (RPSI) [RFC4585]
- H.271 Video Back Channel Message (VBCM) [RFC5104]

Please note that RPSI is part of the discussed RTCP feedback messages in 
draft-ietf-rtcweb-rtp-usage.

There may be created new things in the future that also include PT. If 
that occurs this gateway could be a barrier preventing usage. Yes, I 
know that would be only for cases where both the WebRTC and the 
non-WebRTC support that new message type.

Thus, I assume the WG chairs can declare consensus on this change.

Cheers

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: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 3 Sep 2015 17:20:18 +0000

> On Aug 17, 2015, at 4:53 PM, Peter Thatcher <[email-masked]> wrote:
> 
> 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.

Note that was about endpoints and did not include gateways and was said in the context of what we should do for the next version of ICE which will be years from deployment across devices from lots of manufactures.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Sep 2015 10:25:40 -0700

I'm now pretty confused.

What's useful in the near term is to remove rtcpmux from the existing
ICE stacks with existing ICE. If we're not going to do that, then I
don't see a lot of value discussing this.

-Ekr

On Thu, Sep 3, 2015 at 10:20 AM, Cullen Jennings (fluffy) <[email-masked]>
wrote:

> > 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.
>
> Note that was about endpoints and did not include gateways and was said in
> the context of what we should do for the next version of ICE which will be
> years from deployment across devices from lots of manufactures.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Sep 2015 11:45:33 -0700

I may be even more confused than EKR.

I had thought the discussion was about removing the non-mux mandate in
RTP-Usage, not about removing non-mux discussion from RFC 5245bis or any
other document (such as the security doc which IMHO needs to provide more
detailed info on how non-mux would work with DTLS).   After all, the
proposal was to make non-mux support a MAY rather than a MUST NOT.

On Thu, Sep 3, 2015 at 10:25 AM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Sep 3, 2015 at 10:20 AM, Cullen Jennings (fluffy) <
> [email-masked]> wrote:
>
>>
>> Note that was about endpoints and did not include gateways and was said
>> in the context of what we should do for the next version of ICE which will
>> be years from deployment across devices from lots of manufactures.
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Sep 2015 06:38:15 +0000

Hi,

> I had thought the discussion was about removing the non-mux mandate in RTP-Usage, not about removing non-mux discussion from RFC 5245bis or any other 
> document (such as the security doc which IMHO needs to provide more detailed info on how non-mux would work with DTLS). 

One could of course ask whether BUNDLE should also generally (not only within an RTCWEB context) mandate usage of mux, but that discussion belongs to MMUSIC.

  After all, the proposal was to 
> make non-mux support a MAY rather than a MUST NOT. 

Is there really any advantage with MAY instead of MUST NOT? If browsers aren't going to implement non-mux anyway, there is very little reason why other types of devices should do it...

Regards,

Christer

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Sep 2015 23:57:40 -0700

> Is there really any advantage with MAY instead of MUST NOT? If browsers aren't going to implement non-mux anyway, there is very little reason why other types of devices should do it...

[BA] For browser vendors the desire is to remove non-mux or not support it in the first place. 

However, non-mux is not an imminent threat to security or stability which according to RFC 2026 would justify a MUST NOT, it just adds complexity without enough usage in WEBRTC applications to justify the cost. So it is likely to become extinct on its own (like the dodo bird) rather than requiring an eradication campaign (like smallpox).