- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Feb 2024 18:09:06 +0000
- To: public-webrtc-logs@w3.org
@henbos The fundamentals are laid out in RFC 3264 Section 5.1: "For a sendonly stream, the offer SHOULD indicate those formats the offerer is willing to send for this stream. For a recvonly stream, the offer SHOULD indicate those formats the offerer is willing to receive for this stream. For a sendrecv stream, the offer SHOULD indicate those codecs that the offerer is willing to send and receive with." Based on this, the statement about SCP in JSEP 4.2.6 is correct for recv-only and send-recv m-lines, but I do not believe that it is correct for send-only m-lines. Some notes: 1. A sendonly transceiver can only offer codecs/profiles that can be sent (send-only or send/recv) a. In a situation where the browser can send at a different profile/level than it can receive, the send profile is used. 2. A sendrecv transceiver to offer sendrecv codecs/profiles, but not sendonly or recvonly codecs. a. In a situation where the browser can send at a different profile/level than it can receive, the lower of the profiles is used. 3. A recvonly transceiver can only offer codecs/profiles that can be received (recv-only or send/recv) a. In a situation where the browser can send at a different profile/level than it can receive, the receive profile is used. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2939#issuecomment-1946816698 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 February 2024 18:09:09 UTC