Announced Call Transfer

[Guest Rico]

I download VG 4.9 and install it in PC win2k SP2 using Intel D4PCI. The setup seems working fine except for an announced call transfer which works like a blind transfer. On the log the tsfrcall wave files are play but never heard on the phone being called. In fact, that phone is still ringing and VG release it already, waiting status. The blind transfer

works fine. BTW, here is the log:

00422 5 [Get Number] Number Input 686

00812 5 LsXferStart EV_TIMEOUT_READYTOBEGINTRANSFER

00812 5 RVreplace start: [$RV[Get Number]]

00822 5 RVreplace end: [686]

00822 5 [Transfer Call] Announced Transfer to 686 (Generate)

00842 5 tapic lineGenerateDigits(66014,!) => 0

01634 5 tapie generate LINEGENERATETERM_DONE

02555 5 LsXferStart EV_TAPI_GENERATE

03566 5 LsXferPlayVts EV_HOOKFLASHFINISHED

03586 5 tapic lineGenerateDigits(66014,686) => 0

04027 5 tapie generate LINEGENERATETERM_DONE

05008 5 LsXferPlayVts EV_TAPI_GENERATE

05008 5 fn PlaySoundStartNumbers TsfrCallFrom.wav, TsfrAskAccept.wav, , Digits

05018 5 twcal PlaySayNumber D:\VoiceGuide\system\voicedlgc\TsfrCallFrom.wav, D:\VoiceGuide\system\voicedlgc\TsfrAskAccept.wav, , , 1

05048 5 PlaySoundStartNumbers ok

05769 5 tapie monitordigits 49 2

05779 5 LsXferPlayAnn [1]

05830 5 PlaySoundStop ok

06751 5 LsXferPlayAnn EV_PLAY_FINISHED

06751 5 LsXferPlayAnn EV_TAPI_GENERATE

07762 5 LsXferPlayAnn EV_TIMEOUT_HANGUP

07762 5 PlaySoundStop ok

07772 5 HangupCall called from []

07772 5 Hanging up call...

07782 5 PlaySoundStop ok

07792 5 fnHangupCall end

07903 5 tapie linedevstate 2048 0 0

07903 5 tapie callstate IDLE 66014 0 0

07913 5 WorkingMode@Idle=

07923 5 set EV_TIMEOUT_TIMETOREINITLINE 2

07923 5 tapi Reply 65946 0

08904 5 LsAwaitingCalls EV_TIMEOUT_TIMETOREINITLINE

08904 5 ReinitTelephony due to IDLE start

08914 5 tapic lineDeallocateCall(MainCall:66014) 0

09144 5 lineOpen(5) => 0

09144 5 Waiting for a call...

09154 5 lineOpen(5)LineHandle=65929

[SupportTeam]

It looks like about 1.5 seconds after VoiceGuide playing "686" there is a DTMF tone "1" being played on the line... which VoiceGuide can hear and as DTMF "1" is used to indicate call acceptance then VoiceGuide thinks recipient of call has accepted the call so VoiceGuide hangs up...

 

What PBX are you using?

 

When you do a transfer yourself manually can you hear your PBX sending any tones?

 

trace shows:

 

VoiceGuide Plays "686"

 

03586 5 tapic lineGenerateDigits(66014,686) => 0

04027 5 tapie generate LINEGENERATETERM_DONE

 

Starts playing "will you accept the call?"

 

05008 5 fn PlaySoundStartNumbers TsfrCallFrom.wav, TsfrAskAccept.wav, , Digits

 

VoiceGuide hears DTMF tone 1 being played on the line:

 

05769 5 tapie monitordigits 49 2

05779 5 LsXferPlayAnn [1]

[Guest rico]

Thanks for the quick reply. I am using Panasonic TD1232 pabx. Actually the pabx is sneding feedback tone regarding the status of the transfer, i.e. 1 for ringing, 2 for busy, 3 invalid extension, 5 for answer, etc...By the way how can i track this feedback status? It seems the inband signalling is not working here. I enable inband but I can see only data when the call is answered.

[SupportTeam]

pabx is sending feedback tone regarding the status of the transfer, i.e. 1 for ringing, 2 for busy, 3 invalid extension, 5 for answer, etc

 

Well this confirms what we are seeing here - PBX is sending DTMF "1" when the destination extension starts ringing - and VoiceGuide takes this to mean that the recipient of transfer has pressed "1" to indicate that "Call has been accepted"...

 

The way that VoiceGuide's Announced Transfer works right now is that "1" is taken as "call is accepted" and anything else is taken to indicate that the call is declined - so right now in our case if the PBX sends anything else other then "1" then VoiceGuide will go down the "Fail" path...

 

You cannot at this stage change how VoiceGuide will react when it hears different DTMF tones whilst doing an Announced Transfer...

 

 

The current version of VoiceGuide does not store in the log file what was pressed - but we've just added that feature in and it will be available in v4.9.1 - you will be able to access it in the script using the standard Result Variable format: $RV[module title]

 

 

 

As far as Inband signaling is concerned - the DTMF tones get sent by PBX after call is answered, but before the caller is connected to the recipient...

