Refer Madness

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, or session, 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 OK (i.e. call was answered) and the caller responds back with an Ack message.  Media will now flow between the two parties on a separate channel from the one used for the SIP signaling.

If you’ve been paying attention to trends 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:

  1. Andrew and Susan are in an active call.
  2. The call between Andrew and Susan is put on hold.
  3. Andrew sends a Refer to Susan telling her to transfer the call to John.
  4. Susan creates a new call to John.
  5. Susan informs Andrew of the progress of the new call.
  6. Upon being informed that the call to John has been answered, Susan drops the held call to Andrew.
  7. 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 are outside the enterprise.  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.

So, what’s your favorite SIP message?



  1. Very well written and interesting even to us untechie dumbies!

  2. Andrew Prokop · · Reply

    Thank you for reading and commenting! I am trying hard to make this blog accessible to everyone.

  3. What a gem of a website you have here. I’m delving more into SIP myself and the devil is absolutely in the details. I plan on reading the RFCs, but this gives me a great foundation. Keep up the excellent work!

    1. Thanks for reading and taking the time to comment. If you have any questions about SIP, I am always open to requests for future articles.

  4. This is the best information I got on REFER so far!! great work Andrew.

  5. prachi · · Reply

    Hello Andrew, Thank you for the article.. You have mentioned that susan and john need not be SIP accounts( as in just normal phone number) . But whats the carrier mentioned. could you give me an idea of how to instruct the carrier to make the connect susan and john.. Please it would be really helpful.

    1. If you are connected to a SIP enabled carrier, you simply send the above SIP messages.

  6. Simple, precise and clear.
    Thank you very much for sharing your knowledge, your articles are helping me a lot learning SIP.
    Congratulations for your work.

  7. Hello Andrew, thank you so much even you have made it so simple but I am confused it with the refer option which we have on the sip server or registrar. Does this have any relation to enabling or disabling REFER before sending a call to gateway?

  8. Great explanation, I’m experiencing an issue where my refer messages are been blocked by my sbc with a 486 message.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: