[asterisk-bugs] [Asterisk 0014250]: [patch] Incoming calls matched to the wrong peer

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14250 
====================================================================== 
Reported By:                Nick_Lewis
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   14250
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-15 05:58 CST
Last Modified:              2009-01-28 05:30 CST
====================================================================== 
Summary:                    [patch] Incoming calls matched to the wrong peer
Description: 
If there are multiple sip trunks with the same ITSP then an incoming call
is arbitarily matched to the last peer with the same host IP address. This
is not a serious problem because the DID is still correct but it does have
many insidious effects due to the incorrect channel name
====================================================================== 

---------------------------------------------------------------------- 
 (0098947) Nick_Lewis (reporter) - 2009-01-28 05:30
 http://bugs.digium.com/view.php?id=14250#c98947 
---------------------------------------------------------------------- 
I am glad that now is the time to make a good design for sip trunks

Re "No problem with that" I do have some niggles
(i) In an INVITE from a UAS the request URI represents the sip termination
point. Asterisk is currently getting the wrong one. Remedial action outside
sip does not mend sip behaviour
(ii) In an INVITE from a UAS the request URI does not contain an Address
of Record so it should not be used to route a call in the dialplan. Any
routing of trunk calls in the dialplan should be based only on the context
of the sip termination point.

RFC3261 shows the difference between UAC and UAS invites in the examples:
INVITE sip:bob at biloxi.com SIP/2.0 (an Address of Record from UAC to UAS)
INVITE sip:bob at 192.0.2.4 SIP/2.0  (a Contact from UAS to UAC)
and perhaps it would have been even clearer as 
INVITE sip:robertgeldof at biloxi.com SIP/2.0
INVITE sip:bob at 192.0.2.4 SIP/2.0

It is possible to regard the way a UAS Registrar translates AOR to Contact
as similar to the way the dialplan translates Exten to
Dial(res_tech/res_name). The Contact is a more physical resource like
res_name whereas the AOR is signalling like Exten

Anyway I have wittered on too much. I will await the new design 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-28 05:30 Nick_Lewis     Note Added: 0098947                          
======================================================================