- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 1 Apr 2015 17:27:27 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
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.
Received on Wednesday, 1 April 2015 17:27:57 UTC