[asterisk-bugs] [Asterisk 0016061]: [patch] Peer mismatch in incomming call [PATCH]

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16061 
====================================================================== 
Reported By:                dveiga
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16061
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 223801 
Request Review:              
====================================================================== 
Date Submitted:             2009-10-12 18:08 CDT
Last Modified:              2009-10-14 14:42 CDT
====================================================================== 
Summary:                    [patch] Peer mismatch in incomming call [PATCH]
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).
====================================================================== 

---------------------------------------------------------------------- 
 (0112291) dveiga (reporter) - 2009-10-14 14:42
 https://issues.asterisk.org/view.php?id=16061#c112291 
---------------------------------------------------------------------- 
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 at PBX'sIP/201
register => 202:Password2 at PBX'sIP/202
....
register => 224:Password24 at 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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-14 14:42 dveiga         Note Added: 0112291                          
======================================================================