In a post that prompted me to write this, Tsahi discusses different alternative signaling protocols one can use in a WebRTC-enabled app. In this post, I approach the issue from a different angle and I hope this sheds additional light and helps you to reach a choice appropriate for you.

First let us consider the transport mechanism.

1. Pure HTTP: Since the app will be accessed from a browser, an easy choice would be to use HTTP as the transport. It works great if the browser is initiating a signaling procedure and the server responds.


2. HTTP w Long Polling/Comet: But there are times, when the server needs to initiate asynchronously. Some examples are when the server wants to notify one user of another’s action like placing mic or speaker on mute. Or the server would like to notify of an incoming call request. Since the server can autonomously initiate an HTTP session an alternate will be to use long polling or Comet. This may increase the load on the server due to excessive polling or may introduce latency and its undesirable effect on UX.


3. HTTP w Push Notification: Alternatively the server can use Push Notification offered by both Chrome and Firefox to push a notification and upon receiving such a notification, the browser can initiate an HTTP session to continue the procedure. Of course this addresses the server load, but does not address the latency issue, especially for “in-session” procedures. Worse, the latency is affected by a third party service.


4. Websocket: This where use of Webscoket has its advantages. Since Websocket starts as an HTTP session which is then converted to a persistent TCP session. Almost all browsers (most recent versions) support Websocket and there are server implementations that are very efficient. So it addresses both the issues.


5. Websocket w Push Notification: If maintaining a Websocket connection during an idle period (so as to inform of an incoming session request), then one can use Push Notification during idle periods and then use Websocket only during active sessions.


6. Data Channel w X: Final choice is for the server not to be involved during an active session, but allow the browsers to handle the signaling procedures directly between themselves via a WebRTC Data Channel. But this approach does not address how to handle notification during idle periods.

Deciding which protocol to use is either “no-brainer” or “not so fast”. If the paramount objective is to work with already deployed system and WebRTC app is just another access mechanism, then there is nothing more to consider. It is optimal just to use the signaling procedure used by the deployed system and that is that. Otherwise, it is better to start from scratch and ask questions differently. From the time of Q.931 in ISDN Basic Access up to and including SIP, the standards bodies have focused on defining the protocol so as to ensure interoperability between two autonomous systems. Since the end-points will be of different capabilities and present different user experiences, the best a standard can do is to design a protocol that drives basic user interface. Thus for example, when the far-end places a call on hold, the near-end is not notified. It is not clear how to abstract the notification so all variation in the UI can be handled.

Next, let me quickly dismiss a faux use case, but one that is widely considered. It is know as “trapezoidal connection”. In this connection, the two end points are each connected to its own WebRTC app and the two apps are federating between themselves. The fact that the two end-points are using WebRTC as access is incidental; the real crux is that the two apps are federating and they have agreed on a protocol for this. So what the apps will select for protocol belongs to the “no-brainer” category. The apps will select a protocol that is optimal for the agreed upon federation protocol.

So the real interesting use case is where the end-points are directly connected to the app server, the so called “triangular connection”. Since both the end-points are directly connected to the app server and the server can dynamically download the signaling procedures via Javascript, it is in a position to offer a rich user experience by dynamically driving UI elements. The app designer can freely devised the needed signaling procedures - conforming to a standards is not critical. A good analogy is to compare the choice to paint by number and free-form painting. At first glance, paint by number looks straight forward; but in fact it is tedious, no room for error and not very expressive. On the other hand, free-form painting, if you are good at it, is fluid, very expressive and gives lots of freedom. If the choice were only free-form painting, then I will have only blank canvas; with paint by numbers, there is a hope that I will have something that looks like a painting. So I say to each, his own.

Recently, Carl Ford was musing about potential ideas for a WebRTC Hackathon. One idea he had was exploring different UI designs associated with “Video on Hold”. This post is a summary of our design thoughts decisions we made for a WebRTC application that is part of EnThinnai.

In a followup post he elaborates his point. He suggests that we may imitate the idea used in 1A2 Key Systems phones. To see how far we can carry its design we need to go into a bit more detail.

These phones had some white buttons, with each one controlling a line it has access to and at most one button can be engaged. There was a red button that can place the currently engaged line on hold. All these buttons can be lit and also flash to signify the status of the line. For example, the quick flashing light will signify that there is an incoming call; a slow flashing light will signify that the line has been put on hold and a steady light will suggest an active call. Subsequently, Avaya carried over this design idea to their digital sets as well. This concept of “call appearances” and “active call appearance” is natural and very familiar in computer systems using windows. It is direct to observe that capp appearances are nothing more that open windows and active call appearance is active window. When the user selects a window to be active, the OS tacitly places other windows on hold.

