- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Feb 2019 08:40:35 +0000
- To: public-webrtc-logs@w3.org
Indices in the transceiver list don't match the SDP m-line index in general (it does at the time of initial generation of the SDP offer, but given that the indices are in the order in which transcevers were added to the list, transceivers that were created prior to generating an answer won't be slotted into corresponding m-line indexes, and the rules for recycling m-sections also mean that the indices don't match. Until @jan-ivar updated the transceiver list getter to require time-of-addition order (so that it was stable), it was legal to return the list in m-line-index order, presumably with loose transceivers at the end; this meant that getTransceivers() called before and after a negotiation could give back different orders even if no transceivers were stopped; this is now illegal (and needs test). I'm happy to throw stopped transceivers out of the list, since I think referring to them by list index is foolish anyway; note that if the app has stored references to them, that doesn't mean the objects disappear. Aboba's comment refers to stopping the receiver's track, not stopping the transceiver (which stops both sending and receiving, and triggers negotiation-needed). -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2092#issuecomment-459647833 using your GitHub account
Received on Friday, 1 February 2019 08:40:36 UTC