“Phone number” for WebRTC
Jul 25th, 2013 by Aswath
For many use cases the point of this post may not be applicable. But for the use case where your contact can use a browser to reach you to communicate with you, it is very relevant. So you decide whether to read on further.
If you want your contacts be able to reach you from their WebRTC-enabled browser, you need to provide them with an HTTP URI. Just like we share our telephone number. Or email address. Or better yet, the URL of our blogs. Usually the URI will identify the location where the WebRTC app is running and also your id. For example the URI to reach me at Twelephone is
http://twelephone.com/aswath
It can be as simple as this or a bit more complicated. I have a WebRTC app running on a self-hosted server. My URI there is
http://enthinnai.dyndns-home.com:8080/enthinnai/pages/iframelogin.jsp?from=iframe&owner=aswath.mocaedu.com
You may not want to share such an unwieldy URI. Since a WebRTC session starts with an HTTP message exchange, we can use redirection service and use a more memorable URI as WebRTC “number”. For example, I am using
http://bit.ly/callaswath
as my URI to reach my self-hosted WebRTC app server.
We may want to do this even if it is short like the one issued by Twelephone. Unlike phone numbers, you can not port the URI from one provider to another. But HTTP redirection is a simple and straightforward solution.
The URI need not be a static one. A website can dynamically construct a URI to indicate additional, context specific information. For example, the URI can indicate the ID of the caller, which can be verified using a HTTP-based verification system. For example, this URI,
http://enthinnai.dyndns-home.com:8080/enthinnai/pages/iframelogin.jsp?from=iframe&owner=aswath.mocaedu.com&
buddy=www.enthinnai.com/unauopenid/anycard
indicates the caller’s id to be www.enthinnai.com/unauopenid/anycard. Or the caller can indicate the purpose of the call in the URI itself. Or the URI can indicate the page from whence the call is initiated.
All these supplementary information is usually defined by the signaling protocol. Since the signaling protocol is unspecified, the application can decide which information will be sent and the specific format. Specifically, the app can decide to carry some of the information as part of the URI.
Hello Mr. Aswath: Great post. What do you think about using an iNum number as the unique identifier at the end of the http request, then it can be a WebRTC “number” and a usable e.164 phone number that people can call from skype, google voice and other networks or via access numbers (until its universally supported? )
Hugh, thanks for your comment. Certainly one can derive their WebRTC URL from their iNum. It can be anchored at iNum domain or the user’s preferred domain. Similarly, one can do the same thing with their own “already well known” PSTN number. Somebody has suggested use of .tel domain. It is individual choice. But there is no need for a universal, single solution.