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

Re: [webrtc-pc] Should RTCRtpTransceiver.setCodecPreferences() only refer to RTCRtpReceiver.getCapabilities(kind)?

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Thu, 04 Oct 2018 05:43:39 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-426892214-1538631818-sysbot+gh@w3.org>
@Orphis `setCodecPreferences` affects which codecs are included in `createOffer` or `createAnswer`. For this purpose, either `RTCRtpSender.getCapabilities(kind)` or `RTCRtpReceiver.getCapabilities(kind)` may be relevant, depending on the direction indicated (`sendrecv`, etc.). 

With respect to the Offered codecs, RFC 3264 Section 5.1 says: 

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.  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.

For the codecs in the Answer, RFC 3264 Section 6.1 says: 

   For streams marked as recvonly in the answer, the "m=" line MUST
   contain at least one media format the answerer is willing to receive
   with from amongst those listed in the offer.  The stream MAY indicate
   additional media formats, not listed in the corresponding stream in
   the offer, that the answerer is willing to receive.  For streams
   marked as sendonly in the answer, the "m=" line MUST contain at least
   one media format the answerer is willing to send from amongst those
   listed in the offer.  For streams marked as sendrecv in the answer,
   the "m=" line MUST contain at least one codec the answerer is willing
   to both send and receive, from amongst those listed in the offer.
   The stream MAY indicate additional media formats, not listed in the
   corresponding stream in the offer, that the answerer is willing to
   send or receive (of course, it will not be able to send them at this
   time, since it was not listed in the offer).  For streams marked as
   inactive in the answer, the list of media formats is constructed
   based on the offer.  If the offer was sendonly, the list is
   constructed as if the answer were recvonly.  Similarly, if the offer
   was recvonly, the list is constructed as if the answer were sendonly,
   and if the offer was sendrecv, the list is constructed as if the
   answer were sendrecv.  If the offer was inactive, the list is
   constructed as if the offer were actually sendrecv and the answer
   were sendrecv.

-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1998#issuecomment-426892214 using your GitHub account
Received on Thursday, 4 October 2018 05:43:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:07 UTC