- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Mon, 21 Oct 2019 16:38:56 +0000
- To: public-webrtc@w3.org
aboba has just created a new issue for https://github.com/w3c/webrtc-pc: == Section 4.4.1.6: Set the RTCSessionDescription (Object visibility) == Section 4.4.1.6 specifies when the DtlsTransport and IceTransport objects become visible to JS. The specified behavior does not appear to be implemented in any browser. In Bullet 9, sub-bullet 1, it is stated: "9. If description is not null, then run the following steps: 1. If remote is false, then run the following steps for each media description in description: 1. If the media description is not yet associated with an RTCRtpTransceiver object then run the following steps: ... If the media description is indicated as using an existing media transport according to [BUNDLE], let transport and rtcpTransport be the RTCDtlsTransport objects representing the RTP and RTCP components of that transport, respectively. Otherwise, let transport and rtcpTransport be newly created RTCDtlsTransport objects, each with a new underlying RTCIceTransport. If RTCP multiplexing is negotiated according to [RFC5761], or if connection's RTCRtcpMuxPolicy is require, do not create any RTCP-specific transport objects, and instead let rtcpTransport be null. Set transceiver.[[Sender]].[[SenderTransport]] to transport. Set transceiver.[[Sender]].[[SenderRtcpTransport]] to rtcpTransport. Set transceiver.[[Receiver]].[[ReceiverTransport]] to transport. Set transceiver.[[Receiver]].[[ReceiverRtcpTransport]] to rtcpTransport." [BA] If I read this correctly, calling addTrack() and examining the resulting transceiver object should show transceiver.sender.transport, transceiver.sender.iceTransport, transceiver.receiver.transport, transceiver.receiver.transport,iceTransport being non-null. This is not observed. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2338 using your GitHub account
Received on Monday, 21 October 2019 16:38:58 UTC