W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

Re: [webrtc-pc] addTransceiver woes

From: stefan hakansson via GitHub <sysbot+gh@w3.org>
Date: Thu, 04 Jan 2018 12:59:47 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-355276230-1515070786-sysbot+gh@w3.org>
>> From a different angle, why do we require negotiation for this:
>>
>> ```
>> const pc = new RTCPeerConnection();
>> const transceiver = pc.addTransceiver('audio');
>> // ... negotiate (so the transceiver becomes associated)
>> pc.addTrack(someAudioTrack, someStream);
>> ```
>>
>> which, presumably, would reuse the transceivers sender.
>
>@fippo It would not, because it fails the following test for re-use:
>
>*"The sender has never been used to send. More precisely, the [[CurrentDirection]] slot of the >RTCRtpTransceiver associated with the sender has never had a value of `sendrecv` or >`sendonly`."*

However, if `const transceiver = pc.addTransceiver('audio' {direction="inactive"});` (or "recvonly") could be used by `addTrack`, right? Also, if the signaling state has not left `stable` (i.e. no `setLocal` since `addTransceiver` the [[CurrentDirection]] slot would be null.

-- 
GitHub Notification of comment by stefhak
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1662#issuecomment-355276230 using your GitHub account
Received on Thursday, 4 January 2018 12:59:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:58 UTC