- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Sun, 18 Jun 2017 15:25:53 +0000
- To: public-webrtc-logs@w3.org
> For example, does the RTCDtlsTransport remain the same and make an (odd) transition back to "new"? I think there should be a new DTLS transport object since the internal keying material on a DTLS transport is immutable once set. Also packets on the old dtls transport still need to be decrypted ( spec pointer from [this old comment](https://github.com/w3c/ortc/issues/93#issuecomment-47406008) [here](https://tools.ietf.org/html/rfc5245#section-9.1.1.1) Ideally at least, getting this use-case 100% seamless might be too ambitious. @taylor-b maybe you have a chance to look at [this bug](https://bugs.chromium.org/p/webrtc/issues/detail?id=5768) again while figuring out how your lib handles this? But creating a new object makes things worse for RTPSender and RTPReceiver: * when does the transport change? Once its up as no media is received on the new transport before then? Note that we do not wait for media initially so I think the answer is "during SLD/SRD". * should there be a way to subscribe to the transport change? I do not see a use-case for that. > If so, does the onstatechange EventHandler for the old RTCDtlsTransport get moved to the new RTCDtlsTransport automagically, or does the application somehow need to figure out that the RTCDtlsTransport has changed and set the EventHandler itself? I think the application should remove and add a statechange listener on _every_ setRemoteDescription. No magic please. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1406#issuecomment-309284141 using your GitHub account
Received on Sunday, 18 June 2017 15:25:59 UTC