Refer Madness

by Andrew Prokop | Arrow Systems Integration

Do you have a favorite song? How about a favorite color? A favorite SIP message? What’s that? You don’t have a favorite SIP message? You really should. Since SIP only has about a dozen messages it shouldn’t be too hard to pick one. I did and mine is Refer. Does that surprise you? Yes, Invite is pretty much the workhorse of SIP and Subscribe is at the core of all sorts of cool and clever applications, but I happen to like Refer. Are you curious as to why? Read on.

Before I rave on about Refer I need to explain a few things about how SIP sessions are created. As you may already know, a connection from one SIP entity to another is established with an Invite message. Within the Invite are headers describing the caller, the called party, the device sending the Invite, the kind or kinds of media that the calling device is able to support, and any number of other parameters about the call. This will trigger response messages from the called party such as “100 Trying” and “180 Ringing.” The session is eventually established when the called party returns a “200 Okay” and the caller responds back with an Ack message. At this point, media will flow between the two parties on a channel separate from the one used for the SIP signaling.

Now, if you’ve been paying attention to trend in VoIP, you know that unlike dumb H.323 telephones, SIP telephones have a great deal of smarts and can do much more than a simple stimulus device. In other words, a SIP telephone doesn’t have to rely upon a central brain like an IP IPX for many of the standard telephony features. In fact, some SIP telephones can perform all sorts of call processing feats with nothing more than an Ethernet cable between them.

Consider the call we established a couple paragraphs ago. If these were H.323, analog, or digital telephones we would need to signal the PBX every time we wanted to do something to that call. For instance, if someone pressed the Hold button, a message would be sent to the PBX telling it to put the call on hold. If someone pressed the transfer button, a different message would be sent to the PBX informing it to start the transfer process. Not so with SIP telephones. A SIP telephone can put a call on hold by sending a message to the far-end that says “stop sending media until I tell you otherwise.” The same goes for transfer. A SIP telephone can transfer a call with direct communication to the interested parties without ever so much as a please or thank you to the PBX.




All of which finally brings me to Refer. Refer is the SIP message that moves a session from one place to another. Imagine that Andrew is talking to Susan and Andrew decides that John should really handle the call. In the SIP world, Andrew would Refer his call with Susan to John. In fact, Susan’s SIP telephone would actually end up doing the bulk of the work and Andrew’s telephone would simply be an observer.

The SIP call flow for transfer looks similar to the following:

Andrew and Susan are in an active call.

The call between Andrew and Susan is put on hold.

Andrew sends a Refer to Susan telling her to transfer the call to John.

Susan creates a new call to John.

Susan informs Andrew of the progress of the new call.

Upon being informed that the call to John has been answered, Andrew drops the held call to Susan.

Susan and John are now communicating and Andrew can get back to his day.

The thing that truly excites me about this is that the telephones themselves made the transfer happen. Sure, the PBX is there for user and device support, but the transfer itself was instigated, managed, and completed by the SIP telephones all by themselves.

Let’s take transfer one step further. Imagine that Susan and John were outside the enterprise and calls to or from either one came in and out on SIP trunks. Wouldn’t it be nice if once the transfer was completed the PBX and its trunk resources were out of the picture? This concept is known as “take-back and transfer” and is implemented by, guess what, Refer. Now, instead of Refer telling the SIP telephone to perform the transfer, it instructs the carrier to do what it needs to do to connect Susan with John. The end result is that all call legs leave the PBX and any associated trunks are released. Imagine the cost savings from something as simple as that.

Hopefully, you are starting to see why Refer is my favorite SIP messages. Not only does it allow SIP devices to be smarter than your average telephone, but it saves money, too. If you ask me, that sounds like a winning combination.

Share this article

The thoughts and opinions in these blogs belong to the individual blogger and do not necessarily represent the views or opinions of Arrow Systems Integration.