Re: [webrtc-pc] strawman text to show how unverified media would work

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