Dissecting SIP Transfer

Two weeks ago, I had a little fun by tearing apart a SIP conference call. I was shocked by how popular the article turned out to be. Not only was the view count very respectable, but I received a number of emails from folks who wanted to take it a bit deeper. Seriously, I had no idea there were that many hardcore SIP nerds out there.

Today, I am going to push my luck and do the same thing for SIP transfer. While I have addressed transfer in previous blog articles, this is the first time I am going to include Wireshark traces of the entire process.

---

I recommend the following articles as study guides for today’s missive:

Dissecting a SIP Conference Call

REFER Madness

REFER Revisited

---

As with conference, this article is based on a lab exercise from my SIP class. The students use an old Avaya SIP soft phone in point-to-point mode. This means that the clients send SIP requests and responses directly to other clients. There is no SIP proxy of any sort that sits in the middle.

For this instance of the lab, Kevin calls Mike. Mike answers the call and then transfers Kevin to Wayne. After Wayne answers the incoming call, Kevin releases his call to Mike.  Lastly, Kevin drops his call to Wayne.

Before I dig into the traces, allow me to get some terminology out of the way:

1. Transferer. This is the client that initiates the transfer process. In my example, that would be Mike.
2. Transferee. This is the client that is transferred. That would be Kevin.
3. Transfer Target. This is the destination of the transfer. Since Mike transfers Kevin to Wayne, Wayne is the transfer target.

There are two places where it makes sense to run Wireshark traces  – at the Tranferer and the Transferee. As you will soon see, nothing unusual is seen if you trace at the Transfer Target. For this article, I chose to show you the traces made at the Transferee. It should be very easy to infer what the Transfer Target sees.

As I nearly always do when I use Wireshark to capture SIP call flows, I start with Telephone–>VoIP Calls to find all the SIP call flows. I cleared the Wireshark buffer before this test so you will only see the flows involved with the transfer.

Notice there are two calls.  I will choose the first call and click on Flow to expand it.

I will now select the second call and press Flow.

As I explained in my conference article, you can simultaneously select both calls to see a combined flow.

This is a good time to stop and talk about what you are looking at. The first flow consists of all the SIP requests and responses between Kevin and Mike. The second flow consists of Kevin’s call to Wayne.

The combined flow can be divided into six parts:

1. The call from Kevin to Mike – from timestamp 9.874197 to 15.678657
2. Mike telling Kevin to transfer the call to Wayne – from timestamp 40.861666 to 41.081605
3. Kevin calling Wayne – from timestamp 41.085407 to 44.129618
4. Kevin informing Mike the status of the transfer – from timestamp 41.089734 to 44.129228
5. Kevin releasing the original call to Mike – from timestamp 44.128037 to 44130455
6. Kevin releasing the call to Wayne – from timestamp 48.684516 to 48.686046

Note that there is some crossover in terms of timestamps with steps 3 and 4. Step 4 begins before step 3 is finished. Also, step 6 has nothing to do with the transfer. It is simply Kevin releasing the call to Wayne after they were done speaking.

Steps 2 and 4 are the most exciting parts of this lab. This is where the transfer is initiated and the transferee informs the transferer of progress of the new call.

A SIP REFER is used to kick the transfer off. Instead of Mike performing the transfer, Mike uses REFER to delegate that responsibility to Kevin.

REFER uses two headers to initiate the transfer – Refer-To and Referred-By. In this example, Refer-To contains Wayne’s contact information. This instructs Kevin to send an INVITE to Wayne. Referred-By contains Mike’s contact information. This information can be shared with Wayne to let him know that Mike initiated the transfer request.

REFER creates a quasi-subscription between Kevin and Mike. This allows Mike to be informed of the progress of the call to Wayne. Like all SIP subscriptions, NOTIFY messages are used to convey state change. In this case, those changes are sipfrag messages that contain snippets of the responses that Kevin receives from Wayne – 100 Trying, 180 Ringing, and 200 OK.

This Wireshark screen capture shows the NOTIFY for the 100 Trying.  Notice that the Event is refer and the content-type is message/sipfrag.

Once Wayne answers the incoming call, Kevin releases the call to Mike. If for some reason the transfer did not succeed, the call between Mike and Kevin is still active and some other action could take place.

It is important to understand that a lot of this happens automatically.  I said that Kevin released the call to Mike, but in actuality, Kevin’s soft phone did the release.  The same is true for those NOTIFY messages.  No user interaction is required after Mike presses the transfer button and enters the SIP user ID of the Transfer Target.

That’s All Folks

I hope you enjoyed this as much as my article on conference. REFER is my very favorite SIP method, but until you see it in action, it can be a bit confusing. Let me know if the light bulb did not go off and you still don’t get it. I am always happy to help.

Tags: Call Transfer, REFER, SIP, Unified Communications, VoIP