- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Apr 2017 17:43:49 +0000
- To: public-webrtc-logs@w3.org
Cullen, Can you please explain what does it mean "second TLS connection is happening within that TLS context"? As far as I know, to establish second or any new DTLS association you need to do an ICE restart. You cannot have two DTLS associations over the same underlying transport (5-tuple) since you cannot de-mux DTLS packet. If you do the ICE-restart and get consent for a new 5-tuple, you need a complete offer/answer exchange before you can send data in both directions, which means fingerprints for both end points are available before DTLS association is established. I do think your problem is real, but the early media gets stuck on the SBC with no way to send it to the WebRTC end point since DTLS session is not running yet. So, this is an SBC problem, not a WebRTC end [point problem. Regards, _____________ Roman Shpount On Tue, Apr 4, 2017 at 10:51 AM, Cullen Jennings <notifications@github.com> wrote: > Imagine a browser sends offer to a SBC like thing. The SBC sends PR answer > that sets up just a data connection. At this point ICE comes up and a TLS > session comes up. Now the SBC forwards the offer as a SIP invite to a PSTN > GW calling 1-800-go-fedex which sets up a second TLS connection but that > media packets for this are relayed via the SBC. So the first PR answer set > up the ICE. The second TLS connection is happening within that TLS context. > The PSTN GW completes the ICE handshake, and then starts sending the one > way media with IVR prompts from fedex as ringback tone. At the point that > it needs to go two way, the PSTN GW sends a 200 with answer which the SBC > translates into answer with the fingerprint of the PSTN GW to send to the > browser. If the browser discards this media, it looses the initial prompt. > Note that the browser gets the fingerprint and knows who it is talking to > *before* it needs to send any media or DTMF. This case would likely work > if you buffered all the media and only played it once the fingerprint > arrived because the IVR would just wait at the prompt till the person had > listened to the buffered media and pressed 1. But the browser would need to > speed up the playback or it could never catch up. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291524724>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AEh5SsM78TPKmUrAYx88KRUyTS8QypBGks5rslj6gaJpZM4L-hgv> > . > -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291577433 using your GitHub account
Received on Tuesday, 4 April 2017 17:43:55 UTC