[Home]

Summary:ASTERISK-02625: 487 Message not sent after receipt of CANCEL
Reporter:tschroer (tschroer)Labels:
Date Opened:2004-10-18 07:28:56Date Closed:2008-01-15 15:11:15.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) mydiff.txt
Description:Based on RFC3261, a UAS receiving a CANCEL request should respond back with a 487 Error response.  On SIP to SIP calls with asterisk set up with canreinvite=yes, when an incoming call reaches *, but * has not sent back final response and the Calling party sends a CANCEL, asterisk will respond in the following manner:
Asterisk sends back an OK to the CANCEL from the calling party,
Asterisk sends a CANCEL to the called party,
Asterisk receives an OK back from the called party,
Asterisk receives a 487 message from the called party,
Asterisk sends an ACK to the 487 message

However, asterisk does not send a 487 message to the calling party.

****** ADDITIONAL INFORMATION ******

Here is the call flow of what appears to be occurring.  

Party A        Asterisk          Party B
 |---INVITE------>|                |
 |<--TRYING-------|                |
 |                |---INVITE------>|
 |                |<--TRYING-------|
 |                |<--180 RINGING--|
 |<--180 RINGING--|                |
 |                |<--180 RINGING--|
 |                |<--180 RINGING--|
 |                |<--180 RINGING--|
 |----CANCEL----->|                |
 |<---200 OK------|                |
 |                |-----CANCEL---->|
 |                |<----200 OK-----|
 |                |<-----487-------|
 |                |------ACK------>|

Technically, should the asterisk be sending a 487 message to the Calling Party?  I just downloaded the latest CVS version to confirm and I am still seeing this behavior when canreinvite is set Yes as well as when it is set to No.  I have queried the forums to get confirmation on the expected behavior, went through the associated web sites and even looked through the various documentation sources to verify before submitting this.  Hope this helps.

Comments:By: Brian West (bkw918) 2004-10-18 09:36:01

Can you quote the section of the RFC that deals with this specifically?
By: tschroer (tschroer) 2004-10-18 10:52:23

No problem, I'll cite a couple references:  Look at Section 9 Canceling a Request (second paragraph):

"...a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487)."

It goes on to say in 9.2 Server Behavior, 4th para...
"If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated).  A CANCEL request has no impact on the processing of transactions with any other method defined in this specification.

Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response." (which Asterisk does)  

The above was a change from 2543 which did not requre the proxy to send a 487 response.

-Tom
By: Brian West (bkw918) 2004-10-18 14:50:32

You do remember that asterisk isn't a proxy its a B2BUA...

bkw
By: tschroer (tschroer) 2004-10-18 15:49:30

No, I do realize that and was trying to avoid the word "proxy" and weighed that fact before submitting the bug report.  I would still think this behavior applies because of the hop by hop characteristic of CANCEL messages. In addition, I'll defer to the reference to B2BUA's in 3261; "A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS)."  It goes on with a little more detail, however, I think it indicates that the behavior would apply to *.  I would really like to submit a patch for this, unfortunately, I am not much help in that arena eventhough I tried to look around chan_sip thinking the answer would present itself.  Thanks.
By: Brian West (bkw918) 2004-10-18 15:57:34

Ok just making sure we are both on the same page :)

bkw
By: Mark Spencer (markster) 2004-10-18 22:26:10

We're not supposed to send 487 unless we *receive* the CANCEL, and then we send it on the original INVITE.  If we *send* CANCEL, we don't have a message to cancel!
By: Mark Spencer (markster) 2004-10-18 22:48:33

Okay nevermind I understand now.  Next time put "<pre>" and "</pre>" before/after your diagram :)
By: Mark Spencer (markster) 2004-10-18 23:13:05

Okay *now* it's ifxed in CVS.
By: Russell Bryant (russell) 2004-10-23 08:19:46

fixed in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:10:53.000-0600

Repository: asterisk
Revision: 4034

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r4034 | markster | 2008-01-15 15:10:52 -0600 (Tue, 15 Jan 2008) | 2 lines

Don't "ignore" on CANCEL (bug ASTERISK-2625)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4034
By: Digium Subversion (svnbot) 2008-01-15 15:11:15.000-0600

Repository: asterisk
Revision: 4062

U   branches/v1-0/channels/chan_sip.c

------------------------------------------------------------------------
r4062 | russell | 2008-01-15 15:11:15 -0600 (Tue, 15 Jan 2008) | 2 lines

Don't "ignore" on CANCEL (bug ASTERISK-2625)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4062