Automatically Hook/Flash transfer inbound POTS call to external number

General Help
, , ,
1

Does anybody here have experience or willing to offer guidance about automatically transferring an inbound call to another external number via Hook/Flash carrier functionality on POTS lines?

On the old phone system (nortel) the staff would answer a call, press “Link” button (Hook/Flash) dial the external number and then Hangup. This would transfer the caller and release the line.

Instead of setting our phones up to “forward” (night mode external answering service for example) to an external number via FreePBX, we would like them to “Hook/Flash” (link) transfer. That way the POTS line is freed up and can then “forward” another call if it comes in while the first call is still on the line.

Currently, if we use Carrier *72 PhoneNumber or just setup a second ring group for “Night Mode” in FreePBX it keeps either 1 or 2 (with a ring group) lines busy while caller is on the phone.

Longer Explanation
We are working on migrating our POTS lines to SIP. In the process we have hit a snag. We have a “main number” and hunt group on our POTS lines. The carrier is Frontier and when we use the carrier level forwarding (*72 ForwardNumber) to forward to our new SIP trunk, It makes the line busy if a call is being forwarded and will not forward a second call. In other words, if forwarding is on, it will not hunt.I have asked Frontier if they have the ability to forward any call that comes in instead of only 1 call at at time. Their customer support is TERRIBLE and after speaking to two different people, I have no hope they will be able to help.

We have at least a month (probably more) before we can port the number do to some outside contract issues. Our most pressing reason to move to SIP was that we would gain inbound capacity without adding analog lines. However, because Frontier can only forward our main line 1 call at a time, we have actually LOST the capacity of the other 2 lines in the hunt group in the interim.

As a work around, I have started setting up a second FreePBX server with a 3 line FXO card (Digium TDM400P) in it that can hopefully automatically “Hook/Flash” Transfer the calls to our SIP trunk number.

We have tested this by just hand dialing… If we “Hook/Flash” the call over, the carrier (frontier) releases that line and it can then receive another call. This should accomplish our goal of over coming our limited POTS line count.

Any suggestions, reading material etc you are willing to send my way to accomplish this would be great.

2

Send you dahdi calls to a context something like

[dahdi-xfer]
exten => s,1,Answer()
exten => s,n,Flash()
exten => s,n,SendDTMF(13235551212)
exten => s,n,Hangup()

(You could also leave out the flash and just SendDTMF(wfw13235551212) ) )

1 Like
3

Thank you! I’ll Attempt to give this a shot tomorrow. I really appreciate you taking the time to send this info over.

4

What dicko said should work. I had centrex lines like 3 years ago before going to a PRI. If that does not work I can post what I got working on my old system

5

Thank you dicko.

I got the context setup and firing off. However I’m getting the error. Suggestions?

app_flash.c: Unable to flash channel DAHDI/1-1: Device or resource busy

Also, No matter what I do, inbound CID does not work with these FXO lines. I get “UNKNOWN” in the logs. Should I post the CID question elsewhere? It does not seem to even be receiving the calling number.

I have added the below to the “DAHDi config > Global Settings > Under Custom Settings” to no avail

callerid=asreceived
hidecallerid=no
cidsignalling=bell
cidstart=ring
6

Figured out if I add the below after answer it works. However it is creating quite a bit of dead air for the caller (About 8 - 10 seconds). Is this just the nature of the process?

exten => s,n,Wait(2)

CallID is still not working… I guess it’s possible these lines do not have CID on them. When I asked Frontier (terrible tech support) they said these lines were setup just like all of our other lines (which have CID)

7

CallerID is “spilled” in NANP land between the first and second ring ( about 4 + 6 % 4 seconds), enable ‘immediate = yes’ in your appropriate dahdi channels/groups with appropriate cidsignallinfg and cidstart ( not needed in NANP land though Mark/Digium is from Alabama :slight_smile: ) , then use an inbound context to handle the s extension of “immediate=yes” then the “wait” will be minimized.

8

dicko, I believe I follow. Because the carrier may not be sending any CID info according to the troubleshooting in this article. http://kb.digium.com/articles/Configuration/Troubleshooting-missing-caller-ID-on-Analog-calls. (I don’t see any CID between first and second ring in WAV editor) I have shutoff CID.

I also turned on immediate=yes.

The caller now hears between 2 and 3 rings, 8 - 10 seconds of dead space and then ringing again.

I tried setting wait to Wait(1) or removing it but if it is anything less than Wait(2) the Flash() will not get hooked by the carrier.

Is this just the limitation of this process?

9

No, with immediate=yes, no CallerID and a context that handles the s extension works as quick as you want apart from Fax calls, the DID is intrinsic to the channel so start with DumpChan() in your inbound context. to route as appropriate., it rings, Asterisk answers and Dahdi knows what rang, as soon as you answer, then you can Flash() and PlayDTMF() as soon as the far end is ready. so yes a wait() in the inbound context after the aAnswer() might be experimented with.

10

Thanks dicko. I have implemented all you said. Still about an 8 second delay from when the first ringing stops for caller and the second ringing starts. Also still takes about 1 - 2 rings (to the caller) before it goes silent (first ringing). Could be carrier

Here is the DumpChan().

