cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6712
Views
0
Helpful
31
Replies

Total newbie looking for assistance with TCL - SIP and Hookflash to FXO

Jim.Phillipps
Level 1
Level 1

Hi,

i've been tasked with helping a customer integrate a legacy pbx to some new SIP terminals. 

Call flow is as follows:

PSTN --> PBX / ACD -- call delivered to extension 1001 through 1004.  These are analog lines.

The FXS on the PBX is wired to matching FXO on the 2921 Router with the ports configured with PLAR OPX to the SIP devices that are registered to a SIP proxy.  So if 1001 gets the call it will go out the analog line, connect to the FXO and Plar to, say 1001 that is the IP phone.

This all works.

Issue is when the terminal needs to transfer the call back into the old pbx.   They need to grab dial tone from the FXS off of the pbx through the FXO and send the call back.  Everything i've tried to do has failed and is sending me back to a TCL script with some call handling to be able to release the call back to the pbx off of that incoming call leg.

Some extremely nice people have shared a similar TCL script with me, and we are finally attacking it, and trying to understand but if someone has some better ideas or a way to pair down the script to make it easy to follow it would be great.

What i have tried is using CME instead of the sip proxy server and have the terminals register directly.  no luck.  I used CIPC to see if we can emulate what happens - and actually CIPC has a flash softkey and it worked - so we know it's possible.  The flash key does not exist on any SIP profiles for CME.  I wanted to pcap a successful flash and transfer but it would not work.   Transfer off a cisco ip phone registered as a sip client results in a new call going back, hairpinning the call  and not flashing and re-using the same line, and therefore freeing it up.

Any help / direction is appreciated.   For those that can help I'll share the TCL with you directly as it is not my work, and was given it by the authors when they solved a similar, but not identical problem.  They had a few more constraints.   So i know it's doable, i just need help and i'm willing to debug, test and learn.  

Thanks

Jim

31 Replies 31

I am going through the logs - I see:

p  9 03:52:05.741: (CALLDISCONNECT(2), ev_leg_timer(1)--(act_Cleanup)-->(any_state(0))

Sep  9 03:52:05.741: (IVRACTIVE(3), ev_transfer_request(230)--(act_IVRActive)-->(SENDHFLASH(4))

Sep  9 03:52:05.741: (CALLDISCONNECT(2), ev_media_done(200)--(act_Cleanup)-->(any_state(0))

Sep  9 03:52:05.741: (SENDDIGITS(5), ev_media_done(200)--(act_DigitSend)-->(CALLEND(6))

Sep  9 03:52:05.741: (SENDHFLASH(4), ev_disconnect_done(23)--(act_HookFlash)-->(SENDDIGITS(5))

Sep  9 03:52:05.741: (any_state(0), ev_disconnected(22)--(act_Cleanup)-->(any_state(0))

Sep  9 03:52:05.741: (CALLEND(6), ev_media_done(200)--(act_Cleanup)-->(CALLDISCONNECT(2))

Sep  9 03:52:05.741: (CALLDISCONNECT(2), ev_disconnect_done(23)--(act_Cleanup)-->(any_state(0))

Sep  9 03:52:05.741: (CALLDISCONNECT(2), ev_disconnected(22)--(act_Cleanup)-->(any_state(0))

Sep  9 03:52:05.741: (CONNECTIVR(7), ev_setup_done(257)--(act_IVRConnected)-->(IVRACTIVE(3))

Sep  9 03:52:05.741: (CALL_INIT(1), ev_setup_indication(37)--(act_Setup)-->(CONNECTIVR(7))

Sep  9 03:52:05.741: FSM start state CALL_INIT(1)

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/Tcl_Link: Script hookflash succesfully linked.

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/AFW_ExecEnv_SetScript: Num of packTable entries: 26

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/AFW_ExecEnv_RestoreDataBackup: Script DataArea empty, do backup

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/AFW_ExecEnv_RestoreDataBackup: Script TokenTable empty, do backup

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/AFW_ExecEnv_Initiate: Execenv = 0x3E7F4100

Sep  9 03:52:05.741: //-1//AFW_:EE3E7F4100000:/AFW_ExecEnv_SetCallCorID:

Sep  9 03:52:05.741:  CallCorID is  Ig}WW,p

so I think I'm close - as I'm seeing the ev_transfer_request and the sendhflash

if this is working i'll need to somehow modify this so it's not tied to this specific IVR number of 253 (I sent it to 101) - it would be good to have this invoked and have the voice port connect to the appropriate number via the connection plar opx XXX command and not have it hardwired.  then - if this is working it could be used for all numbers.   anyways - was exciting to see the SENDHFLASH message....

cheers.

Hi Jim,

Is call answered at sip phone as I don't see call setupdone event in the logs. I don't see any sip refer message also.

Thanks,

Raghavendra

Hi. The call original ages from the fxo to the 8851 sip phone registered on another CME at 10.10.20.90. Once I had the call established i pressed transfer on the 8851 (far end CME) - and then those event messages on the fxo router were created.

I thought that the script triggered those messages based on the transfer button being pressed causing a sip refer - but I guess not.  I'll look at it again.

There is a sip trunk between the router with the fxo and the CME with the 8851 registered.   I figured this was the best way to simulate the environment as they have sip clients registered off of a proxy server and that talks to their 2921 router.  They also have similar sip protocol based dual peers.

Should I be looking for some messages on the cme side as well - se if it sends sip refer to fxo router where the tcl script is loaded on the pots dial peer?  No reason to load the script on the dial beer from the fxo router out to the CME is there?

Thanks

Jim

Hi Jim,

I don't see any SIP refer message or ev_transfer request in the logs which you attached. when you transfer from CME sip phone you need to look for refer message in FXO router.

You can also try jimflash.tcl which can receive DTMF digits.you need a small change in script to send hookflash to incoming leg when it recieve * and then the rest of digits.

proc act_ProcessDTMF { } {
# get the dtmf and duration
     set dtmf_value [infotag get evt_digit]
     set dtmf_duration [infotag get evt_digit_duration]

     if {$dtmf_value == "*"} {
          leg sendhookflash leg_incoming
     } else {
# ok, not a * so playout the dtmf event with the same duration
          leg senddigit leg_incoming $dtmf_value -t $dtmf_duration
     }
}


Thanks,
Raghavendra

hi

I made the changes to jimflash.tcl - applied it to the dial-peer.  when the call came in (after a reboot of router) when I hit * I put the far end on hold...  awesome.   this is my home line and I'm not sure I have capability to transfer so will try at site.  I heard dial tone on the ip phone, and on the phone call that was called in - I heard that I was on hold.

The mechanism for transfer should just be dialing digits and hanging up as technically the dial tone heard was from the FXS on the other side of the FXO (in this case my home telephone line provider).   Will test at site.

thanks.

Jim

Tested at site - and on the inbound call from the FXO the call is immediately placed on hold.  The caller hears ringback and then MOH from the ACD that is transfering out of the PBX to the FXO on the router.  So i think the app is flashing the PBX, but why?  it's not lettign the call get through and having the user initiate the flash.  I see invalid command "B" in the logs.   Any reason why it would be triggered?

There is some error in the script ( jimflash_mod.tcl ) might be some typo. could you please share the script.

Thanks,

Raghavendra

In your previous putty logs, I see hookflash is sent to incoming leg, but there is some error in jimflash_mod.tcl. Please make sure both scripts are same.

Sep 11 12:37:09.770: //15//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(CALLACTIVE[3],ev_digit_end[20])---[act_ProcessDTMF]------

Sep 11 12:37:09.770: //15//TCL :/tcl_InfotagObjCmd:  infotag get evt_digit

Sep 11 12:37:09.770: //15//TCL :/tcl_InfotagGetObjCmd: infotag get evt_digit

Sep 11 12:37:09.770: //15//AFW_:/vtr_ev_digit: argc 2

Sep 11 12:37:09.770: //15//AFW_:/vtr_ev_digit: digit=*

Sep 11 12:37:09.770: //15//TCL :/tcl_InfotagObjCmd:  infotag get evt_digit_duration

Sep 11 12:37:09.770: //15//TCL :/tcl_InfotagGetObjCmd: infotag get evt_digit_duration

Sep 11 12:37:09.770: //15//AFW_:/vtr_ev_digdur: argc 2

Sep 11 12:37:09.770: //15//AFW_:/vtr_ev_digdur: duration=330

Sep 11 12:37:09.770: //15//TCL :/tcl_LegObjCmd:  leg sendhookflash leg_incoming

Sep 11 12:37:09.770: //15//TCL :/tcl_LegSendHookflashObjCmd: sendhookflash leg_incoming

Sep 11 12:37:09.770: //15//AFW_:/vtd_lg_incoming: argc 2

Sep 11 12:37:09.770: //15//AFW_:/vtd_lg_incoming: Legs [15 ]

Thanks,

Raghavendra

Thanks - I am at site tomorrow and will grab some logs.  I think the far end system does not support dtmf-relay rtp-nte.  will let you know what I find - thanks.

jim

Hi Rahavendra,

I was at site this AM and tested - I was able to generate a hookflash from the TCL script when using  an 8851 registered to the CME via SIP out the local FXO.  I applied the TCL to the FXO port and it worked.  When I tried using the SIP soft client they have I was not able to make it work.  I can see the * but the tone duration is 150 ms whereas I think on the the 8851 it is 380 ms.  Or maybe it's a difference of the DTMF encoding - the 8851 uses RTP-NTE, and i'm not sure what their softclient does.  Either way - I was able to grab dial tone via the flashhook initiated by the *.  Are you able to see what the differences could be?

thanks,

Jim

I think it is config issue,looks like soft client sending digits as SIP Info. try to configure as dtmf as below.

dtmf-relay sip-notify

Thanks,

Raghavendra

ok - we will try that.  Thanks.    DTMF detection will work for rtp-nte (we've seen that) and hopefully it's supported for sip-info - i'm not in front of my router now, but sip-notify enables dtmf for SIP info?

Jim

sip-notify for dtmf same as rtp-nte. If rtp-nte works you can use that.

Thanks,

Raghavendra

The solution - pbx - is from Frequentis - specialized equipment.  The do SIP-Info - is this the same as SIP-NOTIFY?  They were not successful with that test.  I'm wondering if I look at specific SIP messaging to try and trigger the hookflash if they can't generate the proper DTMF.  Any suggestions?

If they can't generate DTMF digits, the other option is to get ev_transfer_request for SIP refer transfer.

You should see below log when TCL script get ev_transfer_request after SIP refer message.

050275: *Sep 11 07:02:40.601: //88//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(IVRACTIVE[3],ev_transfer_request[222])---[act_IVRActive]------
050276: *Sep 11 07:02:40.601: //88//TCL :/tcl_InfotagObjCmd:  infotag get evt_transfer_info transferDest
050277: *Sep 11 07:02:40.601: //88//TCL :/tcl_InfotagGetObjCmd: infotag get evt_transfer_info transferDest
050278: *Sep 11 07:02:40.601: //88//AFW_:/vtr_ev_transfer_info: argc 3 argindex 2
050279: *Sep 11 07:02:40.601: //88//AFW_:/vtr_ev_transfer_info:  transferTo


Thanks,
Raghavendra