Re: DTLS-SDP and JSEP Conflicts

On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla <[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