Dumping Info For Channel: DAHDI/3-1:
================================================================================
Info:
Name= DAHDI/3-1
Type= DAHDI
UniqueID= 1496436518.4
LinkedID= 1496436518.4
CallerIDNum= (N/A)
CallerIDName= (N/A)
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits= (N/A)
RDNIS= (N/A)
Parkinglot=
Language= en
State= Up (6)
Rings= 1
NativeFormat= (ulaw)
WriteFormat= ulaw
ReadFormat= ulaw
RawWriteFormat= ulaw
RawReadFormat= ulaw
WriteTranscode= No
ReadTranscode= No
1stFileDescriptor= 30
Framesin= 37
Framesout= 0
TimetoHangup= 0
ElapsedTime= 0h0m0s
BridgeID= (Not bridged)
Context= dahdi-xfer-othercc
Extension= s
Priority= 2
CallGroup=
PickupGroup=
Application= DumpChan
Data= (Empty)
Blocking_in= (Not Blocking)

Variables:
CRM_LINKEDID=1496436518.4
CRM_SOURCE=
CRM_DIRECTION=INBOUND
AGISTATUS=SUCCESS
lookupcid=
CIDSFSCHEME=QUxMfEFMTA==
CALLINGNUMPRES_SV=allowed_not_screened
CALLINGNAMEPRES_SV=allowed_not_screened
REVERSAL_REJECT=FALSE
MOHCLASS=
FROM_DID=*USA NUMBER REMOVED*
GOSUB_RETVAL=
CALLED_BLACKLIST=1
FROMEXTEN=unknown
REC_POLICY_MODE_SAVE=
MON_FMT=wav
TIMESTR=20170602-134838
YEAR=2017
MONTH=06
DAY=02
NOW=1496436518
REC_STATUS=INITIALIZED
DIRECTION=INBOUND
MACRO_DEPTH=0
CHAN=3
DID=s
================================================================================
11

And the whole [context] that handles the channel would be needed, also a log of an actual call , both would be diagnostic, grep it from the log file as the console capture doesn’t have the timestamp ( you can change that, which is a good idea in my opinion :wink: )

12

Context in: /etc/asterisk/extensions_custom.conf

[dahdi-xfer-othercc]
exten => s,1,Answer()
exten => s,n,DumpChan()
exten => s,n,Wait(2)
exten => s,n,Flash()
exten => s,n,SendDTMF(*USA NUMBER REMOVED*)
exten => s,n,Hangup()

This is from the Log file. I set the context on the analog line to “dahdi-xfer-othercc”. it was “from-analog” and I was using “DAHDi Channel DIDs” to give each port a number and then using inbound routes to send them to their various destinations. To bypass and extra routing, I just forced it to this route. Caller still rings between 1 and 2 times before going silent… followed by 8 - 10 seconds of silence

[2017-06-02 14:19:28] VERBOSE[1897][C-00000000] sig_analog.c: Starting simple switch on 'DAHDI/3-1'
[2017-06-02 14:19:28] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:1] Answer("DAHDI/3-1", "") in new stack
[2017-06-02 14:19:28] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:2] DumpChan("DAHDI/3-1", "") in new stack
[2017-06-02 14:19:28] VERBOSE[1897][C-00000000] app_dumpchan.c:
Dumping Info For Channel: DAHDI/3-1:
================================================================================
Info:
Name= DAHDI/3-1
Type= DAHDI
UniqueID= 1496438368.0
LinkedID= 1496438368.0
CallerIDNum= (N/A)
CallerIDName= (N/A)
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits= (N/A)
RDNIS= (N/A)
Parkinglot=
Language= en
State= Up (6)
Rings= 1
NativeFormat= (ulaw)
WriteFormat= ulaw
ReadFormat= ulaw
RawWriteFormat= ulaw
RawReadFormat= ulaw
WriteTranscode= No
ReadTranscode= No
1stFileDescriptor= 30
Framesin= 1
Framesout= 0
TimetoHangup= 0
ElapsedTime= 0h0m0s
BridgeID= (Not bridged)
Context= dahdi-xfer-othercc
Extension= s
Priority= 2
CallGroup=
PickupGroup=
Application= DumpChan
Data= (Empty)
Blocking_in= (Not Blocking)

Variables:
================================================================================
[2017-06-02 14:19:28] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:3] Wait("DAHDI/3-1", "2") in new stack
[2017-06-02 14:19:30] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:4] Flash("DAHDI/3-1", "") in new stack
[2017-06-02 14:19:31] VERBOSE[1897][C-00000000] app_flash.c: Flashed channel DAHDI/3-1
[2017-06-02 14:19:31] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:5] SendDTMF("DAHDI/3-1", "*USA NUMBER REMOVED*") in new stack
[2017-06-02 14:19:35] VERBOSE[1897][C-00000000] pbx.c: Executing [s@dahdi-xfer-othercc:6] Hangup("DAHDI/3-1", "") in new stack
[2017-06-02 14:19:35] VERBOSE[1897][C-00000000] pbx.c: Spawn extension (dahdi-xfer-othercc, s, 6) exited non-zero on 'DAHDI/3-1'
[2017-06-02 14:19:35] VERBOSE[1897][C-00000000] sig_analog.c: Hanging up on 'DAHDI/3-1'
[2017-06-02 14:19:35] VERBOSE[1897][C-00000000] chan_dahdi.c: Hungup 'DAHDI/3-1'