setLocalDescription: fails expecting setup:actpass when renegotiation

[mparis]

Hello,
we have noticed that Chrome fails when the remote peer's SDP offer has the "a=setup:active" attribute in the second SDP negotiation.

The steps in the negotiation are:
First negotiation
Chrome PeerConnection offers the next SDP:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
...
a=setup:actpass
...
m=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98
...
a=setup:actpass

and the SDP answer of the peer is:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 0
...
a=setup:active
...
m=video 9 UDP/TLS/RTP/SAVPF 100
...
a=setup:active

Second negotiation
The peer offers the next SDP:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 0
...
a=setup:active
...
m=video 9 UDP/TLS/RTP/SAVPF 100
...
a=setup:active

Chrome PeerConnection creates the next SDP answer:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 0
...
a=setup:passive
...
m=video 9 UDP/TLS/RTP/SAVPF 100
...
a=setup:passive

Then, we it is set as local description, we have the next error:
setLocalDescriptionOnFailure
    Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.

If I am not wrong, it should work fine because the setup value of the second SDP offer is correct, shouldn't it?

Best!!

[Justin Uberti]

per https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#page-34, actpass must be used. However, this is an open topic of discussion.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/811556cb-5593-455d-9aa3-88c669fae11a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mparis]

Thanks for the reference!!

Is there any link to see the discussion and can participate?

[mparis]

Hello again Justin,
recently we have come across a problem related to that in the interoperability with Firefox [1].

After that, I think that the next text from RFC 5763 section-5 is only referring to the first negotation and is not taking into account the renegotiation case, where the "a=setup" value MAY be the same that the previously role set (unless the User Agent aims to change the DTLS-SRTP role, which is not commonly desired to avoid starting a new DTLS handshake)

   o  The endpoint MUST use the setup attribute defined in [RFC4145].
      The endpoint that is the offerer MUST use the setup attribute
      value of setup:actpass and be prepared to receive a client_hello
      before it receives the answer.  The answerer MUST use either a
      setup attribute value of setup:active or setup:passive.  Note that
      if the answerer uses setup:passive, then the DTLS handshake will
      not begin until the answerer is received, which adds additional
      latency. setup:active allows the answer and the DTLS handshake to
      occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
      party is active MUST initiate a DTLS handshake by sending a
      ClientHello over each flow (host/port quartet).

Taking this into account, we should clarify this in JSEP spec, specifically changing this text:

    An "a=setup" line, as specified in [RFC4145], Section 4, and
    clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
    The role value in the offer MUST be "actpass".

Is there an already opened discussion in the IETF mailing list or in another forum?
If yes, could you please refer me to it?

Best!!

Refs
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1323723#c4

[Iñaki Baz Castillo]

2017-01-03 18:19 GMT+01:00 mparis <mpari...@gmail.com>:
> After that, I think that the next text from RFC 5763 section-5 is only
> referring to the first negotation and is not taking into account the
> renegotiation case, where the "a=setup" value MAY be the same that the
> previously role set (unless the User Agent aims to change the DTLS-SRTP
> role, which is not commonly desired to avoid starting a new DTLS handshake)

I don't read that in the RFC 5763. Each SDP O/A party is independent
and must conform to the same rules, no matter whether it is a
renegotiation or not.

Yes, the re-offerer MUST always use "a=setup:actpass" and the
re-answerer is supposed to choose a "a=setup" value matching its role.
This is:

First SDP O/A:

Alice --> actpass --> Bob
Alice <-- active <-- Bob

Second SDP O/A:

Bob --> actpass --> Alice
Bob <-- passive <-- Alice [*]

[*] Alice must choose "passive" so she keeps its previous role.



--
Iñaki Baz Castillo
<i...@aliax.net>

[mparis]

Hello Iñaki,
thanks for your collaboration in the discussion ;).

Your interpretation would be also correct reading RFC5763, but the point is that it is not enough clear (at least from my point of view).
The section-5 (Establishing a Secure Channel) explains how to establish the channel, but what happen if the channel is already established (which is related to SDP renegotiations)?
At this point and from my understanding, subsequences of O/A negotiations (renegotiations) are NOT independent due to some reasons. In relation to "a=setup" attr, and so to the DTLS-SRTP transport using ORTC notation [1]:

• m-lines in Nth negotiation are related to the same m-lines in (N-1)th negotiation.
• New added m-lines belonging to the same BUNDLE group share the same transport.

In these cases, I wouldn't agree that the Nth offer MUST use  setup:actpass, because this can cause a new DTLS handshake wasting resources,. Even some User Agents may not support it.

Moreover, I neither wouldn't agree that the first offer MUST use setup:actpass. In this way we are restricting the interoperability for limited User Agents that only support DTLS client role. Why they cannot announce setup:active from the beginning?

I might have missed some detail behind the decision made in RFC5763 section-5, but I think that these points are reasonable.
Anyway, I am going to open a issue in https://github.com/rtcweb-wg/jsep/issues, where I think this should be discussed.

Best!!

Refs
[1] http://publications.ortc.org/2016/20161202/#rtcdtlstransport*

[mparis]

Issue opened: https://github.com/rtcweb-wg/jsep/issues/448

[nohl...@mozilla.com]

As I noted in the github issue already I think the important reference regarding the usage of setup in JSEP is https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-15#section-5.5
Which in my opinion says roles need to stay the same for renegotiations. Except:

1. 'dtls-id' is being used to request a new DTLS connection
2. ICE restart allows to change roles

But in both cases you would start with setup:actpass again.