how is an ice restart done?

i'm pondering about implementing ICE restarts in adapter.

The basic sequence of events in webrtc 1.0 terms is as follows:
    <negotiate intial connection>
    call createOffer({iceRestart: true})

On the offerer side this will create a new ICE gatherer and a new ICE 
transport. The remote side answers, candidates are exchanged and 
eventually the new ICE transports state will go to connected/completed.
At that point, media should switch to the new path (I've heard that ice 
restarts follow a make-before-break principle so the old path must be 
kept open and used until the new one is found).

Typically (*) this should not affect the DTLS transport and there should 
not be a DTLS handshake.

Now... how do I change the ICE transport a RTCPRtpSender is using?
RTCRtpSender has a setTransport method:
     http://draft.ortc.org/#rtcrtpsender-interface-definition*
It takes a DTLSTransport however. And I do not want to change the DTLS 
transport and this should not (typically; unless the remote fingerprint 
changed) affect the DTLSTransport.

It seems that the RTCDtlsTransport defined in
      http://draft.ortc.org/#rtcdtlstransport-interface-definition*
is missing a way to change the ICE transport similar to what exists for 
the RTPSender and the DTLSTransport.
Another way would be to extend RTCRtpSender.setTransport to take an 
ICETransport but that would violate layers imo.


[*] there is also the less common case that the DTLS transport can
     change when the remote fingerprint changes. In that case it would
     be perfectly valid to create a new DTLS Transport upon receiving
     the remote description and then replace the dtls transport.

Received on Sunday, 5 March 2017 10:51:26 UTC