But the analogy goes only so far. In a computer, even if a window is not active, activities can go on an inactive window. For example, the user may be playing a You Tube video in an inactive window. Also we should note here that 1A2 Key System phone indicates whether the local user has placed the call on hold or not; it does not know whether the far-end user has placed the call on hold or whether he is retrieving the call, which is the use case Carl wants to explore.

There is one other fundamental difference between 1A2 Key System and the environment WebRTC app will find itself. The phone can safely decide that when a call appearance becomes active, the call that was active must be placed on hold. But that may not be appropriate in the case of WebRTC. For example, the user may want to continue the call while viewing and interacting with the contents of another window. Or the user may have multiple WebRTC session going at the same time in an attempt to emulate a bridged call. So the only safe approach is to let the user explicitly select whether a video call must be placed on hold or not.

If we dig a bit deeper, we will question the basic need to place a call on hold in the first place. In PSTN systems, a call must be placed on hold if the user wants to attend another call because the access line can carry only one call at a time. But that is not the case in the case of WebRTC. The user can equivalently decide to turn off the camera or the display or both instead of placing the whole call on hold.

Recently, call centers have responded to frustrations expressed by callers due to excessive hold times, by introducing a feature called “callbacks” or “virtual queuing”. A webRTC app can offer a similar feature in an elegant manner by making the app a multi-modal one with the text chat session to periodically update the status and use it as a link to provide audio and video cues when an agent becomes available.

These thoughts are captured in the current user interface design used in EnThinnai:

1. Screenshot of the chat window, just before start of a video call

2. Screenshot during an active video call

3. Screenshot of a “held” or “virtually queued” call

4. Far-end sends a text message and creates audio sound by pressing the “b” button

Inasmuch the main utility of a formal living room is to entertain visiting guests, a WebRTC allows guests to initiate a communication session with the subscriber of the app that utilizes WebRTC.

Many go to enormous lengths to furnish and decorate a living space normally called Living Room. Notwithstanding the expense involved and the name, it is used mostly when guests are visiting. When we are entertaining guests and they are using the amenities in that room, there is no question of whether the guests have similar room and similar amenities in their houses. The only requirement is that they visit you and that you are ready to host them.

So is the case with WebRTC apps. The main reason for the app and for you to sign up for one is so people can initiate communication session with you. The only requirements are that your guests have a compatible browser and that you are willing to communicate with them.

Just because you have a lavish formal Living room does not mean that when you visit one of your friends you will experience similar luxury. Similarly, subscribing to a WebRTC app may not imply that you can initiate a communication session to one of your friends. In this respect, WebRTC apps for for receiving only. This is critical. Anyone suggesting differently is misleading you.

The image is courtesy of AvaLiving.com

It has been reported that Telefonica will shut down Tu Me and redirect its resources in shoring up another service, To Go. People have theorized that compared to competing services from OTTs, To Me has anemic traction with uncertain revenue potential. On the other hand, the reasoning continues, To Go has solid revenue opportunities, since it accrues billable minutes/SMS from existing customer base. Two years back, I gave a talk at Telecom 2018 Workshop, in which I argued that telcos will have difficult time directly competing with OTTs and suggested an alternate approach. In this post, I revisit those points in the context of Telefonica’s decision.

Telcos are a study in contrast. They are established enterprises beholden to shareholders who value steady return and adverse to big risks. Furthermore, they need to be worried about cross elasticity of new services with old ones. They also have strong presence in geographically restricted areas; usually federate with other telcos in out-of-regions. But such federation is not easy to come by since potential partners may have different priorities in introducing new and speculative services. So on Day 1, a new service will have low Network effect.

It is clear that To Me experience exactly these issues and predictably they had low traction. Though I do not have verified data, it is a safe bet that they were more successful in their local regions more so than out-of-regions. Since they are marketing To Go to their existing customers, they will have better luck with that service. It allows their subscribers to access the services using multiple means of access. This way, they have become an “OTT” for their subscribers. But it is only half the solution.

If we take the perspective of friends of Telefonica’s subscribers, we will notice the missing piece. They also use multiple technologies to access the network, but in the current scheme, it all have to come via PSTN with attendant restrictive set of features due to federation agreements with their carriers. This need not be the case anymore. Supposing Telefonica allows non-subscribers to reach its network using WebRTC technology, then its customers can use new services and features with no loss of Network effect.

