WebRTC: DTMF and 911WebRTC: DTMF and 911

Two critical elements of traditional telephony will have to be supported in the new voice-on-the-Web technology.

I was at a conference without my cell phone, and I wanted to access my voice mail through Skype. It did not work. According to the Skype website, it does not support Dual Tone Multiple Frequency (DTMF) signaling. That means I am blocked from accessing any IVR system, my bank, voice mail, credit card companies, and others that have DTMF signaling capabilities. This not terrible, but it is inconvenient.

Some of the services I access by phone are much easier to work with because I can speak to a person. Eventually I will be able to do this with WebRTC, but I have to wait until the contact center vendors deliver the applications at both ends of the connections.

Then I thought about 911. Skype does not support 911 or E911 service; the Skype website states, "Skype Software is not a replacement for your ordinary mobile or fixed line telephone. In particular, apart from in very limited circumstances, the Software does not allow you to make emergency calls to emergency services. You must make alternative communication arrangements to ensure you can make emergency calls if necessary."

These limitations prompted me to consider WebRTC working with IVR systems using DTMF signaling, as well as WebRTC support of 911 and E911.

There is a WebRTC DTMF procedure. This is an absolute must-have function for Auto Attendant navigation and IVR menu selection. If the IVR is designed to accept WebRTC connections, then the DTMF signaling can be translated into data so there is no block to the Auto Attendant and IVR access. WebRTC integration offers developers an API to handle DTMF tones. This assumes that all the WebRTC applications that perform this function are the same or that there very few versions to implement--a standard implementation is very desirable.

When the WebRTC user has to access the PSTN (where DTMF works), then the WebRTC-to-PSTN gateways have to generate the DTMF tones for the IVR access. Again, this should be standardized or limited to a very few discrete implementations. In either case, WebRTC DTMF through a gateway needs to be consistent across virtually all the vendors. See my blog WebRTC-to-Legacy Gateway Announced by Genband.

Another issue is the caller's need to hear the tone feedback from IVR DTMF signaling. I am used to getting this feedback, to confirm my entry. This seems to be an issue. I found a blog on the problem of generating DTMF tones through WebRTC with tone feedback. The blog says there are problems with tone feedback so we may see a text feedback mechanism created instead of tone feedback.

911 and E-911
I looked into the question of 911 support by WebRTC applications. The Public Safety Answer Point (PSAP) is where the 911 call has to be delivered. The PSAPs are designed for the analog PSTN, but they are slowly moving to the next generation on 911 access. See my blogs, NG911: On the Horizon and Impacts of NG911 for further information on NG 911.

I did a Google search on "WebRTC 911" that generated only 4 results. This was not much help. So I contacted Mark Fletcher, Business Development Manager for Avaya's Public Safety Solutions to gain some insight into the WebRTC 911 issue. Mark commented:

Regardless of the endpoint technology someone uses to make a 911 call today, the connection between the Central Office 911 Tandem switch and the PSAP is downgraded to basic analog signaling. The "location data" (and I use that term VERY loosely) is conveyed by MF [mutli-frequency] tone generation by the Central Office and sent to the PSAP as in-band audio. These tones are then decoded at the PSAP. It is at this point where they are used to construct a query into the Automatic Location Information (ALI) databases, which then return the location information out of band on a separate path, most often a frame relay-type X.25 connection.

This is why the connection to 911 has never been an issue, even for VoIP telephones. The VoIP problem is one of mobility and nomadic behavior of the user, and the fact that no real "information" is generated from the origination point; it is derived based on the Automatic Number Identification (ANI) assigned by the Central Office. WebRTC will be a technology enabler that finally allows the disassociation of a telephone number and location, but [this won't happen until] the [public] network is ready. Until that point, it is business as usual and something will convert New to Old in the path of the call, probably through a gateway.

Next Generation 911 networks will have the ability to carry real-time data as a packet of information in the SIP header. This will allow the massive amounts of information available from origination networks and devices to be delivered to Public Safety. To prevent overloading an agency with too much information, the location information is delivered in the header while "additional data" such as building plans, environmental sensor data, or even data from an individual's personal health monitor can be presented as a SIP URI that the PSAP will query only if they want, and can receive the available information.

With WebRTC running on intelligent computing devices including Smartphones, I believe you will see the very first implementation of NG911-capable endpoints to be these devices using WebRTC directly into the Emergency Services IP network or ESInet.

This is why the connection to 911 has never been an issue, even for VoIP telephones. The VoIP problem is one of mobility and nomadic behavior of the user, and the fact that no real "information" is generated from the origination point; it is derived based on the Automatic Number Identification (ANI) assigned by the Central Office. WebRTC will be a technology enabler that finally allows the disassociation of a telephone number and location, but [this won't happen until] the [public] network is ready. Until that point, it is business as usual and something will convert New to Old in the path of the call, probably through a gateway.

Next Generation 911 networks will have the ability to carry real-time data as a packet of information in the SIP header. This will allow the massive amounts of information available from origination networks and devices to be delivered to Public Safety. To prevent overloading an agency with too much information, the location information is delivered in the header while "additional data" such as building plans, environmental sensor data, or even data from an individual's personal health monitor can be presented as a SIP URI that the PSAP will query only if they want, and can receive the available information.

With WebRTC running on intelligent computing devices including Smartphones, I believe you will see the very first implementation of NG911-capable endpoints to be these devices using WebRTC directly into the Emergency Services IP network or ESInet.

These problems of DTMP and 911 will be solved, so WebRTC will be successful. What I am pointing out is that WebRTC for handling voice calls both on the Internet and connected to the PSTN has to support mundane functions as well as all the hyped new applications. Success in this case needs to be evolutionary, not revolutionary.