- From: Cullen Jennings via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Apr 2017 14:51:40 +0000
- To: public-webrtc-logs@w3.org
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. -- GitHub Notification of comment by fluffy Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291524724 using your GitHub account
Received on Tuesday, 4 April 2017 14:51:46 UTC