Call forward extension to external number
Submitted by Mr_Flibble on Wed, 08/08/2007 - 3:02pm.
I am running the latest version of Trixbox, and I am trying to set up call forwarding from an extension to a cell phone.
When I use *72 and set up the external number everything appears to work.
When I dial the extension internally, I get the target cell phone. That is, if I call forward extension 100 to 555-1234, when I call extension 100 from extension 101, I get the cell phone.
However, if I am external to the PBX (calling outside from 555-9090) when I call in, if I choose extension 100, the call fails and I get redirected to voicemail. Looking at the logs, the call is failing with the ever so helpful "all circuits busy" message which I detest due to its complete lack of specifics. And, I know for a fact that the circuits are *NOT* busy, ergo, it is something else.
What is the best way to set up call forwarding to an extension for an external number?
 
Response....
Wed, 08/08/2007 - 3:14pm
Hi, do make sure that you are not using one trunk line to come into the system and attempting to use the same trunk line to exit the system. This may give you a trunk busy becos there are no more trunks to use... or make sure that you configuration allows for the extension to pick other available trunk if the prefered is unavailable.
You may also paste the configuration file that you have so that all may see what could be wrong... Thanks
 
Well, there is not too much
Wed, 08/08/2007 - 4:55pm
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"
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
 
OK I will NOT read ALL that
Wed, 08/08/2007 - 5:18pm
Look you are going about it wrong
the way you are doing it the call is using the wrong context.
If you want to have the system call an outside line (cell phone)
create a second exten put the cell phone number in as the follw me (how ever you need to dialout) and then place a # at the end.
now forward to that phone.
Follow me has some added feature you will need
the call will take some time some give the caller some notice use the announment, you can also setup the confirm call so that you must press one to take the call (stop the call from hittng the VM)
 
Creating a second extension
Thu, 08/09/2007 - 9:21am
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.
 
Add a custom extension using
Thu, 08/09/2007 - 2:43pm
Add a custom extension using FreePBX, select Other(Custom Device) as the type
and put Local/5551234@from-internal in the "Dial" box under
Device Options
This device uses custom technology.
that will have a caller to the extension handled the same way as dialling 5551234 on an extension phone.
 
Worked Internally!
Thu, 08/09/2007 - 2:55pm
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.
 
if you dial the exact same
Fri, 08/10/2007 - 1:03pm
if you dial the exact same number from an extension phone does it work ?
 
Yes, thus if the cell phone:
Fri, 08/10/2007 - 4:26pm
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.
 
try the "Never Override
Fri, 08/10/2007 - 5:06pm
try the "Never Override CallerID" option on the trunk, fill in the correct CID info for the trunk and check the box. Once you reload the configs it may very well work. What provider are you using on the trunk?
 
I am using DigitalVoice out
Fri, 08/10/2007 - 5:11pm
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.
 
BINGO!
Fri, 08/10/2007 - 5:38pm
You hit the nail on the head. That was the problem. The CID info was being forwarded to DigitalVoice, which was rejecting the call based on that information. Once I checked never override CallerID the calls immediately started routing properly.
That just made my day! :)
 
Good to hear that worked for
Sat, 08/11/2007 - 6:51pm
Good to hear that worked for you, some providers are picky about CID info on outbound calls, I guess they want to prevent spoofing.
 
can I get your working settings for mydigitalvoice?
Tue, 12/04/2007 - 2:43pm
hello I just signed up with mydigitalvoice voip service and I am needing the configuration settings to plug in to trixbox for inbound and outbound calling.
can I get that info please?
I am using the
mydigitalvoice.com
its the us version of
mydigitalvoice.ca
thanks
Hank
 
Member Since:
2006-08-14