Call forward extension to external number

Well, there is not too much to post. I dial *72 and go through the call forward unconditional messages. I enter the phone number they are going to: 555-1234 and hang up. When dialing internally, the call seems to route. External calls hitting that extension go into a loop where the extremely non-helpful "all circuits busy" error crops up.

As this occurs, I notice that the dial plan is trying each and every trunk for an outbound route, and deciding that each trunk in turn is busy and that it cannot route the call outwards. When making a call to the extension internally, the first trunk selected works and dials out.

So, what I am going to do for troubleshooting is make multiple calls to the forwarded extension and identify how the calls route differently between the external and internal calls.

The only clue is that asterisk seems to be trying to use the inbound caller ID to make an outbound call with the same caller ID - and that my trunks are rejecting outbound calls with the original caller ID.

I could post segments of the logs, but they are extremely verbose. Each time I try this, Asterisk puts about 5000 lines into the full log - or out to the console.

The below is probably the most relevant of this I believe:
XXX555134 is the cell phone
XXX5559090 is the inbound caller from an external network

-------------------------------------------------------------------------------------

Aug 8 14:09:32 DEBUG[26852] pbx.c: Function result is 'SIP/DVTrunk9'
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing Set("Local/XXX5551234@from-internal-1992,2", "custom=SIP/DVTrunk9") in new stack
Aug 8 14:09:32 DEBUG[26852] app_macro.c: Executed application: Set
Aug 8 14:09:32 DEBUG[26852] pbx.c: Expression result is '0'
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing GotoIf("Local/XXX5551234@from-internal-1992,2", "0?customtrunk") in new stack
Aug 8 14:09:32 DEBUG[26852] pbx.c: Not taking any branch
Aug 8 14:09:32 DEBUG[26852] app_macro.c: Executed application: GotoIf
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing Dial("Local/XXX5551234@from-internal-1992,2", "SIP/DVTrunk9/XXX5551234|300|") in new stack
Aug 8 14:09:32 DEBUG[26852] chan_sip.c: Setting NAT on RTP to 524288
Aug 8 14:09:32 DEBUG[26852] chan_sip.c: Outgoing Call for XXX5551234
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Called DVTrunk9/XXX5551234
Aug 8 14:09:32 DEBUG[26795] chan_sip.c: Acked pending invite 102
Aug 8 14:09:32 DEBUG[26795] chan_sip.c: Stopping retransmission on '0f91f4697f99d50015688201243364b2@192.168.1.9' of Request 102: Match Found
Aug 8 14:09:32 DEBUG[26795] chan_sip.c: Acked pending invite 103
Aug 8 14:09:32 DEBUG[26795] chan_sip.c: Stopping retransmission on '0f91f4697f99d50015688201243364b2@192.168.1.9' of Request 103: Match Found
Aug 8 14:09:32 WARNING[26795] chan_sip.c: Forbidden - wrong password on authentication for INVITE to '"XXX5559090" ;tag=as54df2d
97'
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- SIP/DVTrunk9-0883bfe0 is circuit-busy
Aug 8 14:09:32 DEBUG[26852] chan_sip.c: update_call_counter(XXX5551234) - decrement call limit counter
Aug 8 14:09:32 VERBOSE[26852] logger.c: == Everyone is busy/congested at this time (1:0/1/0)
Aug 8 14:09:32 DEBUG[26852] app_dial.c: Exiting with DIALSTATUS=CONGESTION.
Aug 8 14:09:32 DEBUG[26852] app_macro.c: Executed application: Dial
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing Goto("Local/XXX5551234@from-internal-1992,2", "s-CONGESTION|1") in new stack
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Goto (macro-dialout-trunk,s-CONGESTION,1)
Aug 8 14:09:32 DEBUG[26852] app_macro.c: Executed application: Goto
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing NoOp("Local/XXX5551234@from-internal-1992,2", "Dial failed due to CONGESTION - failing through to o
ther trunks") in new stack
Aug 8 14:09:32 DEBUG[26852] app_macro.c: Executed application: NoOp
Aug 8 14:09:32 VERBOSE[26852] logger.c: -- Executing Macro("Local/XXX5551234@from-internal-1992,2", "outisbusy|") in new stack

Creating a second extension is another option I was looking at, but the documentation was sparse. The reason that I was using call-forward-to-external is that it is documented, and the procedure seems fairly simple.

I will check the docs on external extensions.

I was able to create an extension 902 that dialed 555-1234 with your directions. So, thanks very much for that!

Trouble is, the system is still not routing calls out. :(

Seems to be the exact same issue I have been having with *72 call forward.

This suggests to me that something is messed with the asterisk call routing. Which is strange, as I have made no manual edits to any of the .conf files, although I was considering doing so with extensions_custom.conf.

So, it looks like the issue I am having is related to something different with Asterisk. It is something to do with the call routing as inbound calls that are trying to go out again seem to be routing with the same information as the originating call. :(

Ah, the joys of troubleshooting. At least I am learning a great deal about Asterisk in the process.

Yes, thus if the cell phone: 555-1234 is set to extension 902, and I am sitting at extension 103 and I dial 902, I get the cell phone.

However, when coming into the phone network from outside our PBX, that is when the extension fails. I have 9 trunks - so enough to have one line for the call to be inbound on, and the same call to be outbound on the cell as well, however, the call refuses to go through if the originating call is external to the PBX.

I am using DigitalVoice out of Vancouver BC.

I think you have a good idea though, as it appears that my VOIP provider is rejecting the outbound call as it believes that the outbound call from my PBX is in fact originating from the caller ID of the first phone. That is, Asterisk seems to forward the CID info of the inbound call out with the outbound call, and DigitalVoice's servers reject that.

That is my guess at this point anyways.

Good to hear that worked for you, some providers are picky about CID info on outbound calls, I guess they want to prevent spoofing.