TIPS Outbound Calls - IncrediblePBX - Ubuntu14

[Bryan Cole]

Hello All,

Been using PIAF in various capacities for about 5 years now - thanks to every one of you who contribute to the project!

I'm not a Linux guru in any way, but I can usually get by as needed. I am a bit more comfortable with Ubuntu, so I fired up a linode instance (my favorite host) - made the modifications to boot using the distribution kernel, and installed IncrediblePBX with zero issues (it seemed.)

I'm able to receive inbound calls on vitelity DIDs, and sub accounts in Vitelity show registered (which makes me think that the vitel-outbound trunk is properly registered.

While some of the asterisk logfile is a mystery to me, I usually find a very large amount of entries for any successful internal and external call. However any attempted outbound calls result in a very small number of logfile entries, as though some parts of the system are not even executing.

Here's an example log entry from an attempted external call:

== Using SIP VIDEO TOS bits 136​

== Using SIP VIDEO CoS mark 6​

== Using SIP RTP TOS bits 184​

== Using SIP RTP CoS mark 5​

-- Executing [14084170068@from-internal:1] ResetCDR("SIP/61000-0000001c", "") in new stack​

-- Executing [14084170068@from-internal:2] NoCDR("SIP/61000-0000001c", "") in new stack​

-- Executing [14084170068@from-internal:3] Progress("SIP/61000-0000001c", "") in new stack​

-- Executing [14084170068@from-internal:4] Wait("SIP/61000-0000001c", "1") in new stack​

> 0x7f3fb003a550 -- Probation passed - setting RTP source address to 67.169.179.211:50044​

> 0x7f3fb003a550 -- Probation passed - setting RTP source address to 67.169.179.211:50044​

-- Executing [14084170068@from-internal:5] Progress("SIP/61000-0000001c", "") in new stack​

-- Executing [14084170068@from-internal:6] Playback("SIP/61000-0000001c", "silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer") in new stack​

-- <SIP/61000-0000001c> Playing 'silence/1.gsm' (language 'en')​

-- <SIP/61000-0000001c> Playing 'cannot-complete-as-dialed.gsm' (language 'en')​

-- <SIP/61000-0000001c> Playing 'check-number-dial-again.gsm' (language 'en')​

-- Executing [14084170068@from-internal:7] Wait("SIP/61000-0000001c", "1") in new stack​

-- Executing [14084170068@from-internal:8] Congestion("SIP/61000-0000001c", "20") in new stack​

== Spawn extension (from-internal, 14084170068, 8) exited non-zero on 'SIP/61000-0000001c'​

-- Executing [h@from-internal:1] Hangup("SIP/61000-0000001c", "") in new stack​

​

== Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/61000-0000001c'​

​

I know it's a shot in the dark - anyone have any idea where I could start, to figure out where outbound routes/calls/trunks are broken?

Thanks much!
~Bryan

 

[john p]

Here are a few things I'd check - not an expert but things I noted.
1) On the Asterisk settings > SIP settings menu, verify NAT settings are correct & disable video.
2) In Connectivity > Trunks > Vitelity outbound, ensure no register string is set
3) On the FreePBX status screen, ensure you see 1 more trunk online than registered (e.g., 3 online, 2 registered).
#2/3 are something Vitelity TS told me to do when, after a year+, I started having wierd problems. I understood from TS that setting an outbound trunk registration could produce problems. Also, unlike the other vendoes I've used, Vitelity requires a separate inbound & outbound trunk.
Hope this helps.

 

[rossiv]

Based on your log output, what you are dialing (14084170068) isn't matching any outbound routes. Check your outbound routes and make sure you have a 1NXXNXXXXXX rule in there somewhere.

 

[Bryan Cole]

thanks john and rosslv - I'll set out to check these things asap!

I kept thinking it strange that there was no entry in the log for some kind of attempt to dial out that failed. But perhaps this sort of "fall-through" case is not set to be logged. Will report findings back here.

Thanks again for the quick reply!
~Bryan

 

[rossiv]

I kept thinking it strange that there was no entry in the log for some kind of attempt to dial out that failed. But perhaps this sort of "fall-through" case is not set to be logged. Will report findings back here.
~Bryan

There's nothing for it to long - there was never any attempt to dial out on a trunk.

You can see on line 12 where it played the "Cannot be completed as dialed" message. That message only gets played when there is nothing in dialplan that matches the digits dialed. If something else had gone wrong like a trunk configuration error that did match dialplan, you'd see much different output.

As far as Asterisk is concerned, you dialed random digits that mean nothing to it. As such, it had nowhere to send it - trunk or otherwise.

 

[Bryan Cole]

Thanks rosily, that makes sense. I knew this would be something simple... It was simply a type in the outbound routes - as you stated, there was no match on any outbound route, therefore it simply went straight through and never activated a route.

Thanks again for the help!
~Bryan