Subject: [rtcweb] JSEP: When the "current direction" changes

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Nov 2016 15:13:11 -0800

According to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3) setDirection()
does not take effect immediately:

"The setDirection method sets the direction of the RTCRtpTransceiver. Calls
to setDirection() do not take effect immediately. Instead, future calls to
createOffer and createAnswer mark the corresponding media description as
sendrecv, sendonly, recvonly or inactive as defined in [JSEP] (section
5.2.2. and section 5.3.2.). Calling setDirection() sets the
negotiation-needed flag."

My understanding is that setDirection immediately sets the
transceiver.direction attribute, but that the "current direction" (distinct
from the direction attribute) is only changed by calls to
setLocal/setRemoteDescription.

The question is when the "current direction" changes, and how this relates
to the direction expressed in the currentLocalDescription and
currentRemoteDescription.  Some concrete examples:

Example 1

   1. The direction provided in the currentLocalDescription (e.g. the
   "current direction") is "sendrecv" and setDirection("recvonly") is called.
   Since setDirection does not change currentLocalDescription, the RtpSender
   does not stop sending, correct?
   2. createOffer() is called. A "recvonly" offer is generated.
   3. setLocalDescription(RecvOnlyOffer) is called. Now the direction in
   pendingLocalDescription changes to "recvonly", but the direction in
   currentLocalDescription is still "sendrecv".  The RtpSender still does not
   stop sending, correct?
   4. setRemoteDescription(SendOnlyAnswer) is called. Now the direction in
   currentLocalDescription is "recvonly".  So, the RtpSender will now stop
   sending, right?

Example 2

   1. The value of transceiver.direction is "sendrecv" and a "sendonly"
   offer is received so that setRemoteDescription(SendOnlyOffer) is called.
   Since this does not change currentLocalDescription (still "sendrecv"), the
   RtpSender does not stop sending, correct?
   2. createAnswer() is called.  A "recvonly" answer is generated.
   RtpSender is still sending.
   3. setLocalDescription(RecvOnlyAnswer) is called. Now the direction in
   currentLocalDescription changes to "recvonly", so the RtpSender stops
   sending, right?

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 11 Nov 2016 16:55:43 -0800

I'd expect the new "currentDirection" attribute to represent the direction
in the last applied answer. So it would only change in the last step of the
two examples.

However, I don't think there's a 1:1 mapping between currentDirection and
"is sender sending/is receiver receiving". After a sendrecv or recvonly
offer is applied, we MUST be prepared to receive media, before an answer is
received. And I'd somewhat expect that after a recvonly or inactive offer
is applied, we should stop sending media (step 3 of example 1; Chrome
currently works this way). Though I can't find anything explicitly stating
this in RFC3264.

On Fri, Nov 11, 2016 at 3:13 PM, Bernard Aboba <[email-masked]>
wrote:

> According to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3)
> setDirection() does not take effect immediately:
>
> "The setDirection method sets the direction of the RTCRtpTransceiver.
> Calls to setDirection() do not take effect immediately. Instead, future
> calls to createOffer and createAnswer mark the corresponding media
> description as sendrecv, sendonly, recvonly or inactive as defined in
> [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets the
>    4. setRemoteDescription(SendOnlyAnswer) is called. Now the direction
>    in currentLocalDescription is "recvonly".  So, the RtpSender will now stop
>    sending, right?
>
>
> Example 2
>
>
>    offer is received so that setRemoteDescription(SendOnlyOffer) is
>    called. Since this does not change currentLocalDescription (still
>    "sendrecv"), the RtpSender does not stop sending, correct?
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>