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

[Taylor Brandstetter <[e-mail]>]

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 <[e-mail]>
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
> 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?
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>