Standardized Human Behaviour

By Ran Arad

Categories: Standardization

March 3rd, 2008

I called a friend of mine the other day, and he answered and immediately (accidentally?) disconnected. I thought of calling back, but then I thought maybe he it was in the middle of something, and just wanted the phone to stop ringing by opening and closing his clam-phone; or maybe he’s trying to reach me right now, and if I call him we’ll both get a busy tone. On the other hand, he may be expecting me to call him, since I called first. I decided to wait it out, and being a protocol implementer for many years, I thought what would a protocol have to say about it, and decided it would be something like “out of the scope of this document”.

As soon as things get to the real life, the protocol weasels out with the “out of scope” excuse. I wasn’t going to leave it at that. I decided to write it up. The first idea I had was that the person whose side got disconnected will re-initiate the call, but that won’t work because if something in the middle fails, each side will think the other failed, and no-one will call. We have to have a clear assignment of duties: either the caller should call back, or the called side should call back. The caller is likely to have both a more urgent need to communicate and better accessibility, as the called side may have answered with a car speaker or earpiece. The rule I decided on was that the caller should immediately call again, with one exception: since call reestablishment time is critical here, if one side is known to have a harder time reaching the other (e.g. passing through operators), the side with easier access should call back.

Another issue that comes to mind here is the call charges. Sometimes the charges for incoming calls and outgoing calls are different – some companies, for instance, change the subscriber only for outgoing calls and charge the caller for calls going in. Some subscribers have deals for some numbers or hours of the day. If the protocol is to consider these issues, it must assume that both parties are aware of these issues prior to the current call, and agree to utilize this advantage. To do so they can use a separate “call charges diversion protocol” to make sure that the call direction is optimal: if the call initiator wants the other side to make the actual call, he enters “call solicitation mode”, meaning that he calls the other side, lets the phone ring for just a little while, then hangs up. Solicitation may be tried twice, with a 10 seconds’ wait period, and then fall back to normal call initiation.

In order to ensure reestablishment (in case one side does not implement the protocol correctly), in the case where the caller has not reestablished the call within one minute of disconnection, the called side shall attempt reestablishment. From then on, each time a minute passes, the other side reattempts connection. Reconnection procedures are terminated when a connection is reestablished or when ten minutes have passed since disconnection.

As I said, the communication protocols do not care to implement these real life mechanisms. For instance, the “call charges diversion protocol” can be easily implemented at the protocol level by dropping the call with reason “I’ll call you back”. Reestablishment may also be done when the protocol detects that the call was disconnected abnormally – detection may be prevented by a server along the way closing the call gracefully, however, it is certainly possible.

Next time I’ll discuss how long should one wait when he hears a call waiting tone. Until then, here is some supplemental reading: the shotgun protocol.