I have been writing articles for this blog since June of 2013. My goal is to cover the many different aspects of unified communications with a clear emphasis on SIP. Every once in a while I push the envelope and write about something that only has a loose connection to communications, but for the most part I stick with my game plan.
Something near and dear to my nerdy heart is SIP the protocol. I love digging through call flows and figuring out what occurred. They are my puzzles and brain teasers.
My protocol indulgence for today involves one of the least understood SIP headers – Replaces. The Replaces header wasn’t in the original definition of SIP, but its need was quickly recognized and a proposal came in the form of RFC 3891. You are welcome to find and read the RFC, but I think I can tell you everything you really need to know in far less time.
Replaces allows you to swap, or replace, one leg of a SIP call with another. This is not to be confused with transfer where you change both legs.
The most obvious application of Replaces is Call Park. Image a situation where Andrew is speaking with Ellen. Andrew decides that Ellen needs to speak with John, but Andrew isn’t sure where John is. So, instead of trying to transfer the call around until he finds John, Andrew parks the call in some form of a parking lot. The parking lot will return a token to Andrew indicating the spot where the call was moved to. For this example, let’s say that the token is 33. Andrew can now use an overhead paging system to ask John to “pick up a call at 33.” John uses the token to indicate that he is calling Ellen in the parking lot. John is connected to Ellen. Essentially, Andrew’s call to Ellen has now been replaced with a call to John.
As with all headers, Replaces must be part of a SIP request. From every example I have ever seen, that request is INVITE. Looking back at the previous example, when John picked up the parked call, an INVITE with a Replaces header was sent to the parking lot.
So, what’s inside the Replaces header? Obviously, it must be something that can uniquely identify the call in question. For SIP, uniqueness comes from the Call-ID of the target call along with its To and From tags.
For a deeper discussion on call identification, please see my article, Let’s Play (SIP) Tag.
Although you won’t see a Replaces header inside a SIP REFER message, REFER is typically involved in a replaces call flow. In my example, Andrew transferred Ellen to the parking lot. Under the covers, Andrew referred Ellen to the parking lot with, what else, a REFER message.
For a more thorough explanation of REFER and transfer, please see my article, REFER Madness.
Tying all this together we see the following:
- Andrew and Ellen are speaking
- Andrew sends a REFER to Ellen directing her to the parking lot.
- Ellen sends an INVITE to the parking lot and the parking lot answers. This essentially puts Ellen on hold.
- Andrew obtains Ellen’s parking lot token. This might be accomplished by Andrew subscribing to the parking lot and receiving a SIP NOTIFY message containing the token.
- Andrew broadcasts the fact that John has a call waiting in the parking lot. John will be informed of the token ID.
- John hears the broadcast along with the token. Through some out-of-band mechanism (perhaps a webpage that matches tokens to parked call), John retrieves Ellen’s Call-ID, To tag, and From tag.
- John sends an INVITE to the parking lot. This INVITE contains a Replaces header with the retrieved Call-ID, To tag, and From tag.
- Ellen’s parked call will be replaced by the new call from John.
Let’s assume a Call-ID of 12345678, a To tag of 7744, and a From tag of 5693. This would yield a Replaces header that looks as follows:
Replaces: 12345678,to-tag=7744;from-tag=5693
Besides Call Park, there are other uses of Replaces. For instance, Replaces could be used to answer a call ringing on one phone on a different phone. Again, access to the ringing call’s Call-ID and tags are necessary, but an application could be written to make them available.
That’s about it for Replaces. Thank you for sticking with me. It’s nice knowing that there other folks as nerdy as I am about this stuff. Consider yourself special.
Tao, Zen, and Tomorrow 
You’re right that you won’t see a Replaces *header* within a REFER. But what you will sometimes see is a Replaces *parameter* within the Refer-To header in a REFER. And it’s an oddly beautiful thing.
You originally described REFER as “the SIP message that moves a session from one place to another”. That’s not strictly true. It’s really Replaces that does that. REFER is actually just a recommendation to send a request to someone else. By default, it says “I suggest that you send an INVITE to “.
When you send a REFER within an INVITE dialog, you’re implying that the INVITE sent out should replace that dialog. That’s why, in your Refer Madness article, Susan drops the call to Andrew when John answers. But you can also do something like: Andrew sends an out-of-dialog REFER to John with a Refer-To header that contains both Susan’s URI and a Replaces parameter identifying Andrew’s dialog with Susan. If John accepts this, his phone will send an INVITE to Susan with a Replaces header that identifies Susan’s dialog with Andrew. Susan’s phone will then automatically accept that INVITE, send a BYE to Andrew and transfer the media session to this new dialog. Wonderful.
Even more Refer Madness: the Refer-To header can also take a “method” parameter, if you want to suggest that a request other than INVITE be sent. For some delightfully silly examples, take a look at RFC 4579, which describes how you can do client-server conferencing with SIP.
Madness level 2: section 5.11. If it’s your conference, you can kick someone out of it by sending a REFER to the conference server with Refer-To: ;method=BYE. “Hey, conference server – please send a BYE to !”
Madness level 3: section 5.7. Bring someone into the conference by sending a REFER to the conference with Refer-To: ;method=REFER?Refer-To=. Yes, you read that right. “Hey, conference server – please send a REFER to !” Conference server: “Hey, , please send an INVITE to me!” Crazy.
Hi Andrew.
Thanks for your explanation. But I got lost at step 7:
7. John sends an INVITE to the parking lot. This INVITE contains a Replaces header with the retrieved Call-ID, To tag, and From tag.
It doesn’t make sense to me that John sends the INVITE with Replaces header to the parking lot? If he did that, then in step 8 wouldn’t John be connected to the Parking lot and Ellen would be disconnected?
According to my interpretation of the example given in chapter 1 of RFC 3891, I think it should say:
7. John sends an INVITE to *Ellen*. This INVITE contains a Replaces header with the retrieved Call-ID, To tag, and From tag.
8. Ellen’s parked call will be replaced by the new call from John.
Thanks,
Nick.