- 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