Summary:	ASTERISK-05041: [request] [post 1.2] Mismatch peers with same IP
Reporter:	hypherion (hypherion)	Labels:
Date Opened:	2005-09-10 00:38:06	Date Closed:	2010-07-26 15:53:08
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) peerconfuse.txt ( 1) peers_sip_conf.txt
Description:	When there is more than one peer with the same IP address and port, Asterisk uses the credentials from the last one defined in sip.conf to authenticate.  Also, as a minor issue, 'sip debug peer' in this case is irrelevant as debug info for ALL of these peers with the same IP is displayed. ****** ADDITIONAL INFORMATION ****** My test case has two peers defined in sip.conf with the same provider, hence both have the same IP and port (two different accounts, account1 and account2 with same provider).  The order they are listed in sip.conf is [account1] then [account2].   Two things are wrong: When a call comes in through account1, everything works as expected except Asterisk reports in sip debug: Found peer 'account2' Consequently, the console shows the channel name as SIP/account2-5202 Additionally, when I hang up from the client side, and the provider sends a 407 in response to BYE, Asterisk uses the username account2 in the Digest instead of  account1. The result is: Sep  9 21:57:59 NOTICE[19116]: chan_sip.c:9478 handle_response:  Failed to authenticate on BYE to '<sip:caller@Provider_IP>;tag=781947608' ... and the provider does not hang up the caller. I have found that if I add account3, account4 and so on to sip.conf, it's always the last one defined that is used for all communications.  However, the correct context is used and the proper number passed to extensions.conf. Each peer is defined like so: [account1] type=peer secret=mypass username=account1 host=ProviderHost port=5061 dtmfmode=rfc2833 fromuser=account1 fromdomain=ProviderHost canreinvite=yes context=incoming insecure=very defaultexpirey=120 allow=all The attached SIP debug uses Vonage (yes, again!) as the provider, ACCOUNT1 defined under peer [vonage_in] and ACCOUNT2 under peer [vonage7].  Note how Asterisk (1) incorrectly identifies peer vonage7 and (2) uses its credentials for authenticating, even though the To and From refer to ACCOUNT1.
Comments:	By: hypherion (hypherion) 2005-09-10 00:42:55 Added the peer definitions from sip.conf for the two Vonage accounts. By: Brian West (bkw918) 2005-09-10 00:59:01 I honestly don't think this can work without some major work in chan_sip. /b By: Michael Jerris (mikej) 2005-09-10 01:51:10 search the bugtracker for broadvoice.. By: hypherion (hypherion) 2005-09-10 02:50:42 The issues reported with Broadvoice seem to circle more around the fact that peers cannot be identified for CDR and billing or routing purposes.   In this case, the SIP dialog is never properly terminated.  AFAIK, requiring authentication for a BYE is allowed for in the RFC and Asterisk should send the correct credentials if if has them. By: Olle Johansson (oej) 2005-09-10 07:17:18 If you use peer matching by IP we will always match the first one in memory, which is the last one in SIP.conf. By: Olle Johansson (oej) 2005-09-10 10:21:09 Thinking about it this requires some major work, as bkw said. I don't know if we have time or want to rework this part for 1.2. This feature has been unsupported by asterisk for a long time and we don't want to add new features late. I've been playing around with different quick-and-dirty solutions, but came up with no satisfying solution within the current code. We propably have to add the extension we register in the register= to a peer and match on that extension with the peer and the current macros do not allow that... If we had this report a month ago :-) By: Michael Jerris (mikej) 2005-09-10 15:49:06 As stated in ASTERISK-4053 we need a more general solution for auth on all kinds of messages.  This would be gladly accepted, although I beleive all major reworks will need to be post 1.2.  I am going to mark this as a post 1.2 feature request. By: Olle Johansson (oej) 2005-09-10 16:02:59 Mike, this is not really about authentication, but about the matching of the registry and the peer listing, avoiding the IP-based matching for something more intelligent. I had a patch a while ago that enabled registration within the [peer] entry that is the proper way to go for a solution to this. Still playing around trying to find a quick way to solve this in 1.2 without a lot of damage to the source. It is a bug. Not promising anything though. By: Olle Johansson (oej) 2005-11-17 13:20:33.000-0600 Olle: Still playing around? :-) By: Luigi Rizzo (rizzo) 2005-11-18 19:31:35.000-0600 interesting, this seems related to a question I just asked privately to oej. In my case, it was the difference between        dial SIP/100@my.provider.com and     dial SIP/100@foo    where [foo] is a peer pointing to my.provider.com but it is the same problem that exists with multiple peers from the same IP address. I wonder if this is supported by the SIP spec in the first place... if so, we can probably find hints for an interoperable solution there (interoperable is the key, because finding some trick that only works between asterisk nodes would be trivial). Basically, i guess that if we can put some field in the SIP message to tell one case from the other, then the problem can be solved. By: Tilghman Lesher (tilghman) 2005-12-27 00:26:24.000-0600 Just wondering, since it's not mentioned anywhere, but does setting pedantic=yes (or nat=yes) make a difference?  We do more strict checking according the SIP spec with the pedantic flag on. By: Olle Johansson (oej) 2006-01-09 14:04:33.000-0600 Working on this issue in the sipregister branch. By: Olle Johansson (oej) 2006-01-26 13:00:20.000-0600 Closing this issue since it is a feature request, not really an open bug report. I have a plan on how to change matching on incoming calls for outbound registrations, which is part of chan_sip3. Changing matching in chan_sip1 would require significant changes that will be done in chan_sip3 :-)