Summary:	ASTERISK-07092: If CallerID name contains single quote Asterisk answers call but doesn't send it anywhere
Reporter:	caribou7 (caribou7)	Labels:
Date Opened:	2006-06-04 16:29:02	Date Closed:	2011-06-07 14:08:15
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When using a SPA-3000 to receive incoming calls, sometimes the CallerID name field contains only one quote. Asterisk correctly identifies the problem but makes no attempt to work around it, instead simply answering the call, holding the line open a few seconds, and hanging up. I would think that if Asterisk can identify the problem, it should be able to more gracefully handle it. I can definitely verify that it is the single quote mark that causes the call to fail - if the CallerID contains two quotation marks, the call is processed normally. ****** ADDITIONAL INFORMATION ****** I am reposting this publicly, it is a duplicate of report 0007277 to which I attached a file that I wanted kept private, but making the view status private made the entire report private (not just the attached file) which is not what I intended.  Hence this public repost. Before I begin please note I am not a programmer but I am going to describe this as best I can. I am using a Sipura SPA-3000 to receive calls. It appears that the phone company sometimes sends quoted strings in the Calling Name field. For whatever reason, perhaps a Sipura bug or perhaps the phone company is sending it this way, the call comes into Asterisk showing this in a SIP debug: From: "Grand Rapids M <sip:6165555555@192.168.0.200>;tag=19c720c63634095bo1 (Phone number has been munged but otherwise this is exactly as shown. Further down it shows this: Jun 4 00:55:17 WARNING[2883] chan_sip.c: No closing quote found in '"Grand Rapids M <sip:6165555555@192.168.0.200>;tag=19c720c63634095bo1' Which means that Asterisk is identifying the problem, but not working around it. The next line says this: Jun 4 00:55:17 NOTICE[2883] chan_sip.c: From address missing 'sip:', using it anyway And still further down, it shows this: Jun 4 00:55:17 DEBUG[2883] chan_sip.c: Checking SIP call limits for device Jun 4 00:55:17 WARNING[2883] chan_sip.c: No closing quote found in '"Grand Rapids M <sip:6165555555@192.168.0.200>;tag=19c720c63634095bo1' Jun 4 00:55:17 WARNING[2883] chan_sip.c: Huh? Not a SIP header ("Grand Rapids M <sip:6165555555@192.168.0.200>;tag=19c720c63634095bo1)? Jun 4 00:55:17 VERBOSE[2883] logger.c: Reliably Transmitting (NAT) to 192.168.0.3:5061: SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.0.3:5061;branch=z9hG4bK-1bc90cb2;received=192.168.0.3 From: "Grand Rapids M <sip:6165555555@192.168.0.200>;tag=19c720c63634095bo1 To: <sip:s@192.168.0.200>;tag=as256207c0 The call is answered, but there is dead silence, and after a few seconds it disconnects. I am using FreePBX and discussed this with the developer in the IRC channel. He said to be sure to let you know that I have a s exten in [default] and it's not hitting that. For the manager and anyone that can access the private status bug reports, please see the more complete snip from the log that is attached to ASTERISK-7217277.
Comments:	By: Serge Vecher (serge-v) 2006-06-04 16:39:58 caribou7: SPA-3000 is clearly not acting within specifications by not using closing braces. If you review the notes in a now closed duplicate bug 7031, there is a workaround you can use. Although, your best strategy is to contact Linksys and ask them to address this issue in their next firmware release, since it's clearly broken now. By: caribou7 (caribou7) 2006-06-04 16:43:07 With all due respect, this is NOT a duplicate 007031 at all... this is using SIP, not ZAP, it's a SPA-3000, not a 941, and the issue isn't even the same. Edit: Sorry, I hadn't read all the way down in the notes - it appears that the issue is somewhat related but I still think not the same.  Also there are probably thousands of Sipuras out there with this bug and I think that if Asterisk can identify the problem enough to display an error message, it would be really nice if it could also compensate for it.  In my case this is a Sipura SPA-3000 with the 2.0 hardware and while they are issuing firmware updates for the 3.0 series (probably post acquisition by Linksys) this is a regular (non-Linksys) Sipura that I believe predates the acquisition, and in any case there doesn't seem to be any recent firmware updates for it. By: Serge Vecher (serge-v) 2006-06-04 17:01:01 caribou7: it would be nice, agreed, that Asterisk would handle a broken user-agents, but it is a long-standing policy not to do so in the main tree. If you are insterested as to the reasons, I encourage you to read on the recent discussions on the asterisk-dev list. As I've mentioned, there are code / dialplan workarounds provided in 7031. Make the best use of them, as I believe, for your current situation that is the best solution. By: caribou7 (caribou7) 2006-06-04 17:21:23 I tried using "pedantic=yes" (as suggested in 7031) in the incoming trunk configuration but that that did not seem to affect the problem in any way - the incoming calls still failed.  I'm sorry but when you say "there are code / dialplan workarounds provided in 7031", I'm not seeing them (other than the suggestion to try pedantic=yes).  I suppose I should mention that I'm using FreePBX (if that wasn't clear from my original report) so please don't make any unwarranted assumptions about my skill level here - again, if you can be more specific as to exactly what I should try, it would be much appreciated. Is it really the policy of Asterisk developers that if a call comes in with bad CallerID to simply drop the call, rather than at least making an effort to route it (perhaps without any CallerID info)?  I'm not necessarily saying you need to try and figure out what the correct CallerID string should be (though, again, that would be nice considering that this is apparently a not uncommon problem) but it's the sending of calls into la-la land that I'm questioning here.  The call ought to be disposed of in some graceful manner, I would think. Please remember that users can't control what hardware manufacturers do.  Yes, I could request that Sipura issue new firmware, but realistically, what are the chances they are going to do that?  And that's assuming that I can even figure out how to contact the right people to get this fix made (if you have any suggestions in that regard, please let me know). In any case, can you please be a bit clearer about exactly what I can do to work around this issue? By: Serge Vecher (serge-v) 2006-06-04 17:34:18 I referred to note: 0046059 in 7031 By: caribou7 (caribou7) 2006-06-04 18:06:52 Well, there are two problems with the reference to note: 0046059 in 7031 - first, it appears that this deals with a problem with ZAP channels, not SIP channels, so I'm not sure that the fix suggested there would be appropriate.  However the bigger issue for me personally is that when I go to the page referenced in that note (http://www.voip-info.org/wiki/view/D-link+DVG-1120) it seems to be talking about a completely different situation, a different version of Asterisk, but in the end I do not understand what the heck they are talking about there.  Did I mention I am a FreePBX user? Would it be possible to request that "joshnet - administrator" take a look at this?  He at least seemed to be a bit more helpful in the other case.  I feel like you are deliberately making cryptic suggestions that are beyond my ability to comprehend (and please no sarcastic remarks, if I don't know how and you aren't willing to give me clear step-by-step instructions as to what I need to do, sarcasm isn't going to help, and I just have a feeling that's what's coming next). By: Olle Johansson (oej) 2006-06-05 01:00:22 First, the "s" extension is *not* a wildcard extension. As requested by the bug guidelines we need to see a SIP debug to determine why the call fails. nothing in this bug report indicates why the call fails, just that we correctly do not parse a broken header. Please upload a full SIP debug with debug and verbose set to 4 so I can check what happens with this call. Thanks. By: Olle Johansson (oej) 2006-06-05 10:22:52 From the log in 7277, you have no "s" extension in the default context and Asterisk answers 404 not found. Since we can't read the faulty From: header, we can't match properly. By: caribou7 (caribou7) 2006-06-05 13:38:43 I'm not ignoring you guys, just not feeling well today.  Regarding the thing about the s extension, I am only relaying what the FreePBX developer said in the IRC channel. Next time I see him online I will ask him about the comment "you have no "s" extension in the default context" however he did specifically say (before I even posted this) that I have a s exten in [default] and it's not hitting that, so I think he may have anticipated this line of thought.  But I really am not feeling well at the moment so please give me time to research this further. By: caribou7 (caribou7) 2006-06-06 01:27:21 oej, please see this pastebin (too long to upload): http://pastebin.ca/62443 Note in particular that there are lines such as this: Jun  6 00:53:17 DEBUG[8500] chan_sip.c: Found no match for SIP option: x-sipura (Please file bug report!) Also, in case you are wondering, I did a search and replace on the phone number so as to keep it concealed (it shows as 6165555555, which replaces the actual calling number). By: xrobau (xrobau) 2006-06-06 02:04:56 FWIW, all freepbx installs come with a [default] that consists soley of this: [default] exten => s,1,Playback(vm-goodbye) exten => s,2,Macro(hangupcall) (Macro-hangupcall does CDR stuff) I think that this is a bug in asterisk - an invalid header should be mapped to 's@default' or 's@whatevercontextisspecified' - the default user context is 'from-internal', which has 's,1,Macro(hangupcall)' (and the same for h). So, lets me clarify - A SIP call is coming in. It has an invalid 'From' header. It never reaches the dialplan, because (and I'm guessing here) it's trying to match (null),1,whatever in the dialplan, and it always returns 404. Does that help? Edit: We know it's an issue with the 'From' because this works perfectly _except_ for when the Caller ID Name is 15 characters long, which causes the 'From' to drop the closing quote. By: Olle Johansson (oej) 2006-06-06 03:27:47 This debug indicates to me that the SIPura is the one having the problem. We do reply to every invite (with the broken header), it keeps resending the same invite, without the proxy authorization. If you read this, we also do match peer "pstn". Asterisk is doing nothing wrong here, really. I guess we could answer "bad headers" and issue an error, but we're polite and accept quite a lot.... I see no bug in the Asterisk implementation here. By: xrobau (xrobau) 2006-06-06 03:30:19 Good point - that is not the log I was looking at before. The log I saw was full of asterisk returning 404's. Caribou7, can you please paste the log that actually shows the error please? 8) By: Olle Johansson (oej) 2006-06-06 04:03:16 Why should an invalid from header be matched to a different extension? That's just wrong. We only use the from to match with users, to determine the correct incoming context. If we can't match a user because of an invalid From: header, it's sent to the generic context defined in [general] or "default" if there's nothing in general. Which is the correct behaviour. "s" again is not a wildcard extension at all. It is only used if we have no extension given, like dialling to a domain or auto-answering in zap. It's also used in macros. By: xrobau (xrobau) 2006-06-06 05:14:47 oej: "Why should an invalid from header be matched to a different extension? That's just wrong." And that's why I told him to post the bug here! (The 'to' is s@ip.add.re.ss, which is why I keep talking about 's') By: caribou7 (caribou7) 2006-06-06 12:50:47 Hmmm... okay, part of the problem is that since I first posted this, we upgraded the firmware on the Sipura to the latest release (originally I did not think we could do this because it is 2.0 hardware and the Sipura site implies that you cannot use 3.x firmware in the older hardware but it turns out that's not the case; the newer firmware works as expected on the 2.0 hardware).  We made this upgrade yesterday afternoon and the logs I posted in the pastebin were from last night.  Unfortunately, it appears this changed something in the way the problem occurs.  Before, when a call was placed, Asterisk would answer the call, wait a few seconds, then hang up.  Now it appears that when the CallerID is broken, it is ignored completely, that is, the call is never answered at all. I cannot now create a new log file but I can point you to http://pastebin.ca/62620 which at least shows a snippet of what was happening prior to the Sipura upgrade.  Hopefully it will be enough to answer your questions. Edit: Also, I went back to my logs from a couple days ago and found a pre-upgrade log snippet that shows the 404 errors, that is pasted to http://pastebin.ca/62627 Further edit: Also, regarding the pastebin I posted last night, some of the lines specifically say: Jun 6 00:53:17 DEBUG[8500] chan_sip.c: Found no match for SIP option: x-sipura (Please file bug report!) If it's not a bug, why does it specifically ask me to file a bug report?  :-) By: caribou7 (caribou7) 2006-06-06 14:44:25 I'm trying to help narrow the problem down as best I can.  I discovered that I can in fact change the "s" to something else in the Sipura, so I replaced it with one of my valid DID numbers for which there is already an incoming route defined.  Yet even after doing that, calls that come in with a CallerID with a single quote fail, while those that come in with a CallerID with two quotation marks succeed.  I am NOT saying that the way that the s extension is handled isn't a problem, and I also note that even when the call succeeds, I still get the message that asks me to please file bug report.  It's beginning to look like there may be several issues here. I have created yet another pastebin, this one at http://pastebin.ca/62666 which shows the results of two calls, first one which had a short Caller ID name and completed normally, and then one that failed, the only significant difference in the second one is the length of the Caller ID name and the fact that it only had one quotation mark as a result.  Please note that the "s" extension is not referenced in either call, as far as I can tell. By: Olle Johansson (oej) 2006-06-06 15:44:50 please check which contexts the calls are routed to. Onsdagarna mobile, cant check those logs now... sorry By: xrobau (xrobau) 2006-06-06 16:23:00 Caribou7, this is now, definately, a sipura bug. Asterisk is doing things 100% correct - it's sending back the corrupt header. However, the issue with the long one is that the sipura _thinks_ that it's sending "Grand Falls MI", and when asterisk sends back the 407 (request for auth) it's sending back "Grand Falls M <sip..." (which is exactly what it was given). This is confusing the sipura, and it keeps re-sending the invite, rather than going 'Oh. You want auth'. If you email Sipura that specific pastebin, it's reasonably obvious that the Sipura is the one being the bad guy here. --Rob (oej: Please close - not an asterisk bug. Apologies) By: Serge Vecher (serge-v) 2006-06-06 16:24:37 as requested ... By: caribou7 (caribou7) 2006-06-06 18:26:40 There are two things I want to make clear before this issue is closed forever (although I have e-mailed Sipura about this, but don't know if they will respond since I am not one of their corporate customers). First, it is not the Sipura *creating* the CallerID with a single quote - that is how it's *receiving* it from the PSTN line (which is an entirely separate issue, but anyway...).  You are saying that the Sipura is still doing something wrong - fair enough, but I wanted to make it clear that it's not the Sipura generating the bad CallerID string in the first place. Second, there is still the issue of the message: Jun 6 00:53:17 DEBUG[8500] chan_sip.c: Found no match for SIP option: x-sipura (Please file bug report!) Seems that message should either be addressed or the message itself removed, since it is requesting that people file bug reports. That is all I wanted to add to this.  If you feel this does not merit any further attention, I will let it go and see if Sipura is able and willing to address this. By: Olle Johansson (oej) 2006-06-08 09:02:34 I will handle the x-sipura stuff. I am really interested in getting those reports. Thanks.