Why This Developer Thinks Avaya Aura Collaboration Environment Rocks (And Rocks over WebRTC)
A Timely Article About SIP Timers
Some things happen for a reason and some things just happen. Last week I hit a deer and I highly doubt that there was some cosmic reason for the deer to jump out into the road just as I was passing by. It was what it was, and that’s all there is to it.
However, there are other events in my life that feel much more significant and preordained. For instance, in June of 1983 I answered a want ad in the Minneapolis Star Tribune from a company looking for computer programmers.
The company was Northern Telecom and that job started me off on a career that now spans three decades. It’s what sent me down the road of ISDN, digital phones, signaling gateways, contact centers, and now, SIP services, applications, and endpoints.
Could I have done something different for all those years? I suppose so, but as silly as it might sound, I feel as if this was my calling. I truly love what I am doing and cannot imagine what my life would have been like if I took another job and ended up writing payroll or tax software. Yuck.
* * * * *
This article originally appeared on SIP Adventures and is reprinted with permission.
All of this leads me to what I want to talk about today – timing.
I am often amazed at which of my blog articles become “best sellers” and which ones practically die on the vine. I have written about all sorts of subjects, but believe it or not, my top two blogs both have to do with SIP timers.
In fact, Google ranks me very high when it comes to Timer-B and Timer-F. You don’t believe me? Search for “SIP Timer-B” and look who shows up near the top of the list.
Timing is important in all aspects of life, and it’s very important with SIP. It’s important how long a user agent client is willing to wait until an INVITE message receives a response message. It’s important how long a registration or subscription will last.
As I explained in Understanding SIP Timers Part II, the Expires header is used to indicate the number of seconds a message can be outstanding.
For instance, if I put an Expires of 60 into an INVITE, that INVITE will timeout after one minute. As someone who hates listening to endless ringing, I see the value in automatically timing out calls that aren’t answered quickly.
SIP timing also has value outside of improving the user experience. Consider how a firewall permits a trusted application to open an IP pinhole for the traffic of a particular protocol. For security reasons, that pinhole will close if it goes idle after some period of time. Expires comes into play here, too.
An analog terminal adaptor (ATA) supports analog telephones on a SIP call server — the call server sends SIP to the ATA and the ATA converts SIP to analog signaling. Since analog phones can’t send REGISTER messages, that ATA does that on their behalf.
If there is a firewall between the ATA and the call server, that ATA needs to be aware that the SIP pinhole will close if messages stop flowing through it. To prevent this from happening, the ATA will ensure that registration expirations are shorter than the firewall timeout value. This way, even if phone calls aren’t made or received, the pinhole stays open.
In real life, I have seen ATAs use registration expirations of 60 to 120 seconds when firewall traversal is required and one hour when it’s not.
If you were to trace the SIP traffic on an Avaya system you will see that Avaya telephones set a fairly short Expires value. This allows them to use REGISTER for registration as well as a “here I am” message.
The distributed nature of SIP adds a new level of complexity when it comes to managing a network of SIP servers and services. It’s not like the old days of the monolithic PBX where one central brain controlled everything. SIP allows for intelligence to be shared amongst a collection of loosely connected servers.
However, those servers might need to know who is running and who is not at any given point in time. It’s also certainly useful for an administrator to be able to look at a maintenance console and see which elements are “up” and which are “down.”
SIP timing comes into play here, too. Since there is no SIP ping message, applications will periodically send OPTIONS messages to query the state of another element. You don’t want to flood the network with too many messages, so a reasonable timeout value should be chosen to balance the need to know with network bandwidth considerations.
Subscriptions are time-based and Expires headers are put into SUBSCRIBE messages, too. The rule of thumb is that a subscription should be refreshed halfway through the expiration time. This will ensure that it doesn’t unexpectedly disappear.
So, there you have it — three timely blog articles about SIP timing. I hope this one proves to be as popular as the previous two.