- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Sep 2020 08:08:14 +0000
- To: public-webrtc-logs@w3.org
An unassociated stopped transceiver won't have any effect on outgoing offers, according to JSEP: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.1 (Initial offers) "The next step is to generate m= sections, as specified in [RFC4566], Section 5.14. An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped RtpTransceivers" 5.2.2 Subsequent offers o If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it. This prevents adding back RtpTransceivers whose m= sections were recycled and used for a new RtpTransceiver in a previous offer/ answer exchange, as described above. If we add the words "if the transceiver is not associated with a media section, remove it from the set of transceivers" to the procedure for transceiver.stop(), I think we end up in a less confusing place. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2576#issuecomment-696572432 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 September 2020 08:08:16 UTC