How to get inbound calls to go to the right context?
Seems to be being directed to "from-sip-external" context
instead of "from-trunk"
-- Executing [6013094718@from-sip-external:1] NoOp("SIP/211.168.1.101-b7724708", "Received incoming SIP connection from unknown peer to 6013094718") in new stack
-- Executing [6013094718@from-sip-external:2] Set("SIP/211.168.1.101-b7724708", "DID=6013094718") in new stack
-- Executing [6013094718@from-sip-external:3] Goto("SIP/211.168.1.101-b7724708", "s|1") in new stack
-- Goto (from-sip-external,s,1)
-- Executing [s@from-sip-external:1] GotoIf("SIP/211.168.1.101-b7724708", "0?from-trunk|6013094718|1") in new stack
-- Executing [s@from-sip-external:2] Set("SIP/211.168.1.101-b7724708", "TIMEOUT(absolute)=15") in new stack
-- Channel will hangup at 2008-08-04 18:16:53 UTC.
-- Executing [s@from-sip-external:3] Answer("SIP/211.168.1.101-b7724708", "") in new stack
-- Executing [s@from-sip-external:4] Wait("SIP/211.168.1.101-b7724708", "2") in new stack
-- Executing [s@from-sip-external:5] Playback("SIP/211.168.1.101-b7724708", "ss-noservice") in new stack
--
-- Executing [s@from-sip-external:6] PlayTones("SIP/211.168.1.101-b7724708", "congestion") in new stack
-- Executing [s@from-sip-external:7] Congestion("SIP/211.168.1.101-b7724708", "5") in new stack
I see various references on the Web about putting "context = from-trunk"
in sip.conf. I have done so:
;========================================================
; If you need to answer unauthenticated calls, you should change this
; next line to 'from-trunk', rather than 'from-sip-external'.
; You'll know this is happening if when you call in you get a message
; saying "The number you have dialed is not in service. Please check the
; number and try again."
;context = from-sip-external ; Send unknown SIP callers to this context
; OK, let's change it. 2008 Aug 3:
context = from-trunk
;========================================================
Still doesn't seem to go to the right place.
Does anyone have some hints on how I might get this
to work?
Hey Joseph!
Thanks a bunch for the quick response!
I diddled around with the trunk in the GUI. My
"sip_additional.conf" now has these entries:
[Cisco-Inbound]
host=211.168.1.101
username=***userid***
secret=***password***
type=peer
context=from-trunk
[from-trunk]
secret=***password***
type=user
context=from-trunk
Am still getting the "ss-noservice" no service
announcement.
Where else can I put the "from-trunk" context,
or did I put it in the wrong place?
I navigate as follows:
PBX -> PBX Settings -> Trunks -> Trunk SIP/Cisco-Inbou
http://www.us-webmasters.com/Trunks-Context.gif
Am I at the right place?
Yep, a Cisco 3640.
Currently it is working fine with a different Asterisk box.
As you can see above, it is sending inbound calls to this
new TrixBox, but it just seems to deadend.
Somehow it goes from the "from-sip-external" context into
a "ss-noservice" recording. TrixBox doesn't seem
to be routing it to the DID inbound route.
How to get that to happen?
Please post the relevant Cisco PEER details and a SIP debug from Asterisk.
When using the SIP debug turn off console debug with the command 'set verbose 0' then turn on sip debugging with 'sip debug ip {peer IP address}' make sure to turn it off when you are done with 'sip no debug'
> Please post the relevant Cisco PEER details
Is this what you mean?
http://www.us-webmasters.com/Trunks-Context.gif
>and a SIP debug from Asterisk.
OK, even used the new commands:
core set verbose 0
sip set debug ip 211.168.1.101
What are we looking for exactly?
LarryPBX*CLI> sip set debug ip 211.168.1.101
SIP Debugging Enabled for IP: 211.168.1.101
LarryPBX*CLI>
LarryPBX*CLI>
LarryPBX*CLI>
LarryPBX*CLI>
<--- SIP read from 211.168.1.101:58618 --->
INVITE sip:6013094718@181.212.22.165:5060 SIP/2.0
Via: SIP/2.0/UDP 211.168.1.101:5060
From:
To:
Date: Tue, 12 Aug 2008 03:34:24 GMT
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
Supported: timer,100rel
Min-SE: 1800
Cisco-Guid: 1689137624-1733693917-2384960989-2697790297
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 1218512064
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 400
v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 5809 IN IP4 211.168.1.101
s=SIP Call
c=IN IP4 211.168.1.101
t=0 0
m=audio 18006 RTP/AVP 98 99 18 2 3 0 101
c=IN IP4 211.168.1.101
a=rtpmap:98 G726-24/8000
a=rtpmap:99 G726-16/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:2 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
<------------->
--- (19 headers 16 lines) ---
Sending to 211.168.1.101 : 58618 (NAT)
Using INVITE request as basis request - 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
Found no matching peer or user for '211.168.1.101:58618'
Found RTP audio format 98
Found RTP audio format 99
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 101
Peer audio RTP is at port 211.168.1.101:18006
Found unknown media description format G726-24 for ID 98
Found unknown media description format G726-16 for ID 99
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format GSM for ID 3
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x906 (gsm|ulaw|g726|g729)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 211.168.1.101:18006
Looking for 6013094718 in from-sip-external (domain 181.212.22.165)
list_route: hop:
LarryPBX*CLI>
<--- Transmitting (NAT) to 211.168.1.101:58618 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 211.168.1.101:5060;received=211.168.1.101
From:
To:
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0
<------------>
Audio is at 181.212.22.165 port 12410
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
LarryPBX*CLI>
<--- Reliably Transmitting (NAT) to 211.168.1.101:58618 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 211.168.1.101:5060;received=211.168.1.101
From:
To:
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Type: application/sdp
Content-Length: 242
v=0
o=root 3403 3403 IN IP4 181.212.22.165
s=session
c=IN IP4 181.212.22.165
t=0 0
m=audio 12410 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
LarryPBX*CLI>
<--- SIP read from 211.168.1.101:1287 --->
ACK sip:6013094718@181.212.22.165:5060 SIP/2.0
Via: SIP/2.0/UDP 211.168.1.101:1287
From:
To:
Date: Tue, 12 Aug 2008 03:34:24 GMT
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
<------------->
--- (9 headers 0 lines) ---
LarryPBX*CLI>
<--- SIP read from 211.168.1.101:1288 --->
BYE sip:6013094718@181.212.22.165:5060 SIP/2.0
Via: SIP/2.0/UDP 211.168.1.101:1288
From:
To:
Date: Tue, 12 Aug 2008 03:34:24 GMT
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 1218512072
CSeq: 102 BYE
Content-Length: 0
<------------->
--- (11 headers 0 lines) ---
Sending to 211.168.1.101 : 1288 (NAT)
LarryPBX*CLI>
<--- Transmitting (NAT) to 211.168.1.101:1288 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 211.168.1.101:1288;received=211.168.1.101
From:
To:
Call-ID: 64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101
CSeq: 102 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0
<------------>
Really destroying SIP dialog '64B006E8-675611DD-8E2A9DDD-A0CD0359@211.168.1.101' Method: BYE
LarryPBX*CLI>
As strange as it may seem the solution to this problem was the
following:
PBX -> PBX Settings -> Inbound Routes > Click on the Route In Question ->
Under "Edit Incoming Route" there are 3 fields:
Description: Main-Inbound-Number
DID Number: 6013094718
Caller ID Number: DO NOT PUT THE PHONE NUMBER HERE!!!!!!!!!!!!!!!!!
As bizarre as this might sound, do NOT put the phone number
in the "Caller ID Number" field!
By deleting this entry, the inbound calls were directed to the
proper context and the IVR.
This should be documented better since it is unclear that this
will foul things up if you put the DID number here.
Define the Caller ID number to be matched on incoming calls
Is that unclear in any way? Any underlined field can be hovered over for a hint, more information is available by clicking the "Help" tab which brings up context sensitive help for the page you are on.
The label on the field simply says:
Caller ID
What the current popup says:
================================
Define the Caller ID number to be matched on
incoming calls
Leave this field blank to match any or no CID info.
=================================
This give no reason why one would want to match
the Caller ID.
Perhaps a better, safer popup would be something
like:
=================================
Do NOT put any information here unless you want
to filter incoming calls by Caller ID.
If you do wish to perform a different action for a
particular Caller ID, then put that number here.
=================================
Do you work for the same folks that put the "do not use in bathtub" label on hair dryers?
If there was a disclaimer on every permutation of every possible configuration the code would never get updated.
To help us understand perhaps you would tell us what you thought the field was for and why you populated it? A route, in a phone system or a router either matches and executes or passes to the next route. That is what the little arrows are for so you can put the routes in order. Each route is evaluated based on the digit patterns.
>Do you work for the same folks that put the "do not use in bathtub"
>label on hair dryers?
Those labels were required because a small minority of people
didn't understand that 110v AC conducts well in bathwater. It
may be obvious to you and me, but I know that if I haven't had
enough sleep, I able to do things that I would not ordinarily do.
I am in favor of people not being electrocuted, and not having
to waste time with something, that if labeled properly would make
something simple and understandable at first glance.
If we truly want to speed up the adoption of Asterisk and VOIP
because it really is the better way to go, then let's make it easy
and clear for everyone.
>If there was a disclaimer on every permutation of every possible
>configuration the code would never get updated.
Of course. I was just zipping through and put the inbound number
into the field. Again, if the pop-up read as above, we wouldn't be
having this discussion.
Remember, there are plenty of people who try Asterisk and give
up because they can't get it to work.
>To help us understand perhaps you would tell us what you thought the
>field was for and why you populated it?
See above.
>A route, in a phone system or
>a router either matches and executes or passes to the next route.
>That is what the little arrows are for so you can put the routes in
>order. Each route is evaluated based on the digit patterns.
Right. I just wanted this DID to go to the IVR. Quite simple. No
filtering needed. Shouldn't have put anything in that field.
Make sense?
>--
>
>Scott
>
>aka "Skyking"
>
>
Make sense?
I was trying to be funny, once we got your problem solved.
Until we have one button labeled 'read mind' and another 'auto configure' everything else is a compromise.
You know sometimes we just have to sit back and be grateful of what we get for free. I have a quote on my desk for an IP voice license add on to an existing NEC PBX, it's $18,000. Sometimes we (users in general) take Open Source for granted.




Member Since:
2007-09-17