This is the fundamental benefit of WebRTC from the perspective of the carriers: it frees them to introduce new services and features to their subscribers without loss of network effect and without relying on federating and coordinating with other carriers.

I suggest that my carrier identify its confidence in the caller id in a three point scale: “verified”, “unverified, but can be challenged”, “unverified and can not be challenged”. The idea is if I answer a call from the second group and conclude that the number was spoofed, I challenge my carrier which propagates upstream. If it is concluded that number was indeed spoofed, a financial payoff follows the reverse path. Since termination charges follows this path, this is not an additional burden. It is recognized that this challenge is resource intensive. So to control my trigger happy nature, I am given a limited number of free challenges, just like we do in sporting events.

There are some potential gotchas. Current Caller ID spec has a way to signify two groups. It is not clear whether the spec can be extended to carry the third group as well. It is not clear how many caller ID devices can display the group. Initiating the challenge process is not difficult. This is just a variation on “last call return”.

I suspect that under this scheme, most of the evil spoofers will not be agreeable to this form of challenge. So those calls will belong to the third group, which I will not answer. But well intentioned spoofers will be agreeable to challenges and over a period of time, the public will gain confidence in this characterization and the number of challenges will decline.

In a recent post Chris Kranky on the need “to move on” and the need for expediency in wrapping up the first iteration of the API. Personally I would have benefited if the first iteration had been a low level spec. For I could have easily ported a custom Java applet. But given the passage of time, it is more important that there is an agreed standard. But this point is not the objective of this post. Instead I would like to focus on another of his points:

