Summary:	ASTERISK-17538: SIP similar user/peer names are not properly identified when authentication and possibly more
Reporter:	Sherwood McGowan (rushowr)	Labels:
Date Opened:	2011-03-10 09:44:49.000-0600	Date Closed:	2011-06-07 14:05:29
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) test-mtv2-to-stl.pcap ( 1) test-stl-mtv2.pcap
Description:	This problem has been discovered before but I can't find any reported issues, so I'm starting a new one. Please forgive me if my Mantis searching was flawed. I've experienced this with the latest 1.6.2.x and 1.6.0.x When I have two SIP endpoints/trunks defined that have largely similar names, Asterisk does not recognize the second definition, and therefore I cannot make the second item place or receive a call through the Asterisk system. In my example I have two Asterisk servers I'm trying to get to pass certain calls between each other. The first server (STL) is configured thusly: [MTV-peer] username=STL-user fromuser=STL-user secret=EXAMPLE ; --snip-- [MTV-user] username=STL-user fromuser=STL-user secret=EXAMPLE ; --snip-- [MTV2-peer] username=STL-user fromuser=STL-user secret=ANOTHER ; --snip-- [MTV2-user] username=STL-user fromuser=STL-user secret=ANOTHER ; --snip-- The other server (MTV2) is configured: [STL-peer] username=MTV2-user fromuser=MTV2-user secret=ANOTHER ; --snip-- [STL-user] username=MTV2-user fromuser=MTV2-user secret=ANOTHER The long and short of it is, other than MTV vs MTV2 and the passwords, MTV and MTV2 were configured identically. MTV could send and receive calls from STL, but not MTV2. Every call attempt would result in a FORBIDDEN response, with no verbose output on the STL server's CLI at verbose 5, and just a FORBIDDEN response notification on MTV2's CLI at verbose 5. I'm attaching packet captures from "bad call attempts" between MTV2 and STL, in an effort to help further. Please let me know if I can do more to assist.
Comments:	By: Sherwood McGowan (rushowr) 2011-03-16 18:01:51 Is there a reason this has not been even viewed by anyone yet? Did I miss something in my search? By: Sherwood McGowan (rushowr) 2011-03-16 18:03:17 Additionally, I wanted to change the asterisk version to 1.6.2.19 (latest version I've recently tested and confirmed on) but cannot. By: David Woolley (davidw) 2011-03-17 06:57:52 You've not complied with the bug reporting guidelines, which require verbose and debug output from Asterisk, for sip set debug and sip history. pcap doesn't include information on what Asterisk thought it was doing. Also, the bug reporting system is not a place for fast support. By: Sherwood McGowan (rushowr) 2011-03-17 07:29:21 Davidw, I apologize if you thought I was asking for support. I'm not. I've reported my fair share of bugs to this tracker before, however it's been a while and I forgot about having to give you all the info instead of just providing enough information to reliably reproduce the reported issue. "fast" is also not what I was expecting, this issue has been around as long as I can remember with Asterisk....since at least 2005, I can tell you that. However, I was expressing my surprise that nobody had even taken a look at the bug yet. Give me a bit, I'll go set up a test system and reproduce the error and send you a nice long document or two with debug output. By: Sherwood McGowan (rushowr) 2011-03-17 07:49:00 I just realized, the reason you received no log output is that there was none. As stated in my bug report, even at level 5, there was no information on the console or in my full log (which logs ALL levels other than DTMF during testing in my shop). However, I'm putting everything back together for you so that I can provide you with sip history and sip debug, but I believe you're going to see the same output as the capture files, since the sip debug is just a console output of the sip packets asterisk is working with.... more in a few By: Leif Madsen (lmadsen) 2011-03-31 13:02:56 I've configured many systems to speak each other over SIP. This seems like a configuration issue to me. I don't see anywhere where you specify a hostname, which would be required to place a call to another peer. Is that your exact configuration? If so, I would not expect it to work. By: Sherwood McGowan (rushowr) 2011-04-15 18:27:30 Hey Leif! I've encountered it on many systems over the years, but I haven't had the time to jump in and recreate this. However, I'll have time soon. Oh, and no, that wasn't the exact configuration that was in use. Nor has this been isolated to Asterisk<->Asterisk communications, I've seen it happen with all sorts of endpoints. I'll follow up while I test my latest PBX installation. I was unable previously to revert to the "problem" version of configuration (I ended up changing the names so that they didn't come close in name) due to the system being brought into production. The new system I'm on will have about a week's testing so I will have more time to fiddle with it. By: Leif Madsen (lmadsen) 2011-05-10 14:45:27 Suspending this issue until the reporter has additional information. At a minimum I'd like to see the Asterisk console output and SIP debug information from the Asterisk systems in question. I believe this to be a configuration issue. You shouldn't be specifying the username= like you are because that could cause the parser to get confused on what to match. You should really be just using fromuser= to change the outbound calls to the other system so the remote end knows what peer to match on. The username= (nay, defaultuser= as username= is deprecated) should really be the same as what is in [peername].