We have a GS GXW410X and an IVR application that does SIP INFO driven flash-hook transfer through GS. Our IVR sends the SIP INFO FH followed by inband DTMF for the call transfer digits. This works and the caller connects to the transfer destination, and then our IVR BYE’s the original call leg. The problem is the now transferred caller is hung up when we send the BYE. Why is this happening? The transferred call should now be independent of the original SIP call leg through the GS gateway.
Flash hook transfer and unexpected call termination
damiano70
#2
In the SIP protocol there is no “flash key”, often referred to as “R”, it is an emulation that makes the reference gateway, it must be set correctly.
What server are you using?
kilroytrout
#3
I’m not sure what “flash key” refers to. The SIP INFO message body for the hook flash transfer that we send to the GX is:
Signal=hf\r\n
Duration=160
The GX responds with a 200 OK, and then we send the transfer DTMF digits. This works and the caller is connected to the transfer destination. The problem is when we BYE the original call leg, the caller is hung up.
scottsip
#5
the flash traditionally is a timed loop break or earth presented on a leg of an analogue circuit … im unsure as to how that translates over a sip packet.
If I understand what Jeff is doing, he’s using the IVR to do a switch hook flash (via IVR using SIP INFO to command the ATA to do the analog flash) - to do an analog side . @kilroytrout let us know if that’s the reason for using flash to an FXO (gateway GXW410x). You’re trying to transfer an CO trunk call that was answered by the application-IVR, the IVR is sending the flash and dialing DTMF to direct the telco where to transfer the CO call.
But instead of completing the transfer, its hanging up and the call is ending instead of transferring?
(BTW, very creative way to use SIP INFO to manipulate the gateway to get a feature)
nebosky9
#7
As interested GS user, I would also like to know reason for failure. As complete scenario is not depicted, I guess it is one on this picture (I also may be wrong):
Ext A is routed to IVR via PBX and GXW, and after connected to IVR and listening for voice message it should be routed to Ext C with @kilroytrout proposed SIP INFO msg.
It is not clear (to me) if Hook Flash on FXO port on GXW410x was at all performed after IVR asked for it. If performed, then PBX receives Hook Flash on its FXS B port, and then is the one to give its Hold tone to Party A.
It is then easy to resolve: if Party A hears Hold tone from PBX, then we know that GXW410x has received SIP INFO and performed Hook Flash, and that it is understood from PBX.
But I am afraid @kilroytrout is not present here any more after so much time to give answer - what tone hears Ext A during Transfer.
lpneblett
#8
You need to diagram the relevant devices and how a call comes in.
From what you have described, it seems that the call comes into the gateway and is routed to your device that accommodates the IVR. What we don’t really understand is where the transfer location is (what device) and what device is actually doing the transfer.
The GXW is a gateway and does not accommodate transfers via dial codes or other. It is my take that the GXW is merely converting the call from analog to SIP for handing off to a PBX or other than can then take control of the call and handle according to include transferring and ending calls. If you are sending a BYE to the GXW then you are ending the call as the GXW has the call associated to an analog line upon which the call was originally seen. The transfer function should be taking place in a PBX or other device beyond the GXW. The GXW has to remain in the call path to keep the call alive.
As the call must continue to remain alive in order for the call to remain active following the transfer, it is not clear why a BYE is sent to the GXW following a the transfer. Is there still not a need to keep the analog call alive so the call can continue?
nebosky9
#9
I did not originate this ticket, i just coment on it - how I understand it. So my drawing may be wrong to original @kilroytrout, but also may be right, at least is one correct scenario. I am fascinated that @kilroytrout almost made Transfer complete.
Mostly agree with you Ipneblett, that GXW does not make transfer, but PBX should. Thats why I asked which tone Ext A hears during transfer - if it is PBX hold tone, then it is PBX doing the transfer. And it should be PBX, agree with you.
But your question on BYE is tricky. When GS SIP phone is used, its Transfer key is used to finalize Transfer and release UCM resources. But for analog ports it is different. Point here is that after BYE from IVR, GXW should release itself from IVR as well as to make On Hook on FXO and release itself completelly. It is total copy of simple PBX transfer, look at picture:
Ext A from PSTN wants to get Ext C in old PBX, but first must be routed by PBX to Ext B - attendent (authorized to pass calls to further PBX extensions). After receiving call from Ext A, Ext B makes Flash Hook and dials Ext C. PBX gives Hold tone to Ext A. This is classic Transfer on PBX FXS port. Before or after Ext C answers, Ext B goes On Hook and Ext A is connected to Ext C. FXS B port is released. Call is now established between Ext A and Ext C with Ext B out of it. Ext B is idle and ready to receive new call.
So, Ext B - Attendant should be replaced by machine that can make Hook Flash on PBX FXS port, like Ext B does and then release itself. Ext B Flash responds to GXW FXO Flash.
Here this machine is set of GXW and IVR, picture on my previous post. Machine also may be UCM630x which integrates FXO GW and IVR, as better solution, no need for BYE and SIP INFO or other msg, everything is done inside UCM 630x.
I made another ticket few days ago: FXO Flash, asking if GS has any device that can make FXO Hook Flash and also generate SIP msg to FXO Gw to do the Flash (for UCM with no FXO port). I did not find answer on this yet, I hope on this ticket.
This issue is past oriented, hard to be accepted for development. I think also it is not well understood, so easy rejected. If understood better, may be action on it. I made above text and drawings, to show how simple idea is behind FXO Hook Flash as Transfer issue.
martyatherton
#10
I apologize for resurrecting a possibly abandoned post. I thought it was a really interesting way to perform a switch hook flash on the CO trunk port, with the sole purpose to do a “Centrex Transfer” or “CO side transfer” where the FXO trunk port would perform the flash on the trunk port (100ms typical), something would dial DTMF (in @kilroytrout example - IVR would dial digits), then BYE would be sent to complete the analog CO side transfer.
I used to do precisely this thing for a customer with a Samsung OfficeServ PBX - that PBX didnt have the capability of VoIP at the time, so the users wanted to do CO transfer via IVR so the call would free up the limited number of analog lines the PBX had. Plus the cell phone the ivr transfered the call to would get the outside CID of the caller, and the audio quality was much better than doing analog trunk-to-trunk conference controlled by the PBX.
I was under the understanding that the GXW didnt have native CO FLASH (or asterisk didnt provide this kind of command structure, i’m not sure), so seeing the SIP INFO FH and further with @nebosky9 feedback further stoked my curiosity.
lpneblett
#11
You could be correct; hence why I asked for more details. The only thing mentioned was the transfer was successful, but who/what actually accommodated the xfer and to what and why would the call still be on the GXW? I would think the provider would have implemented the transfer/forward on their side.
If it is centrex, I wonder what the monthly cost is? I got rid of the last one my clients had in 2008.