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

On Tue, Apr 4, 2017 at 7:51 AM Cullen Jennings <>

> 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.
It's not clear to me what DTLS handshakes are taking place and what
fingerprints the browser sees.  Perhaps if you were more specific about
what remote descriptions come into PeerConnection on what DTLS fingerprints
they have, along with when the DTLS handshakes take place.

> 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
> <>, or mute
> the thread
> <>
> .

GitHub Notification of comment by pthatcherg
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 4 April 2017 20:09:23 UTC