A few months ago I wrote about my favorite SIP message in Refer Madness. I won’t repeat all that I said, but the slimmed down version is that REFER enables you to move an active session from one endpoint to another. In other words, REFER is used to implement call transfer. For example:
- Andrew is talking to McKenzie.
- Andrew decides to transfer McKenzie to Marsha.
- Andrew sends a REFER to McKenzie instructing her to call Marsha.
- McKenzie informs Andrew of the progress of her call to Marsha.
- When Marsha answers, McKenzie releases the call with Andrew
Pretty straightforward, isn’t it? I thought so at the time of the article, but I have since been asked a number of questions that have prompted me to revisit the subject of REFER. I now feel the need to flesh out my English description with some SIP specifics.
Let’s imagine the Andrew, McKenzie, and Marsha example again at the point where Andrew decides to transfer McKenzie to Marsha. This results in the following call flow.
Everything kicks off with the REFER message. Within the REFER is a Refer-to header. In our example, Refer-to designates that Marsha will be the transfer target.
Upon receiving the REFER, McKenzie returns a 202 Accepted response to Andrew. This informs Andrew that McKenzie is willing to carry out the transfer, but Andrew needs to stick around until Marsha answers the call.
Not shown in the call flow is McKenzie putting the call to Andrew on hold. This might be done with a re-INVITE to Andrew. I have also seen some soft-phones simply stop sending media during the transfer process. Personally, I prefer the re-INVITE method.
REFER creates a quasi-subscription between Andrew and McKenzie. I say quasi because Andrew did not send a SIP SUBSCRIBE message. However, for the duration of the transfer, McKenzie will act as if such a subscription exists.
McKenzie sends an INVITE to Marsha and Marsha processes the INVITE as a normal, incoming call. This means that she will send the typical provisional response messages back to McKenzie – 100 Trying and 180 Ringing.
This is where the quasi-subscription comes in. Just as if she had received a SUBSCRIBE from Andrew, McKenzie responds back with NOTIFY messages. The bodies of those NOTIFY messages contain the status of the call from McKenzie to Marsha. The formatting of this status is referred to as SIPFrag. A SIPFrag, or SIP Fragment, is a piece of a SIP response message. In our example, NOTIFY/SIPFrag messages are sent for the 100 Trying, 180 Ringing, and eventually the 200 OK.
Andrew acknowledges the receipt of each NOTIFY with a 200 Ok. These 200 Ok responses should not be confused with the one generated for the INVITE when Marsha answers the call.
A NOTIFY message for the 100 Trying might look similar to the following:
NOTIFY sip:Andrew@mycompany.com SIP/2.0
Via: SIP/2.0/UDP 10.10.21.11;branch=z9hG4bK9922ef992-25
CSeq: 192 NOTIFY
SIP/2.0 100 Trying
I’ve highlighted in bold the important aspects of the NOTIFY. An Event type of “refer” indicates that the NOTIFY is part of a REFER call flow. Content-Type tells Andrew that the message body will be formatted as a SIPFrag. Finally, you will see a SIPFrag for the 100 Trying response. Similar NOTIFY messages will be sent for 180 Ringing and 200 Ok responses.
Once Marsha answers the call, McKenzie can drop the existing, held call to Andrew. If Marsha did not answer (e.g., McKenzie receives a 404 User Not Found), McKenzie would notify Andrew and the held call would be reconnected. Andrew could then complete the call with McKenzie or attempt a different transfer.
REFER is used for more than station to station transfers. Are you familiar with take back and transfer? REFER is used to instruct a SIP carrier to move a trunk call to an off-PBX destination. Without REFER, inbound and outbound trunks would be tied up for the duration of the call even after the transfer was completed.
There you have it – a deeper dive into REFER than perhaps you’ve ever taken or ever wanted to go. Thanks to the folks who requested more information. I am always happy to get SIP geeky with you and it’s especially gratifying when someone actually requests it.
Thanks, that’s a really good primer on REFER messages!
You’re welcome. Thank you for reading and commenting on my article!
Thank you very much Andrew for clarifying the missing points..
You’re welcome! Happy to be of service.
Thanks for sharing this blog. this is the very informative blog for those person who wants to gain information about Virtual Receptionist and Call Transfers.
Thanks, Jack. I am happy that you find my blog educational.
Good article.can you please also let us know how to transfer call using re-invite and also which method is preferred over another and why?Thanks!
It’s funny that you mention that. I am planning on putting out an article on transfer next Tuesday. Let’s talk again after you read that one.
Nice article it was really useful to me.
Really thanks for your article…Every thing becomes easy and simple after your explanation..=)
Thanks. That was my goal.
thank you very much for your post, its really good post.
Andrew, after completion, do you know if there is a mechanizime such as notify-controller on TBCT (NI-2 PRI) to advise the controller of the end of the call transfered?
I do not. Sorry.
If we didnt get 202 accept for first REFER, UAC will try to retransmit again?
I expect that it would.
Hey Andrew, I have a scenario where a user in one environment (Skype for business) is trying a SIP REFER to a user on Session Manager 6.3. Session manager is declining the call with a response of “Refer-To” user is null. Any thoughts on where to start?
Is the Refer-To actually Null? I am not familiar with how to setup Skype. Is there a configuration item for Refer?
Skype for Business (S4B) Refer is bugged or not complete implementation.
Refer has two types:
1- Simple (should have a ‘number’ in its Refer-To header)
2- Replaces (should have at least Call-ID and From/To Tages in its Refer-To header)
S4B uses Replaces type.
In this mode, we have two established SIP calls.
A-B (A called B OR B called A .. where B is S4B)
B-C (B must have called C)
Here, B refers with replacing itself (in the call B-C) to A, so A will be connected to C, via
two ReINVITEs from B. One to A (containing C-SDP), and one to C (containing A-SDP), then both A & C will be connected. At this point B can drop its two sessions by sending BYE to A & C.
In the actual S4B environment, it sends REFER with Replaces but the Call-ID, From-Tag and To-Tag is undefined and do not exist (simply S4B didn’t establish another call in the frist place!).
That’s why S4B REFER gets always rejected with 4xx or 5xx, since there is no info about the call it is sending its context ..
Orange Business Services
Thank you for the article was really helpful. Could you please advise me how to use in jain sip api.. in java ? does anyone have any idea
Hi Andrew, thank you very much for your article!
I need to initiate a call for a different client registered to the same user.
So can i send a REFER command to “myself” and see if another client answers?
Would that be possible?
Calls are not initiated with a REFER.
Thanks for your answer. I found out how to solve my problem.
My first idea was to send a INVITE request for another UAC. But for this i need to know all the other registered UACs. And i did not find a way to get this information from the registrar. So what i do now is sending a INVITE to my own number. And as soon as another registered UAC picks up the call i send a REFER to the number i would like to call. Best regards Markus
Thank you Andrew.This blog is very helpful
Thanks for your blog…
But what is purpose of sending ‘call-id, from tag, to tag’ in Refer-to header in REFER message?