[Home]

Summary:ASTERISK-17883: SIP CANCEL is broken when phone is not registered to asterisk (sip friend and/or sip user)
Reporter:Artem Makhutov (artem)Labels:
Date Opened:2011-05-18 16:48:58Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_sip/General
Versions:1.8.4 13.3.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip.log
Description:I have discovered a bug while playing with asterisk and with the embedded sip client of an android mobile phone.

Canceling a call is broken when the mobile phone is not registered to asterisk.

When calling from the android phone and the other party picks up the phone everything works just fine. But when the other party does not pick up the phone and I hangup the call on the mobile then the other phone will never stop ringing.

This problem does not occur when the mobile phone is registered to asterisk.

Here is the relevant configuration of sip.conf:

[2005]
type=friend
defaultuser=2005
transport=udp
fromuser=2005
context=internal
host=dynamic
fromdomain=xxxxxxx
secret=xxxxxxx
qualify=yes
nat=yes
directmedia=no
disallow=all
allow=speex
allow=alaw
allow=ulaw
allow=gsm
allow=g729
allow=h264
Comments:By: Artem Makhutov (artem) 2011-05-18 17:02:12

Argh, somehow hit the back button while editing...

Bug titel:

SIP CANCEL is broken when phone is not registered to asterisk (sip friend and/or sip user)

Bug description:

I have discovered a bug while playing with asterisk and with the embedded sip client of an android mobile phone.

Canceling a call is broken when the mobile phone is not registered to asterisk.

When calling from the android phone and the other party picks up the phone everything works just fine. But when the other party does not pick up the phone and I hangup the call on the mobile then the other phone will never stop ringing.

This problem does not occur when the mobile phone is registered to asterisk.

Here is the relevant configuration of sip.conf:

[2005]
type=friend
defaultuser=2005
transport=udp
fromuser=2005
context=internal
host=dynamic
fromdomain=xxxxxxx
secret=xxxxxxx
qualify=yes
nat=yes
directmedia=no
disallow=all
allow=speex
allow=alaw
allow=ulaw
allow=gsm
allow=g729
allow=h264
By: Brett Bryant (bbryant) 2011-05-18 17:12:55

I have modified this bug report in response to a query from this reporter on IRC.
By: David Woolley (davidw) 2011-05-19 05:48:38

Looks to me that the To tag is missing.  I'm not sure if that is required.

The Trying didn't have one, but the Ringing does.  The CANCEL doesn't.
By: Santiago Gimeno (sgimeno) 2011-05-19 05:54:54

I don't think it requires the To tag. As per RFC 3261 - 9.1:

"The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags."
By: Artem Makhutov (artem) 2011-05-19 14:39:53

I think that the SIP messages are correct. Everything works fine as long as the phone is registered to asterisk.

The problem only happends when placing a call while the phone is not registered to asterisk.
By: Matt Jordan (mjordan) 2012-10-03 15:20:45.817-0500

This appears to be a problem with the device in question.  Prior to the device sending a CANCEL request, Asterisk (as the UAS) responded to the INVITE request with a 180 Ringing:

{code}
<--- Transmitting (NAT) to 192.168.10.187:44142 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.10.187:44142;branch=z9hG4bK95098c98e2a7f064a1438d784561680234;received=192.168.10.187;rport=44142
From: "2005" <sip:2005@test.local>;tag=2459195543
To: <sip:2001@test.local>;tag=as2cc6da29
Call-ID: 25f1c19c6e0a45b5713281c0e34256c6@192.168.10.187
CSeq: 2971 INVITE
Server: Asterisk PBX 1.8.4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:2001@192.168.10.1:5060>
Content-Length: 0
{code}

At this point in time, Asterisk has provided sufficient information to establish a dialog with the client.  Section 9.1 of RFC 3261 says the following:

{quote}
The following procedures are used to construct a CANCEL request.  The
  Request-URI, Call-ID, To, the numeric part of CSeq, and From header
  fields in the CANCEL request MUST be identical to those in the
  request being cancelled, including tags.  A CANCEL constructed by a
  client MUST have only a single Via header field value matching the
  top Via value in the request being cancelled.  Using the same values
  for these header fields allows the CANCEL to be matched with the
  request it cancels (Section 9.2 indicates how such matching occurs).
{quote}

That is, the tags *do* matter, and the CANCEL request must use both the header fields and the tags.  This is so the UAS can figure out what request to cancel.  Section 9.2 indicates how the matching occurs here:

{quote}
A UAS first processes the CANCEL request according to the general UAS
  processing described in Section 8.2.  However, since CANCEL requests
  are hop-by-hop and cannot be resubmitted, they cannot be challenged
  by the server in order to get proper credentials in an Authorization
  header field.  Note also that CANCEL requests do not contain a
  Require header field.

  If the UAS did not find a matching transaction for the CANCEL
  according to the procedure above, it SHOULD respond to the CANCEL
  with a 481 (Call Leg/Transaction Does Not Exist).
{quote}

Section 8.2.6.2 specifies:

{quote}

8.2.6.2 Headers and Tags

  The From field of the response MUST equal the From header field of
  the request.  The Call-ID header field of the response MUST equal the
  Call-ID header field of the request.  The CSeq header field of the
  response MUST equal the CSeq field of the request.  The Via header
  field values in the response MUST equal the Via header field values
  in the request and MUST maintain the same ordering.

  If a request contained a To tag in the request, the To header field
  in the response MUST equal that of the request.  However, if the To
  header field in the request did not contain a tag, the URI in the To
  header field in the response MUST equal the URI in the To header
  field; additionally, the UAS MUST add a tag to the To header field in
  the response (with the exception of the 100 (Trying) response, in
  which a tag MAY be present).  This serves to identify the UAS that is
  responding, possibly resulting in a component of a dialog ID.  The
  same tag MUST be used for all responses to that request, both final
  and provisional (again excepting the 100 (Trying)).  Procedures for
  the generation of tags are defined in Section 19.3.

{quote}

In other words, at the point Asterisk provided a To tag to the client (in the 180 Ringing), the client had to start using it.  Asterisk established a dialog with the client; not specifying the dialog properly means Asterisk *must* respond with a 481.
By: Mark Michelson (mmichelson) 2012-10-03 15:43:04.718-0500

I'm going to disagree with Matt's analysis here. First off, the quotation of 8.2.6.2 is irrelevant here because that is telling a UAS what to do when generating a response, not when verifying a request.

The big thing with CANCELs is that you are attempting to match a *transaction*, not a *dialog*. In order to match a transaction, all that is required is the following, from section 17.2.3:
{quote}
     1. the branch parameter in the request is equal to the one in the
        top Via header field of the request that created the
        transaction, and

     2. the sent-by value in the top Via of the request is equal to the
        one in the request that created the transaction, and

     3. the method of the request matches the one that created the
        transaction, except for ACK, where the method of the request
        that created the transaction is INVITE.
{quote}

To further bring home the point that the CANCEL requires no to-tag, I present this e-mail from the SIP-implementors' list from July 2001: https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-July/001631.html

In it, Jonathan Rosenberg, one of the authors of RFC 3261, clarifies the specifics behind SIP CANCEL. Specifically, he states:

{quote}
Everything in the CANCEL matches the INVITE. If there were no tags in the
INVITE, there are none in the CANCEL. That is the intent of the above.
{quote}

"The above" is the portion of RFC 3261 quoted by Santiago previously.

I conclude then that it is fine for a CANCEL not to contain a to-tag. This issue was reported against 1.8.4. I'm curious whether this has been fixed in the many revisions to chan_sip.c since then. This should be easy to verify using SIPp or some other such tool.
By: Matt Jordan (mjordan) 2012-10-03 15:45:32.481-0500

Yup, I'm wrong.  Missed the part that the CANCEL request had to match the header/tags in the initial request, not the response.
By: Walter Doekes (wdoekes) 2012-10-16 02:39:32.349-0500

Artem: are you able to test a newer version and/or include 'core set debug 10' logs?
By: Paul Belanger (pabelanger) 2012-10-30 14:46:38.353-0500

Ran into this issue today.  I believe if you set

sip.conf
[globals]
pedantic=false

You phone will work.  Why it works is another story.
By: Alexander Traud (traud) 2015-06-01 05:04:50.266-0500

Same with Asterisk 13.3.2. Only few Android phones offer that SIP client, for example
* Sony Xperia Z1 Compact (Android 4.4.4) Menu » Settings » Call » (Internet Call Settings) Accounts
* Google Nexus 4 (Android 5.1.1) Menu » Phone » Options » Settings » Calls » Calling accounts » (SIP settings) SIP accounts

In my case, it does not make any difference whether Android is registered or not. The SIP-CANCEL is rejected with STATUS 481. Only if Asterisk ignores tags (sip.conf: pedantic=no), the call is hung-up correctly. Thanks for the hint, Paul!
By: Carlos Ramos (carragom) 2016-01-05 12:51:45.873-0600

Hi I would like to confirm this bug as well. Asterisk 11.13.1 and Samsung Galaxy S5 with Android 5.0. If pedantic=no it hangs up correctly. If pedantic=yes it does not hang up. Is there any missing information to resolve this ?