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:58 | Date Closed: | |
Priority: | Minor | Regression? | No |
Status: | Open/New | Components: | 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 ? |