Looking for extension in the first context only (Incoming)

Asterisk Asterisk Support
1

Hello,

Asterisk version: 11.10
Operating System: Ubuntu 12.04 Server (64-Bit)

I think that this is a new issue. I have done lot of research on Internet and did not find any similar post.

Scenario: I am using bandwidth.com as our provider. I configured my Asterisk server with “sales” and “support” contexts and each with one extension and one DID number respectively. I am able to make outgoing calls successfully.

Problem: I am able to received incoming call on my first configured DID number with “sales” context. When I received incoming call on my second configured DID number, unable to receive incoming call and it is searching and looking for that second DID number in the first configured context only. As my second DID number is configured with “support” context, it is giving the below message.

CLI Message: chan_sip.c:25632 handle_request_invite: Call from ‘bandwidth123’ (67.231.8.195:5060) to extension ‘+14565556666’ rejected because extension not found in context ‘sales’.

sip show peers output:
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
1001/1001 111.93.55.36 D Yes Yes 24278 OK (284 ms)
1002/1002 111.93.55.36 D Yes Yes 58913 OK (296 ms)
bandwidth123 67.231.8.195 Yes Yes 5060 OK (90 ms)
bandwidth456 67.231.8.195 Yes Yes 5060 OK (90 ms)
4 sip peers [Monitored: 4 online, 0 offline Unmonitored: 0 online, 0 offline]

Note: If I configure extensions and Two DID numbers with one context only, all are working fine.

Please find my below simple configuration:

sip.conf:

[general]
nat=force_rport,comedia
localnet=172.31.15.19/255.255.240.0
externip=54.186.135.99
bindaddr=0.0.0.0
bindport=5060
disallow=all
allow=gsm
allow=ilbc
allow=ulaw
allow=alaw
allow=h264
allow=g723
rtcachefriends=yes
qualify=3000
rtsavesysname=yes
rtupdate=yes
ignoreregexpire=yes
allowguest=no
dtmfmode=rfc2833

[1001]
callerid=“Sales” <1001>
context=sales
dtmfmode=rfc2833
host=dynamic
insecure=port,invite
nat=force_rport,comedia
secret=password
type=friend
disallow=all
allow=all
defaultuser=1001
directmedia=no
qualify=300
canreinvite=no

[1002]
callerid=“Support” <1002>
context=support
dtmfmode=rfc2833
host=dynamic
insecure=port,invite
nat=force_rport,comedia
secret=password
type=friend
disallow=all
allow=all
defaultuser=1002
directmedia=no
qualify=300
canreinvite=no

[bandwidth123]
context=sales
dtmfmode=rfc2833
fromdomain=67.231.8.195
host=67.231.8.195
nat=force_rport,comedia
type=peer
disallow=all
allow=all
directmedia=no
outboundproxy=67.231.8.195
qualify=300
canreinvite=no

[bandwidth456]
context=support
dtmfmode=rfc2833
fromdomain=67.231.8.195
host=67.231.8.195
nat=force_rport,comedia
type=peer
disallow=all
allow=all
directmedia=no
outboundproxy=67.231.8.195
qualify=300
canreinvite=no

extensions.conf:

[general]
static=yes
writeprotect=no

[sales]
exten => 1001,1,Answer()
exten => 1001,n,Dial(SIP/1001,20)
exten => 1001,n,Hangup

include => sales-outgoing
include => sales-incoming

[support]
exten => 1002,1,Answer()
exten => 1002,n,Dial(SIP/1002,20)
exten => 1002,n,Hangup

include => support-outgoing
include => support-incoming

[sales-outgoing]
exten => _1X.,1,Set(CALLERID(all)=“Sales Company” <(123) 111 3333>)
exten => _1X.,2,Dial(SIP/${EXTEN:1}@bandwidth123)
exten => _1X.,3,Hangup()

[support-outgoing]
exten => _1X.,1,Set(CALLERID(all)=“Support Company” <(456) 555 6666>)
exten => _1X.,2,Dial(SIP/${EXTEN:1}@bandwidth456)
exten => _1X.,3,Hangup()

[sales-incoming]
exten => +11231113333,1,Answer
exten => +11231113333,2,Dial(SIP/1001,20)
exten => +11231113333,3,Hangup()

[support-incoming]
exten => +14565556666,1,Answer
exten => +14565556666,2,Dial(SIP/1002,20)
exten => +14565556666,3,Hangup()

SIP Debug INVITE Message:

<— SIP read from UDP:54.186.135.99:5060 —>
INVITE sip:+14565556666@54.186.135.99:5060 SIP/2.0
Record-Route: sip:67.231.8.195;lr=on;ftag=gK0536b878
Record-Route: sip:67.231.4.93;lr=on;ftag=gK0536b878
Accept: application/sdp
Allow: INVITE,ACK,CANCEL,BYE
Via: SIP/2.0/UDP 67.231.8.195;branch=z9hG4bK9caf.2a3b4d45.0
Via: SIP/2.0/UDP 67.231.4.93;branch=z9hG4bK9caf.34acad9.0
Via: SIP/2.0/UDP 192.168.27.76:5060;branch=z9hG4bK05Bb147119f79217b05
From: “ANDREW, W” sip:+19186666523@192.168.27.76;tag=gK0536b878
To: sip:+14565556666@67.231.4.93
Call-ID: 285589908_101336519@192.168.27.76
CSeq: 2914 INVITE
Max-Forwards: 97
Contact: “ANDREW, W” sip:+19186666523@192.168.27.76:5060
Content-Length: 328
Content-Disposition: session; handling=required
Content-Type: application/sdp
Remote-Party-ID: “ANDREW, W” sip:+19186666523@192.168.27.76:5060;privacy=off;screen=no

Where I am doing the mistake? Any help would be appreciated.

Thank you.

Regards,
Mouli.

2

Expected behaviour. Both peers have the same IP address and same port number. Although you have specified them as “friend”, they will not be sending the username information on the invite, so they will not match as users, only as peers. (In fact specifying them as friends makes you vulnerable to people masquerading as the ITSP, as you have insecure=invite (even if you use remotesecret, instead, you will still have the same vulnerability).

In fact, as sales seems to have toll calling capability, you currently have a perfect setup for a hacker. PSTN “lines” should never be in contexts with toll call capability, even if you do secure them by using peer, rather than friend.

As you have already discovered, you must use the same context for both and resolve the two based on the user field in the request URI.

3

You’ve also got insecure=port, so, in the unlikely event that different port numbers were used for the two registrations, you are telling asterisk to ignore the port number. (Actually it may well match on IP only an then reject the one with the wrong port number, if that were really the case, and you hadn’t disable port number checking.)

nat=force_rport is also inconsistent with matching on port number.

Generally, it looks as though you have most the security reducing hacks that people use to produce configurations that work without thought.

4

Hello David,

Thanks for your reply and sorry for the delay in giving reply.

  1. Regarding security, I will take care :smile: .
  2. Regarding toll numbers, I will take care :smile: .
  3. As you also noticed, DID numbers are registering with 5060 port only at this moment. If I ask my provider to register the DID numbers with random port numbers, does this work for my scenario? What is your opinion about this?
  4. I noticed that If I put all the DID numbers in same context also, incoming call is coming through first registered DID number trunk only. What is your opinion about this?

I look forward to hearing from you.

Thank you.

Regards,
Mouli

5

I don’t know if Asterisk will match against the port number in selecting a peer, if you turn off insecure=port, but it is unlikely that your ITSP will offers that service.

Really the simplest way of doing this is the normal way in which you have a context for external callers which you then route based on the extension.