Contradictory RTP/RTCP mux settings #185

Closed
aboba opened this Issue Apr 1, 2015 · 2 comments

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Apr 1, 2015

Currently whether RTP/RTCP mux is in use or not is indicated in several different ways:

1.For RtpSender/RtpReceiver objects, the constructor requires a DtlsTransport for RTP and (optionally) one for RTCP. Similarly, setTransport requires a DtlsTransport for RTP and (optionally) one for RTCP.

2.For the IceTransport object, an RTCP transport can be created via createAssociatedTransport, and can be stopped via .stop().

3.For receiver.receive(parameters) and sender.send(parameters), parameters.rtcp.mux can be set to true (for RTP/RTCP mux) or false (if not multiplexing RTP and RTCP).

Currently the specification does not rule out contradictory RTP/RTCP mux settings, such as:

a. Calling receiver.receive with parameters.rtcp.mux = false while receiver.rtcpTransport is not set (telling receive you don't want to multiplex while having no RTCP DtlsTransport specified to allow that to work).

b. Calling sender.send with parameters.rtcp.mux = false while sender.rtcpTransport is not set (telling send you don't want to multiplex while having no RTCP DtlsTransport specified to allow that to work).

c. Calling receiver.receive with parameters.rtcp.mux = false after receiver.rtcpTransport.transport.stop() has been called (telling receive you don't want to multiplex after the RTCP Ice Transport has been stopped).

d. Calling sender.send with parameters.rtcp.mux = false after sender.rtcpTransport.transport.stop() has been called (telling send you don't want to multiplex after the RTCP Ice Transport has been stopped).

These contradictory situations should be clearly specified and the appropriate exceptions or errors should be indicated.

@aboba aboba added the 1.1 label Apr 1, 2015
@aboba
Contributor
aboba commented Apr 6, 2015

If an RTCRtpSender or RTCRtpReceiver object is constructed with only a single RTP transport, then calling send(parameters) or receive(parameters) with parameters.rtcp,mux set to false will cause an InvalidParameters exception to be thrown.

If it is desired to transition between RTP/RTCP multiplexing and non-mux, then setTransport() should be called with both an RTP and RTCP transport, then send(parameters) or receive(parameters) can be called with parameters.rtcp.mux set to false to cause the RTCP transport to be used.

@aboba
Contributor
aboba commented Apr 6, 2015

Here is the specific text:

In Section 6.3.2, add:

send
If rtcpTransport is not set or rtcpTransport.stop() has been called and send(parameters) is called with parameters.rtcp.mux set to FALSE, throw an InvalidParameters exception.

setTransport
If setTransport() is called with a single argument or if rtcpTransport.stop() had previously been called, and the last call to send(parameters) had parameters.rtcp.mux set to FALSE, throw an InvalidParameters exception.

In Section 7.3.2, add:

receive
If rtcpTransport is not set or rtcpTransport.stop() has been called and receive(parameters) is called with parameters.rtcp.mux set to FALSE, throw an InvalidParameters exception.

setTransport
If setTransport() is called with a single argument or if rtcpTransport.stop() had previously been called, and the last call to receive(parameters) had parameters.rtcp.mux set to FALSE, throw an InvalidParameters exception.

@aboba aboba closed this Apr 26, 2015
@robin-raymond robin-raymond pushed a commit that referenced this issue May 7, 2015
Robin Raymond - sender.setTrack() updated to return a Promise, as noted in:
#148

- Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in:
#170

- Clarified handling of incoming DTLS packets, as noted in:
#173

- Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in:
#174

- Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in:
#185

- Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in:
#186

- Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in:
#188

- Added close() method to the RTCIceGatherer object as noted in:
#189

- Clarified behavior of TCP candidate types, as noted in:
#190

- Clarified behavior of iceGatherer.onlocalcandidate, as noted in:
#191

- Updated terminology in Section 1.1 as noted in:
#193

- Updated RTCDtlsTransportState definitions, as noted in:
#194

- Updated RTCIceTransportState definitions, as noted in:
#197
c006197
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment