W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] offerToReceive* legacy behaviour spec does not match the behaviour of legacy implementations

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Jun 2017 10:24:10 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-308691938-1497522249-sysbot+gh@w3.org>
JSEP unfortunately does not cover offerToReceive anymore. From 5.2.1:
```
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. This is done in the order the RtpTransceivers were added to the PeerConnection.
```
This suggests to me that createOffer operates on the pc state and we can not generate an m= line without a transceiver.

One way to wiggle around this is to say that createOffer({offerToReceive}) calls the createOffer algorithm with a set of transceivers which in this case does not match the pcs set of transceivers.
And then use a internal slot for the last offer created and its set of transceivers (potentially just the extra transceivers not part of the normal state). Calls to SLD would then act upon that set.

Such a rabbithole...

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1383#issuecomment-308691938 using your GitHub account
Received on Thursday, 15 June 2017 10:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:44 UTC