[Home]

Summary:ASTERISK-14978: [patch] Peer mismatch in incomming call
Reporter:Daniel A. Veiga (dveiga)Labels:
Date Opened:2009-10-12 18:08:11Date Closed:2010-03-15 10:32:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c.diff
( 1) sip-debug.rtf
Description:    I'm using the latest 1.4 svn version as a voip gateway connected to a PBX. As such I have as many DAHDI channels as SIP peers and link them on a one to one basis. When commertial gateways (say Grandstream 4024) register to a PBX, they use different local SIP ports for each channel. In this way, when the PBX places a SIP invite to offer a call using a certain port, ther is no doubt which SIP peer the call is for.
   Asterisk cannot use different ports, so upon receiving an invite, it has to determine which peer it is for. The default behaviour is to determine the peer based on the IP address (after trying to find a user, that is not applicable here), but when there are multiple subscriptions to the same IP this is not enough.
   The current patch analyzes the sip headers to determine the peer name and then finds the peer based on both: IP an NAME. For compatibility reasons, if a peer matching both is not found, it falls back to the previous method (finding one just using the IP address).
Comments:By: Elazar Broad (ebroad) 2009-10-14 12:22:21

Correct me if I am wrong:

;sip.conf
[100]
host=foo
callerid=100

[101]
host=foo
callerid=101

[102]
host=bar

If 102 places a call to 101 or 100, does the call complete? if so, does it come in on the right line?

Note: I had a (possibly) similar issue with some Cisco 7940's on a local network segment, where line 1 would use port 5060 on the phone and line 2 would use some random high port. This would cause registrations for line 2 to fail because Asterisk would challenge or ACK the registration request on port 5060. Enabling NAT support on the phone forced it to use 5060 for both lines, resolving the issue.


By: Daniel A. Veiga (dveiga) 2009-10-14 14:42:04

My config is quite different. Remember Asterisk is acting as a gateway, connected to a PBX using 24 SIP accounts (all on the same server) and having 24 DAHDI ports. The config is as follows:

sip.conf

register => 201:Password1@PBX'sIP/201
register => 202:Password2@PBX'sIP/202
....
register => 224:Password24@PBX'sIP/224

[201]
type=peer
username=201
fromuser=201
fromdomain=PBX'sIP
secret=Password1
host=PBX'sIP
context=from-pbx
[202]
type=peer
username=202
fromuser=202
fromdomain=PBX'sIP
secret=Password2
host=PBX'sIP
context=from-pbx
...
[224]
type=peer
username=224
fromuser=224
fromdomain=PBX'sIP
secret=Password24
host=PBX'sIP
context=from-pbx

The first lines registers Asterisk against the PBX. In fact, Asterisk registers all 24 lines sending SIP packets to PBX'sIP:5060. But as Asterisk is unable to send registrations FROM different ports, instead of having the following scenario (tipical of commertial gateways):

PBX'sIP:5060 <--------------- 201 ------------> Asterisk'sIP:5060
PBX'sIP:5060 <--------------- 202 ------------> Asterisk'sIP:5061
...
PBX'sIP:5060 <--------------- 224 ------------> Asterisk'sIP:5083

we get the following:

PBX'sIP:5060 <--------------- 201 ------------> Asterisk'sIP:5060
PBX'sIP:5060 <--------------- 202 ------------> Asterisk'sIP:5060
...
PBX'sIP:5060 <--------------- 224 ------------> Asterisk'sIP:5060

   The problem arrises when there is an incomming call. Imagine there is a call for extension 202. The PBX contacts Asterisk'sIP:5060, because it's the address that 202 has registred from. But when the packet get's into Asterisk's SIP stack, the first thing to do is identify the peer and authenticate the packet. The peer is determined using ONLY the source IP and port (in this case PBX'sIP:5060). Of course 24 peers match the criteria, and because of the actual implementation, the last is returned (224). As a result, the packet sent using 202/Password2 gets rejected when validated using 224/Password24.

   I solved the problem using the SIP header info to determine which of the 24 peers matching the criteria should be returned.

   Bye,

                                             Daniel
By: Elazar Broad (ebroad) 2009-10-14 15:01:05

You could also add insecure=invite to your peer definitions, if authenticating your peer invite(s) is optional. With that said, we should be matching our challenges against the appropriate extension/user. Can you please provide a sip debug without the workaround that your specified in your last note? Thanks!
By: Daniel A. Veiga (dveiga) 2009-10-14 15:55:58

Sory I have to change the initial scenario, but I have to move off production environment. My new PBX has IP 172.16.3.16, and has 4 sip accounts numbered 991-994. The first one is a standalone phone, the other 3 are SIP accounts of my new gateway. This gateway has 3 DAHDI ports linked on a one to one basis to the 3 sip accounts using the dialplan. It has IP 172.16.5.117.

Config is as follows:

sip.conf

register => 992:Password1@172.16.3.16/992
register => 993:Password2@172.16.3.16/993
register => 994:Password3@172.16.3.16/994

[992]
type=peer
username=992
fromuser=992
fromdomain=172.16.3.16
secret=Password1
host=172.16.3.16
context=from-pbx
insecure=very

[993]
type=peer
username=993
fromuser=993
fromdomain=172.16.3.16
secret=Password2
host=172.16.3.16
context=from-pbx
insecure=very

[994]
type=peer
username=994
fromuser=994
fromdomain=172.16.3.16
secret=Password3
host=172.16.3.16
context=from-pbx
insecure=very


I'm uploading a RTF file named sip-debug.rtf with a screen capture of the console under the following circumstances:

1) Removed my patch
2) Added insecure=very (as can be seen above)
3) Executed "sip set debug peer 992"
4) Called from 991 (outside the gateway) to extension 992 (in the gateway)

I highlighed in red two lines: The first one reflects the incorrect assumption on the peer (It says 'Found peer 994', when the call only involves 991 and 992). The second the result of 'core show channels' when the phone is ringing, that shows the channel was created assuming an incomming call from peer 994.

Bye,


                                Daniel
By: Leif Madsen (lmadsen) 2010-03-03 09:12:57.000-0600

Do you have any opinions on this issue?
By: Russell Bryant (russell) 2010-03-15 10:32:24

Thank you for your contribution.  However, this change can not be accepted.  This is a problem that people have solved via different configuration methods.  There has also been much vigorous architectural discussion on the best way to improve matching in chan_sip.  Regardless of what is done, it can _not_ be done as changes in behavior to the existing matching behavior of type=user and type=peer.    If you're interested in joining the discussion on the design of future matching methods, I would encourage you to join the asterisk-dev list, and look up previous discussions that have occurred in the list archives.