Re: DTLS-SDP and JSEP Conflicts

OK, how do we move forward? Silence won’t do it. Can people live with the current text?

(Version –30 was submitted last week, with the ufrag change removed from the list in section 4.)

Regards,

Christer

From: mmusic <[email protected]<mailto:[email protected]>> on behalf of Roman Shpount <[email protected]<mailto:[email protected]>>
Date: Thursday 7 September 2017 at 21:10
To: Eric Rescorla <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla <[email protected]<mailto:[email protected]>> wrote:

Well, to recap, ICE restart can only be initiated by the offerer:
https://tools.ietf.org/rfcmarkup?doc=5245#section-9.2.2

And as we discussed in detail, there's no real way to demux without an ICE restart, so I'm not interested in trying to preserve that case in the situations when it happens to work. In general, the offerer can simply offer a new tls-id if it's willing to accept a new TLS connection. I appreciate that this will also cause a TLS association even when the endpoints haven't changed, but this just doesn't seem like that big a deal.

If you have a specific case in mind that this causes a problem for, I'd need to see a call-flow diagram to understand it.


There are two specific scenarios that concern me:

1. Third Party Call Control

a. End point A is connected to end point B through third party call control agent 3PCC
b. 3PCC sends a request for a new offer to A (using SIP INVITE with no SDP body).
c. End point A sends an offer with ICE restart (required in response to INVITE with no SDP) and existing tls-id
d. 3PCC agent sends this offer as a new call offer to end point C
e. This is a new offer for C, so it sends an answer with a new tls-id to 3PCC
f. 3PCC sends an answer to end point A
g. Since A got an answer with a new tls-id, a new DTLS association is established between A and C

This also has an optional case, when end point C is legacy and it does not send back tls-id attribute, but does send new fingerprint values. I would prefer that new implementations were allowed for the same scenario using tls-id.

Note that in step d, 3PCC can also send the  re-offer back to B, which will result in existing DTLS association reuse. This is very common when session timers are implemented by 3PCC agents.

2. Connection Recovery

a. End point is connected to a service (like conference service) which is comprised from multiple redundant media servers behind a single signaling proxy
b. End point detects a network connectivity disruption via keep-alive timeout
c. End point initiates connection recovery process by generating an offer with ICE restart and existing DTLS association (and media settings) and sends it to the signaling proxy
d. If the network connectivity is restored to the same media server via a different network path, for instance due to client address change, existing DTLS association and media are re-used
e. If connectivity failure was due to media server failure, connectivity is restored but to a different media server. New DTLS  association and media connection is established in this case.

Please note that case d is much less common then case e.

In both cases it is possible to make things work by forcing new tls-id value in the offer. This will result in extra DTLS association, local ICE candidate allocations (which are required if new DTLS association is requested via new tls-id), and new media setup. All of those things will waste resources and more importantly will increase connection setup time.

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic