[FS-10258] keep previously negotiated DTLS role during SIP re-INVITE Created: 21/Apr/17  Updated: 05/Jun/17  Resolved: 24/Apr/17

Status: Resolved
Project: FreeSWITCH
Component/s: mod_sofia
Affects Version/s: None
Fix Version/s: 1.6.18, 1.8

Type: Bug Priority: Minor
Reporter: Iñaki Baz Castillo Assignee: Mike Jerris
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File fs-changes-dtls-role-during-reinvite.txt    
Issue Links:
Duplicate
is duplicated by FS-10350 Role conflict and session termination... Closed
FreeSWITCH GIT Revision: acdf1d93dbf
GIT Master Revision hash:: acdf1d93dbf

 Description   
In a WebRTC call, FS does not respect the DTLS role negotiated during the initial SDP O/A.

1) INVITE from FreeSwitch with a=setup:actpass (as per spec).

2) 200 from endpoint with a=setup:active (endpoint becomes DTLS client).

3) Re-INVITE from endpoint with a=setup:actpass (as per spec).

4) 200 from FreeSwitch with a=setup:active.

This is wrong. During the re-INVITE, a=fingerprint, a=ice-ufrag and a=ice-pwd in the SDP have not changeg, so DTLS role MUST be the same as before. But FreeSwitch is clearly becoming DTLS client (a=setup:active). It should set a=setup:passive in the SDP answer.


 Comments   
Comment by Iñaki Baz Castillo [ 21/Apr/17 ]
There have been large discussions in the WebRTC WG regarding DTLS role during SDP renegotiations. The accepted rule (and the one implemented by Chrome and Firefox) is that, during a SDP renegotiation, the DTLS role must be the same as in the initial SDP O/A as far as the a=fingerprint, a=ice-ufrag and a=ice-pwd are the same than before. And they are because, obviously, changing the DTLS role and requiring a new DTLS handshake plus a new SRTP key exchange is absurd.
Comment by Brian West [ 21/Apr/17 ]
Is this something that can be replicated with https://tryit.jssip.net/?
Comment by Iñaki Baz Castillo [ 21/Apr/17 ]
Sure, just register into a FS server and make FS call to JsSIP (so JsSIP becomes DTLS active/client). Then press the hold button in JsSIP.
Comment by Brian West [ 21/Apr/17 ]
Can you provide a link to the section that outlines this in the spec please?
Comment by Mike Jerris [ 21/Apr/17 ]
can you please test and confirm that this works properly against master code if you do a RE-INVITE instead of UPDATE. We think this is an issue just when modifying the media session with UPDATE method instead of an INVITE.
Comment by Iñaki Baz Castillo [ 21/Apr/17 ]
> Can you provide a link to the section that outlines this in the spec please?

AFAIR this is not directly specified by the RFC 5763, but draft-ietf-mmusic-dtls-sdp clearly states it:

In https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24:

-----------------------------------------------------------------------------
3.1. General

   A new DTLS association must be established between two endpoints
   after a successful SDP offer/answer exchange in the following cases:

   o The negotiated DTLS setup roles change; or

   o One or more fingerprint values are modified, added or removed in
      either an SDP offer or answer; or

   o The intent to establish a new DTLS association is explicitly
      signaled using SDP, by changing the value of the SDP 'tls-id'
      attribute defined in this document;


5.3. Generating the Answer

   If an answerer receives an offer that does not require the
   establishment of a new DTLS association, and if the answerer
   determines that a new DTLS association is not to be established, the
   answerer MUST insert an SDP 'tls-id' attribute with the previously
   assigned value in the associated answer. In addition, the answerer
   MUST insert an SDP 'setup' attribute with a value that does not
   change the previously negotiated DTLS roles
-----------------------------------------------------------------------------


Yes, it's legal that an endpoint changes the DTLS role during a SDP renegotiation. But, if you do that:

1) The transport is closed and a new DTLS handshake plus SRTP keys exchange must be done, which means possible RTP interrupt. I don't think you want that.

2) If you had a DataChannel running over the same DTLS transport, it will be disconnected and data may be lost. You don't want that.

3) Both Chrome and Firefox behaves in this way: If the a=fingerprint, a=ice-ufrag and a=ice-pwd don't change during a new SDP O/A, then the same DTLS connection is assumed to be used. Hence, if the DTLS role does not match, the SDP is rejected by the WebRTC engine.

BTW this topic has been discussed in the WebRTC WG so many times with these conclusions.
Comment by Iñaki Baz Castillo [ 21/Apr/17 ]
> can you please test and confirm that this works properly against master code if you do a RE-INVITE instead of UPDATE. We think this is an issue just when modifying the media session with UPDATE method instead of an INVITE.

I'm sorry but I don't have any FS installed. I reported this issue based on a report in the JsSIP mailing list.

BTW if you are interested, you can locally install and test the JsSIP demo. Just follow the steps in the README:

https://github.com/versatica/tryit-jssip

You can change this single line so JsSIP will use re-INVITE rather than UPDATE for "hold":

https://github.com/versatica/tryit-jssip/blob/master/lib/components/Session.jsx#L292
Comment by Mike Jerris [ 21/Apr/17 ]
we are working on this.. for what its worth, it looks like the issue is just how we reply in sdp, we are not actually restarting the dtls... just putting in the wrong string. Working on solution, need to move some logic around as right now we are figuring this out later than we need to in order to put the right thing in the sdp
Comment by Iñaki Baz Castillo [ 21/Apr/17 ]
Yep, I expected that since the same flow works in other JavaScript SIP libraries (that probably just mangle the remote SDP before applying it).
Comment by Alexandr Popov [ 22/Apr/17 ]
> can you please test and confirm that this works properly against master code if you do a RE-INVITE instead of UPDATE. We think this is an issue just when modifying the media session with UPDATE method instead of an INVITE.

actually this sdp is from re-invite
with update i got same situation
Comment by Mike Jerris [ 24/Apr/17 ]
pushed a fix to handle this properly w/ re-invite. The issue with UPDATE is FS-10089.
Comment by Iñaki Baz Castillo [ 24/Apr/17 ]
Nice, thanks a lot.
Generated at Sun Jul 21 00:03:16 CDT 2019 using Jira 8.1.0#801000-sha1:2e1cd1bb771978cda2c5e8f3f10539ab180613f6.