Understanding SIP CANCEL

As I have said on a number of occasions, I occasionally teach a two and half day SIP class. While that’s hardly enough time to become a SIP expert, my students always leave with more than enough knowledge to make educated decisions in regards to SIP endpoints, applications, and trunks. Although some may never again have a compelling reason to use Wireshark to trace SIP call flows, just knowing that they can is often good enough.

Every class is different and no two students are alike, but I find commonality in the things that they absorb quickly and the things that require a little more explanation. One of those from the latter camp is the CANCEL request.

On the surface, CANCEL doesn’t sound too complicated, but there are a few aspects that are a wee bit confusing.

Before I delve into the details, let’s take a look at a basic call flow.

Andrew placed a call to Jennifer and Jennifer answered.  They spoke for a while, but eventually Jennifer grew weary of speaking to Andrew (who can blame her?) and released the call. The session began with INVITE and ended with BYE. Pretty typical stuff.

Note that BYE is used to shut down an established session. In SIP speak, an established session is one that received a final response of 200 OK.

Let’s look at a different scenario. Imagine that Andrew calls Jennifer, but this time Jennifer doesn’t answer the phone. Andrew could wait until the call rolls to voice mail, but he doesn’t like leaving messages so he simply hangs up the call.

What happens now? I told you that BYE is used to release an established session, but clearly this call hasn’t received a final response. Jennifer’s phone is still ringing and on the verge of rolling over to voice mail.

This is where CANCEL comes in. Unlike a BYE, CANCEL shuts down a session that has not received a final response.

So, what does this new call flow look like?

The CANCEL informs Jennifer that Andrew is releasing the session prematurely and Jennifer needs to do the same on her end. In other words, Jennifer’s phone should stop ringing and return to an idle state.

It’s important to realize that the 200 OK in the call flow is not for the INVITE. Rather, it’s Jennifer acknowledging that she received the CANCEL and has begun the process of tearing down the session. She does this by stopping the ringing and returning a 487 Request Terminated to Andrew. The 487 is the final response for the INVITE sequence.  This causes Andrew to respond with an ACK.

It’s absolutely crucial that the 487 be sent. Otherwise, Andrew (and any stateful proxies between Andrew and Jennifer) will not properly release the session.

Call Forking

CANCEL is essential to call forking. Call forking occurs when someone calls a user that is registered to two or more devices at the same time. Every registered device will ring, but only one can be answered. This means that the remaining ringing calls must be cancelled.

Unlike the situation where Andrew releases the unanswered call to Jennifer, Andrew does not send the CANCEL(s). In fact, Andrew doesn’t even know that all those devices are ringing because call forking is performed by a SIP proxy on Andrew’s behalf. All that he knows is that he made a call, something rang, and the call was answered.

This means that the proxy will send CANCEL messages to all remaining ringing devices after the call is answered.

In the context of Avaya, the SIP proxy is a Session Manager and call forking is supported by the multiple registration feature. This feature allows a single user to register up to ten devices at time. I personally register four devices – my 9641 desk phone, One-X Mobile for IOS, One-X Communicator on my PC, and Flare Experience for iPad.

Well, that’s it. Remember, BYE is not CANCEL and CANCEL is not BYE. They both perform the task of releasing sessions, but it’s all about when those sessions are released. Thankfully, this is done in software and the user simply hangs up the phone and lets SIP do the rest.

Tags: Avaya, Avaya Aura Session Manager, Call Forking, Cancel