Unable to route inbound calls from trunk/ Broadsoft

Hello

I have been trying to troubleshoot this issue for over 10days now and I nowhere close to a resolution.

I have a SIP trunk with a wholesale MVNO provider using Broadsoft as their platform. Authentication is done based on IP addresses rather than username/password.
The MVNO is providing mobile SIM cards that effectively act as SIP extensions on their platform. So to call a SIM card all you need to do is place a SIP call (e.g. SIP/@provider.net>

I am also using an IAX trunk to a VOIP provider who is providing inbound/outbound DDI numbers.

I have all the appropriate rules in the iptables and the trunk seems to be active.

I can initiate calls to the SIM cards without any problem and the trunk appears to be active.

sip show peers

Name/username Host Dyn Forcerport ACL Port Status
provider_trnk 10.0.4.4 N A 5060 OK (15 ms)

In my configuration I have created two SIP extension (one for each SIM card) with a custom dial string
dial:SIP/[email protected]

However, I have a problem with the inbound path (i.e. receiving calls from the trunk). The trunk configuration is

allow=ulaw&alaw
type=friend
trustrpid=yes
canreinvite=no
dtmfmode=rfc2833
insecure=very
host=10.0.4.4
port=5060
context=from-trunk

I only have one default outbound route that sends all calls down the IAX trunk. This again works fine for any outbound call from any other PBX extension.

However, when I dial a number from the SIM I get an error message in FreePBX saying “the number you have dialled is not in service”

I assume that asterisk is unable to match the outbound call to the trunk.

Can someone please advise on the configuration or any ideas on to troubleshoot?

Thank you

Your

host=10.0.4.4

is not publicly routeable.

Thanks. I have intentially hidden the real ip address of the server.

DIalplan log from time of call, post relevant portion.

Hi Scott - Sorry can you please tell me how I can extract that.

I don’t see any dialplan debug info in the log file.

Thanks

What verbosity level are you set to?

Hi Scott

Not sure how I can check that from the asterisk CLI the

‘logger show channels’ command displays

Channel Type Status Configuration


/var/log/asterisk/full File Enabled - DEBUG NOTICE WARNING ERROR VERBOSE
Console Enabled - NOTICE WARNING ERROR

but I only see messages related to Asterisk no debug info for the sip traffic.

Can you please tell me how I can enable this level of debugging?

Thanks

I don’t think it is a SIP issues as the call is getting to you.

You just need to toggle it for the period of the troubleshooting:

For SIP you can constrain by host or IP

sip set debug ip (or host) xxxxx

Use SIP set debug off.

I turn off dial plan debugging to unclutter the screen.

Dial plan debugging level is controlled by verbosity setting:

core set verbose xxx where xxx is an an Integer between 0 and 128, each bit is another successive level of detail and they are additive.

Also, for reference most modules have their own debug.

Asterisk system debug is controlled by the core set verbose xxxx and it is also bitmapped.

The more I look into this I think that the problem is with the dialplan context. I may need to create a custom dialpan for this provider. Please find below the debug output.

I would appreciate any help or pointers to create a custom dialplan/context to handle the incoming SIP traffic correctly.

Provider: provider.net
Provider external IP: 10.0.4.4
Provider internal IP: 172.0.0.182
My PBX External IP: 192.168.46.239
Number dialed: 442071234567
Username: USIM12345

[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c: Reliably Transmitting (NAT) to 10.0.4.4:5060:
OPTIONS sip:10.0.4.4 SIP/2.0
Via: SIP/2.0/UDP 192.168.46.239:5060;branch=z9hG4bK571fd661;rport
Max-Forwards: 70
From: “Unknown” sip:[email protected];tag=as371928cd
To: sip:10.0.4.4
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.20.1)
Date: Mon, 08 Jul 2013 13:17:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c:
<— SIP read from UDP:10.0.4.4:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.46.239:5060;branch=z9hG4bK571fd661;rport=5060
From: “Unknown” sip:[email protected];tag=as371928cd
To: sip:10.0.4.4
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Server: Sipwise NGCP Proxy 2.X
Content-Length: 0

<------------->
[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c: — (8 headers 0 lines) —
[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c:
<— SIP read from UDP:10.0.4.4:5060 —>
SIP/2.0 200 Alive
Record-Route: sip:172.0.0.182;r2=on;lr=on;ftag=as371928cd;ngcplb=yes
Record-Route: sip:10.0.4.4;r2=on;lr=on;ftag=as371928cd;ngcplb=yes
Via: SIP/2.0/UDP 192.168.46.239:5060;branch=z9hG4bK571fd661;rport=5060
From: “Unknown” sip:[email protected];tag=as371928cd
To: sip:10.0.4.4;tag=919d46fc866a35d88e9332805505f824.5ae6
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Server: Sipwise NGCP Proxy 2.X
Content-Length: 0

<------------->
[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c: — (10 headers 0 lines) —
[2013-07-08 14:17:32] VERBOSE[1465] chan_sip.c: Really destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c:
<— SIP read from UDP:10.0.4.4:5060 —>
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Max-Forwards: 70
Record-Route: sip:10.0.4.4;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
Record-Route: sip:172.0.0.182;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
Via: SIP/2.0/UDP 10.0.4.4;branch=z9hG4bKc6b.5c0e44b577898cd2e656b6e7cd933372.0
Via: SIP/2.0/UDP 172.0.0.182:5080;branch=z9hG4bKFBu0iaJg;rport=5080
From: sip:[email protected];tag=201E3B6E-51DABC0A0007AEF4-9BFFF700
To: sip:[email protected]
CSeq: 10 INVITE
Call-ID: c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1
Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS
Supported: timer
Content-Type: application/sdp
Content-Length: 226
Contact: sip:[email protected]:5060;ngcpct=‘sip:172.0.0.182:5080’

v=0
o=Partitionware-MGW 1 1 IN IP4 10.0.4.4
s=SIP Call
c=IN IP4 10.0.4.4
t=0 0
m=audio 37642 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=nortpproxy:yes
<------------->
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: — (15 headers 11 lines) —
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Sending to 10.0.4.4:5060 (NAT)
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Using INVITE request as basis request - c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Found peer ‘provider_trnk’ for ‘USIM12345’ from 10.0.4.4:5060
[2013-07-08 14:18:02] VERBOSE[1465] netsock2.c: == Using SIP RTP TOS bits 184
[2013-07-08 14:18:02] VERBOSE[1465] netsock2.c: == Using SIP RTP CoS mark 5
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Found RTP audio format 8
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Found RTP audio format 101
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Found audio description format PCMA for ID 8
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Found audio description format telephone-event for ID 101
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Peer audio RTP is at port 10.0.4.4:37642
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: Looking for 442071234567 in from-trunk (domain 192.168.46.239)
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: list_route: hop: sip:10.0.4.4;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: list_route: hop: sip:172.0.0.182;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c:
<— Transmitting (NAT) to 10.0.4.4:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.4.4;branch=z9hG4bKc6b.5c0e44b577898cd2e656b6e7cd933372.0;received=10.0.4.4;rport=5060
Via: SIP/2.0/UDP 172.0.0.182:5080;branch=z9hG4bKFBu0iaJg;rport=5080
Record-Route: sip:10.0.4.4;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
Record-Route: sip:172.0.0.182;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
From: sip:[email protected];tag=201E3B6E-51DABC0A0007AEF4-9BFFF700
To: sip:[email protected]
Call-ID: c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1
CSeq: 10 INVITE
Server: FPBX-2.10.1(1.8.20.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:[email protected]:5060
Content-Length: 0

<------------>
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [442071234567@from-trunk:1] NoOp(“SIP/provider_trnk-00000018”, “Catch-All DID Match - Found 442071234567 - You probably want a DID for this.”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [442071234567@from-trunk:2] Goto(“SIP/provider_trnk-00000018”, “ext-did,s,1”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Goto (ext-did,s,1)
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:1] ExecIf(“SIP/provider_trnk-00000018”, “1?Set(__FROM_DID=s)”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:2] Set(“SIP/provider_trnk-00000018”, “CDR(did)=s”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:3] ExecIf(“SIP/provider_trnk-00000018”, “1 ?Set(CALLERID(name)=USIM12345)”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:4] Set(“SIP/provider_trnk-00000018”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:5] Set(“SIP/provider_trnk-00000018”, “CALLERPRES()=allowed_not_screened”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [s@ext-did:6] Goto(“SIP/provider_trnk-00000018”, “app-blackhole,hangup,1”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Goto (app-blackhole,hangup,1)
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [hangup@app-blackhole:1] NoOp(“SIP/provider_trnk-00000018”, “Blackhole Dest: Hangup”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: – Executing [hangup@app-blackhole:2] Hangup(“SIP/provider_trnk-00000018”, “”) in new stack
[2013-07-08 14:18:02] VERBOSE[4071] pbx.c: == Spawn extension (app-blackhole, hangup, 2) exited non-zero on ‘SIP/provider_trnk-00000018’
[2013-07-08 14:18:02] VERBOSE[4071] chan_sip.c: Scheduling destruction of SIP dialog ‘c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1’ in 6400 ms (Method: INVITE)
[2013-07-08 14:18:02] VERBOSE[4071] chan_sip.c:
<— Reliably Transmitting (NAT) to 10.0.4.4:5060 —>
SIP/2.0 603 Declined
Via: SIP/2.0/UDP 10.0.4.4;branch=z9hG4bKc6b.5c0e44b577898cd2e656b6e7cd933372.0;received=10.0.4.4;rport=5060
Via: SIP/2.0/UDP 172.0.0.182:5080;branch=z9hG4bKFBu0iaJg;rport=5080
From: sip:[email protected];tag=201E3B6E-51DABC0A0007AEF4-9BFFF700
To: sip:[email protected];tag=as5340c1a3
Call-ID: c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1
CSeq: 10 INVITE
Server: FPBX-2.10.1(1.8.20.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------>
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c:
<— SIP read from UDP:10.0.4.4:5060 —>
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Max-Forwards: 70
Record-Route: sip:10.0.4.4;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
Record-Route: sip:172.0.0.182;r2=on;lr=on;ftag=201E3B6E-51DABC0A0007AEF4-9BFFF700;ngcplb=yes
Via: SIP/2.0/UDP 10.0.4.4;branch=z9hG4bKc6b.5c0e44b577898cd2e656b6e7cd933372.0
Via: SIP/2.0/UDP 172.0.0.182:5080;branch=z9hG4bKFBu0iaJg;rport=5080
From: sip:[email protected];tag=201E3B6E-51DABC0A0007AEF4-9BFFF700
To: sip:[email protected];tag=as5340c1a3
Call-ID: c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1
CSeq: 10 ACK

<------------->
[2013-07-08 14:18:02] VERBOSE[1465] chan_sip.c: — (10 headers 0 lines) —
[2013-07-08 14:18:08] VERBOSE[1465] chan_sip.c: Really destroying SIP dialog ‘c321c0ee-d278-44e9-b2b0-1d05925cd3bd1_b2b-1’ Method: ACK

Ok, not sure why.

Catch-All DID Match - Found 442071234567 - You probably want a DID for this.

You can route the 442071234567 pattern with inbound routes.

thanks Scott

This is exactly the problem… I cannot specify a DDI for all outbound calls made from that SIM card. The 02071234567 number is the outbound number dialled from the SIM card (as a mobile user would dial out)

I somehow need to create a custom dialplan to detect the USIM user ID that initiates the call to any random outgoing number and match that userID to an outgoing route.

I have no experience in writing custom dialplans any suggestions would be gratefully received

Thank you

Okay, still somewhat confused, you want to turn this number around and send it out a route?

Just change the context of the trunk to from-internal and use the outbound route module.

sorry for the confusion… let me see if I can help to explain this better.

SIM card (acts as SIP extension on the broadsoft platform and it has a userid in the form [email protected])

Since the SIP trunk is active. I can instigate an outbound call (ie. ring the SIM card from FreePBX) by simply issuing a SIP/[email protected]

I have successfully to create inbound routes that connect an extenal DDI number to the SIM card. Inbound calls coming to 0207xxx0001 will call SIM2, calls coming to 0207xxx0002 will ring SIM2, etc

The problem is the reverse route. So a mobile user that dials a number from his mobile.

The SIP call comes into FreePBX from the provider trunk - I am unable to create a matching Outbound route. When I change the context to “from-internal”, how can I match it to the inbound user ID of the SIM card?

The outbound module does not accept userids as the CID. Hope that helps to explain the setup better. Thanks

Sorry one more question please:

The outbound numbers appear to be coming from the trunk in e164 format

44207xxxxx

how can convert this to a standard dialout number. eg. for the UK it needs to strip the 44 and replace with ‘0’ for other destinations it should add ‘00’ before the number

Thanks