[WebRTC] wasn’t designed to be federated (namely that 2 WebRTC applications aren’t in fact supposed to talk to each other.

He makes this observation to explain the motivation for seeking low level control. My quibble is not with this explanation, but I want to take this sentence in isolation, interpret it literally and discuss it. (It is not fair to Chris, but I am just using his sentence as a prop. So it should be OK with him.)

Following are four main reasons why we need federation and how WebRTC handles them without requiring federation:

1. Reachability information is not widely held, except for some selected nodes in both the systems.
   
   Since WebRC address is HTTP URI, the originator’s service provider or system is not needed. The originator can directly access the destination’s system. Indeed, it is not required that the originator be part of any service provider or system.
2. 
   Communication between the systems may need mediation to handle incompatibilities.
   
   Since the app server dynamically downloads the signaling procedures, there are no incomptibility issues on the signaling plane. I further assume that MTI codecs remove incompatibility between the browsers. In any event, any such incompatibility can be solved w/o the two systems federating.
3. 
   Identification and authentication of external nodes need to be mediated.
   
   Since the whole construct is built on HTTP, any of the third party verification systems can be used to identify and authenticate the end-points. In this respect there is a need for federation, which is much less stringent requirement and can be easily waived by the end points depending on the use case.
4. 
   Since the external systems may not be trustworthy, the local system need to protect its users.
   
   WebRTC has builtin security systems to protect the end nodes from malware apps. Specifically, the browser ensures that a rogue app can not assume control of the end node.

In my opinion the fact that WebRTC does away with federation is one of the important benefits and why it is going to disrupt communications industry.

By now it is quite passe to claim that WebRTC will be a huge disruptive technology. Indeed, there has been a predictable backlash. In all these back and forth, very often we miss to note an important aspect of this technology: there has been a deliberate attempt to avoid specifying any messages and procedures that go across the wire to an intermediate point like server. This gives enormous flexibility to app developer in designing a signaling procedure that suits the needs of the app and at the same time do not have to worry about interoperability issues between arbitrary peers and the app. This is almost true, except for NAT/FW traversal. The objective of this post is to suggest a way to overcome this as well.

Instead of fully developing STUN and TURN servers, the idea is to develop a simple “Twice NAT” and a clever use of Trickle ICE procedure that the browsers already support to bootstrap ICE procedure. Here, let us recall that Twice NAT maps both the origination and destination addresses, instead of just the origination (destination, resp) address on the outgoing (incoming, resp.) flow.

As part of Peer Connection procedure, Peer A will generate an SDP offer containing its host address. The app server can append to this SDP offer an address as a “fake” server reflexive address of Peer A before forwarding it to Peer B. In response to this, Peer B will generate an SDP accept containing its host address. The app server can append to this SDP accept another address as a “fake” server reflexive address of Peer B before forwarding it to Peer A. As part of ICE connectivity check procedure, Peers A and B will send connectivity check messages to these “fake” server reflexive addresses. From these the app server can deduce the real server reflexive addresses of the peers. Also, the app server can allocate two addresses at the Twice NAT as relay addresses. With these addresses at hand the app server can generate SDP offer messages to the two peers containing server reflexive and relay addresses of the other peer. Of course the peers will respond with accept messages that the app server can ignore. Since the peers have new candidates, they will perform connectivity checks on these new set of addresses.

If a peer is multihomed, then that peer will conduct connectivity check from each of the interfaces to the “fake” server reflexive address, yielding true server reflexive address of each of those interfaces.

Thus, the app server facilitates NAT/FW traversal without developing conforming STUN and TURN servers and placing the burden of compatibility solely on the peers.

This procedure is adopted from a modified procedure we were using in the Java-based RTC system in EnThinnai. It was developed during 2008.

Some of us strongly believe that WebRTC will usher in a wide variety of innovative services, features and capabilities. At the same time, there are many skeptics dampen the (irrational?) exuberance. I am sure both sides will present their view points during this week’s WebRTC Conference & Expo. In this post, I would like to commemorate that conference by outlining one possible application.

Then there are occasions when one would like to reach the local police for non-emergency assistance, like a fender-bender. But one may not know the contact information. Indeed, I do not know the phone number of my local police station, let alone a location I am just passing through.

Finally, many communities have non-emergency community information service, sometimes called 3-1-1 service, based on the dial code used in US. Other countries have similar services, but use different access numbers.

I propose an application that can be used in these scenarios.

A user who would like to contact Police or a government agency sends an HTTP request to the app provider. That request will contain needed information like the nature of query, location of the user (as derived from the device) and other incidental information. Then the app provider can use these to locate the specific agency that has jurisdiction and can redirect the HTTP request to that agency. From there, the agency and the user can communicate using the services of WebRTC.

There are advantages in using this scheme. A roaming user does not have to know how to reach the local agency. If the request is for medical emergency, the request can carry the location (URL?) from where medial data can be retrieved. Of course this requires authentication and authorization processes, which can be easily done using multiple redirection of HTTP requests.

It should be noted that the basic requirement is that the app provider have a universal database of emergency and other government agencies for any given location. This may not be such an onerous task. For example, SeeClickFix does it for 311 in many communities.

Setup:

1. The initial step of connecting Obi110 to the Internet and powering up is a simple matter. Once the device powers up, it is automatically connected to Obihai’s VoIP service called ObiTALK. There is no need for any configuration and the device comes with a preassigned ObiTALK number. I am not sure I will ever use this service. There are a number of reasons for this. I know of anyone in my “phone circle” with ObiTALK. Distributing yet another contact information is a pain. But I could use to test the initial setup by dialing the test number.
2. The next step is to administer Google Voice account credentials. There are two ways of doing it. One is to populate the account information by accessing Obi110 locally. This is a low level access with intimidating level of parameters that one can tweak. The other is to register the device with Obihai and provide the needed information to configure Obi110. Since the latter is user friendly and straight forward I used this method.If the device is able to connect to Google Voice, the portal page displays the status information.
3. The final step is to connect Obi110 line port to the wall jack and attach a telephone.

These three steps look simple enough but I encountered a few annoying difficulties.

Difficulties:

1. Even though Google allows for a passphrase, meaning the password can contain spaces, evidently Obi110 does not. I inferred this only after a few failures and have to change the password so it does not contain spaces. The portal should use the password string as entered rather than inferring any delimiters.
2. Evidently, the account information is stored in the portal. I am uneasy about this. Granted, the portal makes the admin simpler, They could have implemented it as a proxy to the device and avoided the need for external storage. At a minimum, they should state how the account information is stored at their site.
3. Given a temperamental DSL connection, I couldn’t connect the device to the telephone jack. But other rooms do not have Ethernet access. So I ended up getting a WiFi bridge so the device could be connected to the router via WiFi. This effectively doubled the total price of the device. I wish the device had a builtin wifi capability.
4. I could not complete calls over the POTS line by dialing the access code, **8. But a person over at the support forum was helpful. The suggestion was to dial # and wait for the second dial tone from the phone company before dialing the phone number. In other words, I have to dial #, instead of the access code. The device could do this for access code itself. After all my cordless phone does this for “offhook” dialing.
5. Updated: If the device is powered, but looses net connection, then it doesn't failover to PSTN line. I wish it announced the net failure and gave an option to complete the call over PSTN or any other available interface.

Enhancements: