REFER Revisited

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:

1. Andrew is talking to McKenzie.
2. Andrew decides to transfer McKenzie to Marsha.
3. Andrew sends a REFER to McKenzie instructing her to call Marsha.
4. McKenzie informs Andrew of the progress of her call to Marsha.
5. 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.

Refer-To: sip:Marsha@mycompany.com

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

To:<sip:Andrew@mycompany.com>;tag=1934342

From:<sip:McKenzie@mycompany.com>;tag=49928814

Call-ID: 898234234@10.10.21.11

CSeq: 192 NOTIFY

Max-Forwards: 70

Event: refer

Subscription-State: active

Contact: <sip:McKenzie@10.10.21.12>

Content-Type: message/sipfrag;version=2.0

Content-Length: 20

 

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.

Tags: REFER, SIP, Unified Communications