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.


  1. Reblogged this on SIPALOOZA and commented:
    Great summary of SIP CANCEL messages. Thank you very much Andrew!

  2. Roger · · Reply

    What happens when Jennifer answers the call at roughly the same time that Andrew cancels the call?
    In that case, the 200 OK that Andrew receives is a response to his INVITE and not to the CANCEL. And Jennifer will see a CANCEL instead of an ACK as the response to her 200 OK. What happens next?

  3. Good question, Roger. Thankfully, the IETF already has an answer. Take a look at RFC 5407 for race condition scenarios. The call will receive a BYE once the condition is realized. http://tools.ietf.org/html/rfc5407

  4. Amatus Saboor Husain · · Reply

    Hi Andrew,

    how can we determine whether call was dropped (due to bad network condition, i.e. from core and not UE) or not due to some network condition.

    Can you share any pcap where Timer expiry for BYE message has been received.

    1. Thanks for the suggestion. I just might try a few things to see what I can come up with.

  5. Hi Andrew,
    RFC3261 (chap 9.2) If the original request was an INVITE, the UAS
    SHOULD immediately respond to the INVITE with a 487 (Request
    Does it means 487 should be sent before 200 OK for CANCEL ?

    1. It sure sounds like it, but in practice, I have seen them mixed together.

  6. Alberto · · Reply

    Hi Andrew,

    We are handling an issue where the calls are dropped with a bye instead a cancel, we know that the originating number hangs up the call before the destination number anwer.

    We are able to get on the SBC(NOKIA SIEMENS) and take a look, but here we would like to know if can tell us where we can review this feature.

    Thank you

    1. An answered call (200 Ok received for an INVITE) should always use BYE. CANCEL is only sent for non acknowledged sessions.

      Are you sure that that a 200 Ok wasn’t sent? Have you looked at the full call flow?

  7. Alberto · · Reply

    Yes Andrew,

    Per mi call flow:
    183 Sessin Progress
    180 Ringing
    200 OK
    487 Request Terminated
    ACKT sip
    We have a lot of calls with the same structure.

    1. That’s a new one to me. You may need to find additional debug logs to figure this out. Good luck.

  8. In the given scenario, Number of Transaction will be One as the ACK came for non 2xx response. In this picture, if we are adding a intermediate proxy [in between UAC and UAS] then will there be any change to the number of transaction? And it will be helpful if you could share the CANCEL scenario call flow using a intermediate proxy.

  9. i have a Question about Groomer device ??
    we’re working on it and we can make a call from SIP to ISUP but not from ISUP to SIP what would be the problem ???
    or what can stop the connection between these two ??

    1. Do you see any SIP messages coming out in the ISUP to SIP case? If so, have you looked at them?

  10. From RFC3261, the caller’s UE is allowed to send a BYE in an early dialog. It means that the specific early dialog has to be terminated. Not many people know this though.

    “The caller’s UA MAY send a BYE for either confirmed or early dialogs, and the callee’s UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs.”

    1. Interesting. I have never seen this done in real life.

  11. saurabh ginti · · Reply

    I am Getting a Cancel after PRACK..how to check the same

    1. I am not sure what you are asking. Are you sending or receiving the PRACK?

  12. I have a question,
    “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.”

    Imagine their is no *VOICE MAIL* and considering the Jennifer never pick up the call and neither Andrew hangs the call what would happen in those scenario.

    1. I suppose that the call could potentially ring forever.

      1. Hmm , Shouldn’t there should be some timeout mechanism in SIP server for that I yes do they propagate the same on either side.

      2. There is the Expires header to stop infinate ringing.

      3. So, would in that case either party would be getting some sort of event after it Expires like CANCEL and ACK.If yes what are those event.

  13. saurabh ginti · · Reply

    I Suppose call will timeout after sometime

    1. Would that generate any event then

      1. A 408 Request Timeout response would be returned.

  14. saurabh ginti · · Reply

    That Need to be checked..🙂

  15. saurabh ginti · · Reply

    Hi Andrew :

    Working On a SIP platform and Inn G711 calls are getting matured and DTMF is working fine but when I am using AMR-NB calls are not maturing and somtimes DTMF is not working any suggestion?

  16. Lkhagvadorj.ba · · Reply

    Hi Andrew:

    I have a question what if Jennifer does not want to answer and presses the busy button immediately on her Softphone or VoIP phone. What would be the call flow then?

    1. In that case, the call would be rejected with some form of 4xx response.

  17. Hi,

    Suppose two user’s(A and B) session is in progress and if A put call on hold and after that B also put hold, what will happen after B put call on hold?

    Is cancel request terminate the session or Bye request terminate the session??

    1. I expect that most SIP clients would not allow holding a held call.

      CANCEL releases unacknowledged session and BYE releases an acknowledged session.

  18. Hi,
    What if it takes a really long time before an INVITE is received from dialing state and by the time this arrives, a CANCEL is sent. What could be the issue

    1. I really don’t know. Can you be more specific?

      1. saurabh ginti · ·

        Please check for the network..check for the latency..

      2. Okay. What I mean is if for example the phone dials a number and the INVITE takes a ‘long’ time say 30s to reach the other device, the terminating device cancels this request with a CANCEL and then 487 message. Could the delay be the reason the terminating device is canceling the request?

  19. saurabh ginti · · Reply

    IF the Invite is taking the time to reach to terminating device then how can the terminating device can send a respose?

    However after the Invite is sent then any delay is there the request can be cancelled need to check the timeout configuration.

    1. Thanks Saurabh. Will check those. The INVITE actually gets received before a CANCEL is sent.

  20. Hi,
    i have a question and i hope i ind the answer here🙂
    X-lite add “rinstance” field in the SIP header.
    what’s the role of this field ?

    1. I believe it’s a proprietary header used by Bria clients. It may stand for register instance.

      1. Hi. Does a 180 ringing without a PRACK when PRACK is required mean the phone did not physically ring?

      2. No. A PRACK is only used to ensure that the 180 Ringing is received by the UAC. It does not control whether the phone rings or not.

  21. Hi,
    CANCEL has the same branch id as INVITE. But it is a different transaction, Plz tell me HOW??

  22. Harikrishna · · Reply

    Hi Andrew, Could you please explain how Andrew is sending cancel message, It should be BYE instead of cancel message.

    1. BYE is only sent for an established session. CANCEL is sent before the final response to a session.

  23. James Jordan · · Reply

    I’m having a big problem with this particular SIP reason and I was hoping you might have some insight. I’m using Freeswitch with FusionPBX and my employees are used to have a missed call on their phone when someone calls (and the ring group is rang). I’ve found the variable ignore_completed_elsewhere=true but it’s not working for me. Any ideas? We just need to see all our calls, if they were to show up in answered calls that’d be fine too🙂 (since they’re not technically missed).

    1. Sorry. I am not familiar with Freeswitch or FusionPBX. Good luck.

  24. Excellent🙂 No more doubts left regarding CANCEL now.

  25. Surender Singh · · Reply


    Cancel is speate transaction or same ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: