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

Re: [webrtc-pc] Clarify offerToReceiveAudio and offerToReceiveVideo in renegotiation

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Jun 2017 22:16:47 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-311807928-1498688205-sysbot+gh@w3.org>
`createOffer` uses knowledge of how many transceivers there are in creating the offer.  Sources of that information include `addTransceiver` as well as `transceiver.stop`.  `offerToReceiveAudio`/`offerToReceiveVideo`  is another source. So the question here is how transceivers `createOffer` should assume if `RTCPeerConnection` has no unstopped "sendrecv" or "recvonly" audio/video transceivers.  Presumably if `offerToReceiveAudio`  is not `false` then there is a desire to have an audio m-line, and if `offerToReceiveVideo` is not `false` there is a desire to have a video m-line. `createOffer` could perhaps act as though the `transceiver` existed without creating it, with creation waiting until later (e.g. when SLD is called).  However, that would imply that the developer would need to call `createOffer` and `setLocalDescription` before being able to call transceiver-based methods, including `setParameters`, setCodecPreferences`, etc.  That seems convoluted.

GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1361#issuecomment-311807928 using your GitHub account
Received on Wednesday, 28 June 2017 22:16:53 UTC

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