New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiplexing Requirements #151

aboba opened this Issue Sep 22, 2014 · 3 comments


None yet
3 participants
Copy link

aboba commented Sep 22, 2014

One of the assumptions of WebRTC is that DTLS, STUN/TURN and RTP and/or RTCP can be multiplexed over the same port. The description of how the multiplexing works is contained in draft-petithuguenin-avtcore-rfc5764-mux-fixes yet this document is not referenced in any RTCWEB WG work item.

To make it clear that this draft needs to be implemented, I'd propose to add the following text to Section 2.2:

"In order to enable multiplexing of DTLS and STUN/TURN with RTP and/or RTCP, implementations must support [MUX-FIXES]."

M. Petit-Huguenin; G. Salgueiro. Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS). 2 July 2014. Internet Draft (work in progress). URL:


This comment has been minimized.

Copy link

aboba commented Sep 22, 2014

Since [MUX-FIXES] is not yet a WG work item, a normative reference is probably pre-mature, so how about the following revised-text:

"Since the DTLS negotiation occurs between transport endpoints determined via Interactive Connectivity Establishment (ICE), implementations of this specification MUST support multiplexing of STUN, TURN, DTLS and RTP and/or RTCP. This multiplexing, originally described in [RFC5764] Section 5.1.2, is being revised in [MUX-FIXES]."


This comment has been minimized.

Copy link

ibc commented Sep 22, 2014

It is perfect IMHO.


This comment has been minimized.

Copy link

aboba commented Sep 30, 2014

Also recommend adding the following text to Section 16.1:

Via the use of [BUNDLE] it is possible for WebRTC 1.0 implementations to multiplex audio and video on the same RTP session. Within ORTC API, equialent behavior can be obtained by constructing multiple RTCRtpReceiver and RTCRtpSender objects from the same RTCDtlsTranport object. As noted in [RTP-USAGE] Section 4.4, support for audio/video multiplexing is required, as described in [RTP-MULTI-STREAM].

@aboba aboba reopened this Sep 30, 2014

@aboba aboba closed this Sep 30, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Oct 14, 2014

Robin Raymond
Address questions about RTCDtlsTransport.start(), as noted in: Issue w…

Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue w3c#147
Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue w3c#148
Partially address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue w3c#149
Renamed RTCIceListener to RTCIceGatherer as noted in: Issue w3c#150
Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue w3c#151
Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue w3c#152
Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue w3c#153
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment