[asterisk-bugs] [JIRA] Commented: (ASTERISK-17883) SIP CANCEL is broken when phone is not registered to asterisk (sip friend and/or sip user)

Wed Oct 3 15:22:27 CDT 2012

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197915#comment-197915 ] 

Matt Jordan commented on ASTERISK-17883:
----------------------------------------

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 at test.local>;tag=2459195543
To: <sip:2001 at test.local>;tag=as2cc6da29
Call-ID: 25f1c19c6e0a45b5713281c0e34256c6 at 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 at 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.

> SIP CANCEL is broken when phone is not registered to asterisk (sip friend and/or sip user)
> ------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-17883
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17883
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.4
>            Reporter: Artem Makhutov
>            Severity: Minor
>         Attachments: sip.log
>
>
> 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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira