DTLS Setup Attribute

[SteveG]

Hi,

I have a query regarding the DTLS setup attribute and the behaviour from Chrome when a stream is added, or some modification is made to an existing stream.  We have a couple of scenarios we are running where we establish an audio call between browser and media gateway. ICE is performed, DTLS is negotiated - all is hunky dory.

The media gateway then wants to re-negotiate some SDP attributes (say change from opus to g711).  None of the DTLS attributes are changing, yet when we apply our offer Chrome complains:

setLocalDescriptionOnFailure

Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.

In the renegotiation from the gateway the SDP contains a=setup:passive and the same dtls fingerprint we exchanged initially.  Why does the browser insist the setup role should revert to actpass when we do not need to re-establish DTLS?

Is this just a signaling constraint or does the browser actually expect to re-establish the DTLS association whenever a new offer is applied?

Appreciate your feedback,

Steve

[Philipp Hancke]

https://tools.ietf.org/html/rfc5763#page-9 (first bullet) requires this. Silly but... just munge the SDP if you don't want to modify your gateway. The transport doesn't bother with re-establishing unless the fingerprint changes IIRC

--

---
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/4247287c-6737-4274-9c05-8e29ab2e93f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Gibbard]

Thanks for the quick reply - we can munge the sdp as a work around.  I think the rfc could have been clearer here - the bullet you reference is under a section "Establishing a secure channel" further down the RFC there is a "Session Modification" section which implies you should use the same fingerprints, transport parameters and setup role if you want to use the same connection.

Session Modification

The peers can reuse the existing associations if

   they are compatible (i.e., they have the same key fingerprints and

   transport parameters)

...

Note

   that if the active/passive status of the endpoints changes, a new

   connection MUST be established.

We have run into issues where session modification is causing ICE restarts and DTLS to be re-established (when the gateway is not changing ICE or DTLS related parameters in the SDP).  

Is there a recommended way to handle re-negotiation at the browser?  For instance if we add a video stream mid-session is there a way to avoid ICE and DTLS to be restarted on all streams?

Steve

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/o2O7rMeQCHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiLuCCyHcTwUcONNLOS6oT55k2DtwMfNtkimyM%3DvO8UqVg%40mail.gmail.com.

[Iñaki Baz Castillo]

2016-04-14 18:14 GMT+02:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:

> https://tools.ietf.org/html/rfc5763#page-9 (first bullet) requires this.
> Silly but... just munge the SDP if you don't want to modify your gateway.
> The transport doesn't bother with re-establishing unless the fingerprint
> changes IIRC

Exactly. And to make this clear: the "renegotiator" is mandated to set
"a=setup:passive" and, in case the fingerprint does not change, the
receiver is mandate to select "a=setup:active" or "a=setup:passive" to
keep the original direction of the already established DTLS
connection.

SDP land.

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

[Iñaki Baz Castillo]

2016-04-14 18:37 GMT+02:00 Steve Gibbard <steve....@gmail.com>:
> Is there a recommended way to handle re-negotiation at the browser? For
> instance if we add a video stream mid-session is there a way to avoid ICE
> and DTLS to be restarted on all streams?

This should not be an issue as long as the new video track reuses an
already established ICE+DTLS transport (easier if BUNDLE is enabled).

However, if your server is allocating new transport resources (UDP/TCP
ports, ICE user/passwd) then the browser needs, of course, to
establish such a requested connection.

[Steve Gibbard]

Hi,

The server does allocate new transport ice-ufrag/pwd fingerprint etc for video stream, but leaves the audio attributes as previously negotiated.  It doesn't support Bundle (unfortunately) but since parameters are not changing for the audio stream can't the browser just kick ICE and DTLS for the video stream without affecting audio?

Does it help if the video stream is created using a separate peerConnection rather than have video added to the PC used by audio?

S 

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/o2O7rMeQCHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfk3JgHcbQy3AeEMM9%3Df50KGwqHUfA69hjF5VN043x2yOw%40mail.gmail.com.

[Philipp Hancke]

2016-04-14 18:51 GMT+02:00 Steve Gibbard <steve....@gmail.com>:

Hi,

The server does allocate new transport ice-ufrag/pwd fingerprint etc for video stream, but leaves the audio attributes as previously negotiated.  It doesn't support Bundle (unfortunately) but since parameters are not changing for the audio stream can't the browser just kick ICE and DTLS for the video stream without affecting audio?

Are you adding a new m-line for video? That might require a=setup:actpass on the video m-line while using other things on the audio m-line.

https://bugs.chromium.org/p/webrtc/issues/detail?id=2782 might contain some hints. But that was fixed for M49.

Does it help if the video stream is created using a separate peerConnection rather than have video added to the PC used by audio?

S 

On Thu, Apr 14, 2016 at 5:40 PM, Iñaki Baz Castillo <i...@aliax.net> wrote:

2016-04-14 18:37 GMT+02:00 Steve Gibbard <steve....@gmail.com>:
> Is there a recommended way to handle re-negotiation at the browser?  For
> instance if we add a video stream mid-session is there a way to avoid ICE
> and DTLS to be restarted on all streams?

This should not be an issue as long as the new video track reuses an
already established ICE+DTLS transport (easier if BUNDLE is enabled).

However, if your server is allocating new transport resources (UDP/TCP
ports, ICE user/passwd) then the browser needs, of course, to
establish such a requested connection.


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

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/o2O7rMeQCHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfk3JgHcbQy3AeEMM9%3Df50KGwqHUfA69hjF5VN043x2yOw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---

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/CAE26g8HhQvp9__odrAa%3D-bsE11R3tbfNh6R6-%2BKk6iOG_C5XVg%40mail.gmail.com.

[Taylor Brandstetter]

Philipp is correct. Changing the DTLS attributes for only one media description would have been an issue before, but that should be fixed now.

As long as you use "a=setup:actpass" in the offer, and have the same "a=fingerprint", Chrome should use the same DTLS association.

The "actpass" requirement is currently imposed by JSEP. Though I think the rtcweb working group might have decided to change this at IETF95 last week: https://www.ietf.org/mail-archive/web/rtcweb/current/msg15790.html

So stay tuned...

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiL7W%2B8E13OsekiwW4n1spx%3DT2-g1vNjsKx54kHetfCVgw%40mail.gmail.com.