W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2016

RE: Should setting an answer modify RTCRtpTransceiver.direction?

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Tue, 1 Nov 2016 22:18:02 +0000
To: Taylor Brandstetter <deadbeef@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <SN1PR21MB00148A6B90FD99FCBD39F800ECA10@SN1PR21MB0014.namprd21.prod.outlook.com>
This seems like a good topic for the upcoming virtual interim.

Looking through the latest version of JSEP, it is unclear whether setLocal/setRemoteDescription can change the value of transceiver.direction to something other than what was set by transceiver.setDirection().  However, it does appear that the direction indicated in an Answer may not correspond to what was indicated in transceiver.setDirection().  Having the directionality change with no corresponding change to the object model seems strange.

For example, JSEP Section 5.3.1 says:


   o  A direction attribute, determined by applying the rules regarding

      the offered direction specified in [RFC3264], Section 6.1<https://tools.ietf.org/html/rfc3264#section-6.1>, and

      then intersecting with the direction of the associated

      RtpTransceiver.  For example, in the case where an m= section is

      offered as "sendonly", and the local transceiver is set to

      "sendrecv", the result in the answer is a "recvonly" direction.


From: Taylor Brandstetter [mailto:deadbeef@google.com]
Sent: Tuesday, November 1, 2016 2:08 PM
To: public-webrtc@w3.org
Subject: Should setting an answer modify RTCRtpTransceiver.direction?

Here's an example to illustrate the point:

transceiver.setDirection("sendrecv");
// ...
pc.setLocalDescription(sendRecvOffer);
// ...
pc.setRemoteDescription(recvOnlyAnswer);
// What is transceiver.direction now? "sendrecv" or "sendonly"?

Has this question already been decided? If not, it's probably something we should cover at the upcoming virtual interim.
Received on Tuesday, 1 November 2016 22:18:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC