3 comments on “Avoiding Contact Center IVR Hell with WebRTC

  1. Excellent job of laying the foundation and building on it. I found your article extremely easy to follow. Can a contact center using provider “A” for their IP Toll Fee use provider “B” to handle RTC incoming traffic?

    • Dave: There’s nothing stopping a contact center from having separate SIP trunks for IP Toll Free, and for WebRTC traffic that has been converted into regular SIP/RTP via a gateway that’s delivered as a Platform-as-a-Service (PaaS).

      Let’s assume that our PaaS provider is hosting the signaling and media gateways. If you look at the second diagram in the post above, you’ll see that the signaling gateway interacts with the contact center’s web portal. What’s required here is for the PaaS to provide a secure API so that the web portal can allocate an identity (that is, a SIP URI) for the WebRTC caller, and request a token for the session.

      When the RTC session is set up, the PaaS provider is going to have an SBC on their end of the SIP trunk, and the contact center will have their own. If the IP Toll Free provider also supplies an SBC as managed CPE, then most likely you will have to supply your own SBC for the WebRTC sessions.

  2. Nice article. Everyone is on the WebRTC bandwagon, it would seem. But I have been unable to find a vendor or solution which allows for basic call switching functionality of a WebRTC video call (i.e transfer to another agent). Is there a technical component I am missing which would explain this limitation?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.