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
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
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
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,
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.