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.
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.
Reblogged this on SIPALOOZA and commented:
Great summary of SIP CANCEL messages. Thank you very much Andrew!
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?
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
[…] https://andrewjprokop.wordpress.com/2014/05/07/understanding-sip-cancel/ […]
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.
Thanks for the suggestion. I just might try a few things to see what I can come up with.
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 ?
It sure sounds like it, but in practice, I have seen them mixed together.
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.
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?
Per mi call flow:
183 Sessin Progress
487 Request Terminated
We have a lot of calls with the same structure.
That’s a new one to me. You may need to find additional debug logs to figure this out. Good luck.
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.
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 ??
Do you see any SIP messages coming out in the ISUP to SIP case? If so, have you looked at them?
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.”
Interesting. I have never seen this done in real life.
I am Getting a Cancel after PRACK..how to check the same
I am not sure what you are asking. Are you sending or receiving the PRACK?
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.
I suppose that the call could potentially ring forever.
Hmm , Shouldn’t there should be some timeout mechanism in SIP server for that I yes do they propagate the same on either side.
There is the Expires header to stop infinate ringing.
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.
@Viren Negi. i think its left to the client side timer, once the timer expires, client can automatically sends CANCEL to other party and indicates the application. which in turn can play some informatory message to user.
I Suppose call will timeout after sometime
Would that generate any event then
A 408 Request Timeout response would be returned.
That Need to be checked.. 🙂
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?
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?
In that case, the call would be rejected with some form of 4xx response.
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??
I expect that most SIP clients would not allow holding a held call.
CANCEL releases unacknowledged session and BYE releases an acknowledged session.
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
I really don’t know. Can you be more specific?
Please check for the network..check for the latency..
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?
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.
Thanks Saurabh. Will check those. The INVITE actually gets received before a CANCEL is sent.
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 ?
I believe it’s a proprietary header used by Bria clients. It may stand for register instance.
Hi. Does a 180 ringing without a PRACK when PRACK is required mean the phone did not physically ring?
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.
CANCEL has the same branch id as INVITE. But it is a different transaction, Plz tell me HOW??
Hi Andrew, Could you please explain how Andrew is sending cancel message, It should be BYE instead of cancel message.
BYE is only sent for an established session. CANCEL is sent before the final response to a session.
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).
Sorry. I am not familiar with Freeswitch or FusionPBX. Good luck.
Excellent 🙂 No more doubts left regarding CANCEL now.
Cancel is speate transaction or same ?
487 Request terminated
How many transaction in CANCEL request ??
Cancel request contain To,From tag?
Hi Andrew ,
In case Andrew —> Jennifer , Jennifer cuts call , though keep ringing on Andrew side. what may be causes for this . This is even happen in the case Jennifer answers and then cut. i.e. Jennifer answer and cuts , but Andrew side call is not going to terminate .
Jennifer cuts call? What do you mean by that? A CANCEL will be sent to Jennifer if Andrew chooses to end the session prior to it being established.
re-inv to put call on hold from callee
Bye from callee
Is Bye the correct behavior or should this be Cancel?
What are you trying to do? Not accept the hold?
I am trying to figure out if this behavior from the far end of terminating this particular call is as per rfc or not .. there are some issues following the Bye message like the 200 ok for Bye getting retransmitted several times which is why I want to know if sending a Bye is correct behavior in the first place..
We the Re-INVITE ever acknowledged with a final response? It needs to be.
No the re-inv never gets acked.. Bye comes right after the re-inv which is why I think the bye might not be correct behavior.. but then the re- invite is only changing an existing dialog .. does a Bye make sense here ?
There is option to leave the session after receiving 200 OK (call was answered),
what i should send back? special ACK? or some other message?
the main idea is that my service just need to know about answer then don’t want to stay in dialogue
[…] https://andrewjprokop.wordpress.com/2014/05/07/understanding-sip-cancel/ […]
Hi Andrew, Is it possible for a UaC send a CANCEL request just after receiving a reliable provisional response? that is without completing PRACK and ACK messages
Hi Andrew, Thanks for the explanation!
I have a scenario where CANCEL is being sent in a very short time after sending Invite (less than 2 secs). This happened 27 times in small Drive test. All these 27 calls are being considered as “Call Setup Failures”. I guess the explanation above for CANCEL msg doesn’t match this scenario because UE doesn’t even wait until B party Rings for a long time or hangup. (Here B party is a Landline test call number)
eNB later sends “400 Bad Request” to UE but doesn’t mention any cause. This Bad request could be “Sip Syntax Error”, ” Invalid Host”, “Invalid Content Length”, etc but in this case there is no info inside the message.
Has anyone experience with such scenarios. What could be the problem?
Full call flow is like this for all 27 calls:
183 Session Progress
400 BAD Request
We have a similar query to what others have asked here…we have a scenario where we are connected to an onward carrier with SIP-I, for a number of incoming / terminating calls to our network – it appears we don’t receive BYE when A party clears the call – we get CANCEL, the CANCEL doesn’t include an ISUP Release – so calls appear to hang.
Would you assess this is normal behaviour..?
Doesn’t seem normal to me.
i have a scenario where Andrew cancels the call but it still continues to make duration and finally ends after 13 seconds by receiving bye from Jenifer why the call didn’t ended earlier ?
Did the Cancel make it to the far-end? Was it acknowledged?
Your blog is one of the best related to VOIP. I read all your articles and I think this should be continued in future so we can get benefit from your knowledge ! 🙂
CANCEL message has everything same as initial INVITE except the method of CSeq, so how will it be separate transaction when it is using same branch and CSeq number.
Read RFC 3261 section 9.1.
Thanks Andrew for your valuable info
Andrew —> Jennifer,then Jennifer cuts the call before the session Establishment(Before picking the call) then what will be the call flow.
Cuts the call? What does that mean? Jennifer can send a 4xx final response (e.g. 486) which will force the UAC to terminate the session.
what will happen, if ACK for 200OK of INVITE drop , will call drop by server ?
If yes What will be SIP error code ?
The 200 OK will be resent.
Thanks for this blog and it helps a lot.
here is my question, lets say UAC received 100trying but still it re-transmits INVITE. what should be the UAS behavior in this case?
Send another 100
Your blog is all that is good in the world.
If only the world was that simple! 🙂
What happens when the call is torn down by a Cancel with a SIP cause 487.
Reason: SIP;cause=487;text=”Request Terminated”
Is the response a 200 OK to the Cancel or should it be an ACK to the Invite to close the session?
How many transcations in CANCEL call flow?
is it 2 or 3 transactions?
Thank you for session .
I have scenario here , after 180 ringing getting CANCEL message within 8 sec how do we know whether call was dropped or any other issue ?
ON success scenario send 183 ringing after that 180 ringing along with 200 ok and call was established.
IS this something offer issue ?
You know that the call has dropped when you see final responses for the CANCEL and the INVITE.
Thanks for the wonderful blog.
I have a doubt regarding sip bye and cancel.
Is it possible to receive a non 200 OK response such as 401 or 403 for these 2 methods?
In that case if non 200 responses are received should we consider the call to have ended?
If I received a 401, I would resend with the proper credentials. If I received a 403 something is terribly wrong and I would expect the call to be torn down.
I like your blogs. They are precise and simple to understand.
I would like to know how a SIP proxy usually handles CANCEL in a conference context.
1. Does it send CANCEL to all the invitees of the conference?
2. If so, how does it handle the multiple responses from the invitees?
3*. Basing on these responses, how does it decide the response sent to the orignal caller?
4. What happens if some of the invitees accept the INVITE before the CANCEL reaches them?
There are multiple such complex scenarios I can think of in a conference context. Is there a guide book/ RFC / 3GPP standard (incase of mobile networks) for conferences based on SIP? Any help would be much appreciated.