[Guest rico]

Okay I got your point. Any idea when 4.9.1 will be released?

 

Actually my pbx sends the status tone before sending the ringback tone or busy tone. When the call is pickup, it send status tone again for the answer tone and then that the time it makes the connection. When the other end disconnect, it send again disconnect tone before disconnecting the line. If I can capture this status, I can use the evaluate module for different path.

 

Secondly, is a way for the system to ignore the inband signal variable? I have this trace error:

36115 5 [FollowOnID] Evaluate $RV[inband_Ext]

36165 5 RVreplace start: [$RV[inband_Ext]]

36175 5 RVreplace end: [$RV[inband_Ext]]

36175 5 .Eval($RV[inband_Ext])

36185 5 Error: 1032

36185 5 Eval Expr result:[$RV[inband_Ext]]

36195 5 RVreplace start: [{False}[Transfer Call]{True}[Voicemail Box $RV[inband_Ext]]]

36195 5 HangupCall called from [Run module 2804]

36206 5 Hanging up call...

The system is supposed to go to false path since there is no inband signal detected but instead I have this error 1032.

 

What parameter in the vg.ini to adjust in order to shorten the inband waiting/detection time? The wave welcome file is not play until detection time expire (hence you can feel the long pause or silence).

[SupportTeam]

Usually when the PBX is configured to send inband signaling it will send it all the time,

if you are finding that sometimes this is not the case in your situation the only way to check whether or not a Result Variable is defined at this stage is to use an Evaluate Expression module to perform a following evaluation:

 

Cstr("$RV[inband_Ext]") = "$R" + "V[inband_Ext]"

 

if outcome is True then the Result Variable is not defined,

if outcome is False then the Result Variable is defined and was replaced by some value.

 

I know this is not a very clean way of ascertaining whether or not a Result Variable is defined. We are going to force replacement of undefined Result Variable with either "0", or "Undefined" or an empty string (ie: "") in an upcoming version of VoiceGuide.

 

 

Inband detection will be done if an "Inband definition file" is specified. VoiceGuide will wait up to 5 seconds to receive the inband signaling, and will finish reading it in if no signal arrived for half a second after some other signals have arrived. This cannot be changed by VG.INI at this stage.

Are you finding that your PBX sometimes sends Inband Signaling and sometimes it does not?

[Guest rico]

Actually I observerd that my pbx send inband signal when an extension call the voicemail port or the extension call forward to the voicemail port. When a CO call (outside) is transfer or intercept by voicemail port, it will not send inbandly the caller port/ext since this is an outside call. I think a callerID will be send instead if I subscribed to callerID and install in the pbx the callerID module.

 

The second scenario is when my voicemail port make an extension call or transfer, the extension status is feedback by the pbx via dtmf tone before sending the ringback/busy tone to the voicemail port, i.e. 1 for ringing, 2 for busy, 3 for invalid...etc.

 

I also notice that in the announced transfer, VG will play immediately the TsfrCallFrom.wav, TsfrAskAccept.wav even though I have not yet lift the ringing phone. If I grap the phone ASAP, sometimes I can here these messages in the middle already when in fact they should only be played once I lift the phone.

[SupportTeam]

Actually I observerd that my pbx send inband signal when an extension call the voicemail port or the extension call forward to the voicemail port. When a CO call (outside) is transfer or intercept by voicemail port, it will not send inbandly the caller port/ext since this is an outside call. I think a callerID will be send instead if I subscribed to callerID and install in the pbx the callerID module.

 

OK, the above is what is expected when 'Inband Signalling' is enabled in VoiceGuide - tones are sent to the device that answers the call when the call is answered, and after the tones are sent the caller and the 'answerer' are connected. The received tones are then matched against possible templates and once a template match is found the template definition is used to extract the information from the tones etc...

 

 

The second scenario is when my voicemail port make an extension call or transfer, the extension status is feedback by the pbx via dtmf tone before sending the ringback/busy tone to the voicemail port, i.e. 1 for ringing, 2 for busy, 3 for invalid...etc.

 

The above 'transfer result feedback tones' that your PBX sends would not be interpreted by VoiceGuide's Inband Signalling detection - the incoming call has already been connected- so VoiceGuide is no longer listening for 'Inband Signalling'. These tones can of course by used to select which paths the script itself will follow... - and as we have already discussed, your PBXs choice of "1 for ringing" fools VoiceGuide into thinking that call has been accepted.

As I mentioned v4.9.1 will have some changes which will allow you to define paths in the Call Transfer module to allow you to define how VoiceGuide should react when it hears various tones..

 

 

I also notice that in the announced transfer, VG will play immediately the TsfrCallFrom.wav, TsfrAskAccept.wav even though I have not yet lift the ringing phone. If I grap the phone ASAP, sometimes I can here these messages in the middle already when in fact they should only be played once I lift the phone.

 

At this stage when doing a call transfer VoiceGuide cannot tell when the destination extension has been picked up (like it does when an outbound call is performed), so for announced transfers the messages need to play immediately after finishing dialing the extension.