[asterisk-dev] SIP Peer matching on Inbound calls (and a feature request, please)

[Daniel Corbe]

Dear Asterisk Community,

I'm having a strage problem related to the way Asterisk is matching
SIP peers on inbound calls to DIDs (not REGISTERed extensions).  I
believe I am 100% correct in my assessment of why my calls are failing
(as explained below).  I've tried to get help resolving this issue
through the use of Asterisk consultants and paid support through
Digium; however, the suggested work-arounds are impractical IMHO.

I would simply like to crawl into the source code and see if I can fix
the issue myself.  I've posed this to the dev mailing list because I'm
looking for a little bit of guidance as to where I need to start.  If
someone can point me in the right direction, I can start hacking away
and testing this weekend and hopefully have a publically available
patch by monday.

I have several DIDs routed to my asterisk box, and when I call one of
these DIDs Asterisk is spitting out 404s at me.  When I have SIP
Debugging turned on, I see the call fail and I know why its failing:

<-- SIP read from 64.49.129.5:5061:
INVITE sip:441612412070 at 12.109.47.235:5060 SIP/2.0
Via: SIP/2.0/UDP
64.49.129.5:5061;branch=z9hG4bK961d25b39e3acb6b937d9bce549c4d33;rport
Max-Forwards: 70
From: <sip:None at 64.49.129.5>;tag=9a658fc7987c766e4421588ccab07729
To: <sip:441612412070 at 12.109.47.235>
Call-ID: 475-3372178825-287887 at lhr1.interceltelecoms.net
CSeq: 200 INVITE
Contact: Anonymous <sip:64.49.129.5:5061>
Expires: 300
User-Agent: Sippy
cisco-GUID: 1980681325-1990509986-3435710513-2096734923
323-conf-id: 1980681325-1990509986-3435710513-2096734923
Content-Length: 284
Content-Type: application/sdp

v=0
o=Sippy 346584172 0 IN IP4 64.49.129.5
s=sip call
t=0 0
m=audio 59052 RTP/AVP 18 8 0 101 19
c=IN IP4 64.49.129.5
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000

--- (14 headers 13 lines) ---
Using INVITE request as basis request -
475-3372178825-287887 at lhr1.interceltelecoms.net
Sending to 64.49.129.5 : 5061 (NAT)
Found peer '2668-outbound'
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 101
Found RTP audio format 19
Peer audio RTP is at port 64.49.129.5:59052
Found description format G729
Found description format PCMA
Found description format PCMU
Found description format telephone-event
Found description format CN
Capabilities: us - 0x50e (gsm|ulaw|alaw|g729|ilbc), peer - audio=0x10c
(ulaw|alaw|g729)/video=0x0 (nothing), combined - 0x10c
(ulaw|alaw|g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x3
(telephone-event|CN), combined - 0x1 (telephone-event)
Looking for 441612412070 in 2668-outbound (domain 12.109.47.235)
Reliably Transmitting (NAT) to 64.49.129.5:5061:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP
64.49.129.5:5061;branch=z9hG4bK961d25b39e3acb6b937d9bce549c4d33;received=64.49.129.5;rport=5061
From: <sip:None at 64.49.129.5>;tag=9a658fc7987c766e4421588ccab07729
To: <sip:441612412070 at 12.109.47.235>;tag=as60019cdc
Call-ID: 475-3372178825-287887 at lhr1.interceltelecoms.net
CSeq: 200 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Clearly, Asterisk is matching the wrong peer here.
""Found peer '2668-outbound'""

Here's the two peers in question:
[2668-outbound]
port=5060
username=2668-outbound
type=peer
cancallforward=no
disallow=all
context=2668-outbound
secret=sheot1in
host=64.49.129.5
allow=g729
allow=ilbc
allow=gsm
allow=ulaw
allow=alaw
nat=yes
callerid=08454658647
canreinvite=yes
insecure=invite

[441612412070]
port=5061
username=441612412070
type=friend
cancallforward=no
disallow=all
context=2668
host=64.49.129.5
allow=g729
allow=ilbc
allow=gsm
allow=ulaw
allow=alaw
nat=no
insecure=invite
id=1
canreinvite=yes

Digium's paid support is telling me that the only matching criteria is
either registered peers (and since this is a DID, there are none) or
the HOST to which the traffic is coming from.

I would like to see a 3rd match criteria here, and that is for
unregistered peers (as in the case of a DID) the Username in the To:
header needs to be matchable to a SIP peer.

The reason I want to do this, is because of my Dialplan I have the
DIDs forwarded to extensions (using Goto, basically) like so:

[2668]
441612412071,1,Goto(2668-outbound,2071,1)
441612412074,1,Goto(2668-outbound,2074,1)
441612412075,1,Goto(2668-outbound,2075,1)
441612412070,1,Goto(2668-outbound,2070,1)
441612412072,1,Goto(2668-outbound,2072,1)
441612412073,1,Goto(2668-outbound,2073,1)

If you notice (go back and look at the SIP Peers), the proper peer for
the 44*2070 DID, the context is set to 2668, so that I would expect
the call to be dumped into the right place in my dial plan.

Since its matching the wrong peer, its dumping the call into the wrong context.

Having this feature would save me from having to route all inbound DID
calls to the default context.  It saves room in my dialplan (so that
inbound calls don't need to be GOTO'd twice).  It also saves me some
headaches down the road as we are currently using Asterisk Real-Time,
we've layered a WMI on top of it that interacts with certain portions
of our Dialplan.  We're using it to route DIDs directly to extensions,
and the context is used to identify which DIDs belong to which
customers.

Regards,
Daniel