VoiceGuide IVR Software Main Page
Jump to content

How could I make "Dial and Conference" work

Recommended Posts

I was trying to transfer call to other system and before handover call to the other system, I need to run another script to hand over caller information by using 4 digits DTMF.

Could you please let me how could I using Transfer Call module to make it happen??

Share this post


Link to post

You can use the "Dial and Conference - Monitored" transfer type.

On that transfer module's Properties pages in the Script Designer go to the "Announce Message" tab and set the "Sound file to play to recipient" to be the DTMF string to play. If the "Sound file to play.." is a series of digits instead of a filename then the DTMF tones will be played. This is how it works in every place a sound file can be  played.

You can use a Result Variable to hold the value of that 4 digit DTMF string, and just specify that Result Variable as the "Sound file to play to recipient".

More information here:

https://www.voiceguide.com/vghelp/source/html/modxfer.htm

https://www.voiceguide.com/vghelp/source/html/resultvariables.htm

Share this post


Link to post

I got disconnect as soon as call went into Transfer Call module with Dial and Conference - Monitored selected.

which log file I need to provide?

Share this post


Link to post

Please .ZIP up the latest 'vgEngine' and 'ktTel' traces which are in VoiceGuide's log subdirectory.

Please .ZIP up and post entire files, not just an excerpt.

Share this post


Link to post

The outgoing leg of the call got immediately disconnected.

Are you able to make outgoing calls from this system? Have you tried just loading an outgoing call using the Dialer to confirm that outgoing calls work on this system?

WireShark trace might show more information here.

Please try placing an outgoing call using the Dialer and do a WireShark capture of that outgoing call attempt, and post the .pcapng save file from WireShark here.

421 100404.201 14208   3   1 fn    LineMakeCall(iLineId=3, iCallRequestId=0 (ignored), strNumberToCall=[913019626359@10.92.39.22], callprog=CONNECT_IMMEDIATELY<rtp-audio><rtp-audio-1>G711U</rtp-audio-1><rtp-audio-2>G711A</rtp-audio-2><rtp-audio-3>G729</rtp-audio-3></rtp-audio>, timeout=60, params:0,8,cidtosend=[12409973549@10.92.39.22],opt=[<calltype>DialAndConf</calltype><CallerId>12409973549@10.92.39.22</CallerId>])

...
445 100404.214  5112   3   1       gc_MakeCall [913019626359@10.92.39.22] call (HMP)
446 100404.214  5112   3   1       gc_MakeCall ok. crnx=8000001
447 100404.215  5112   3   1       TelDriver_LineMakeCall ret=0 crnx=8000001
448 100404.215  5112   3   1 r     generic ktTel_Completion|10000  Completion_MakeCall|0  134217729 (134217729|0|0|913019626359@10.92.39.22|12409973549@10.92.39.22|<result>ok</result><crn>134217729</crn><crnx>8000001</crnx>) this=075CFFCC pTelProxy_Global=0782ABC8
449 100404.216  5112   3   1 ev    GCEV_DIALING crn=8000001 crn_lastMakeCall=8000001
450 100404.216  5112   3   1 r     CallState(3, 8000001, 0, GCEV_DIALING, 16, 0, 16, , , )
451 100404.216 16152               extension - idx=23
452 100404.218  5112   3   1 ev    GCEV_DISCONNECTED crn=8000001 q: 2/3
453 100404.218  5112   3   1 r     CallState(3, 8000001, 0, GCEV_DISCONNECTED, 16384, 1931495192, 64, �Íh䈧    <, , ) 

Share this post


Link to post

Yes, I have no issue for outgoing call.

I could use PBX Hookflash Transfer --Blind to the same outgoing number without any issue. It should be in the log too.

Share this post


Link to post

Can you please make an outgoing call from this system. After the outgoing call is made please .ZIP up the latest 'vgEngine' and 'ktTel' traces which are in VoiceGuide's log subdirectory and post them here.

Please .ZIP up and post entire 'vgEngine' and 'ktTel' trace files, not just an excerpt.

Also:

Please .ZIP up Dialogic RTF logs in Dialogic's \log\ subdirectory - usually "C:\Program Files (x86)\Dialogic\HMP\log" and post the .ZIP file here.

Share this post


Link to post

The outgoing call should be made using the Dialer. A 'Hookflash Transfer' (which on SIP systems results in a "REFER" transfer) does not result in an outgoing call being placed.

Share this post


Link to post

Attached traces do not show an outgoing call attempt using the Dialer.

The outgoing call should be made using the Dialer.

A 'Hookflash Transfer' (which on SIP systems results in a "REFER" transfer) does not result in an outgoing call being placed.

 

Share this post


Link to post

Do I need to change config file for Dialer?

I did Active  the call list and could find loaded number in report, but no dialing happen yet.

image.png.e0932f5c7f7f31bb69378197a0c53460.png

image.png.c433dda06fa3e1c578509c8737e93885.png

image.png.d4e71083700a00b20494a2653fd1ae39.png

image.png.98e63d15e2c06631e03a8dba22520147.png

Share this post


Link to post

You just need to specify the number to call, and the sound file to play for 'Live Answer". Nothing else needs to be set.

The number to call can be specified like this:

image.png.a205996d45e52a70df45185bbe98b4b2.png

Then press the "Load Phone Numbers" button.

You should see the call attempt in the Line Status Monitor, and in the VoiceGuide log files.

Share this post


Link to post

Trace files shows that the attempted outgoing call request was sent by VoiceGuide to Dialogic HMP, and Dialogic HMP accepted the call request and advised that it was making the outgoing call, and then a few milliseconds later HMP advised that the call has been Disconnected.

The RTF log does not show any errors.

WireShark trace might show more information about the outgoing call, and whether the HMP did issue the SIP INVITE message to 10.92.39.22

Please start a WireShark capture and then try placing an outgoing call using the Dialer and see if you can capture any IP messages of that outgoing call attempt. Then post the .pcapng save file from WireShark here.

 

980 205924.810 17448   3   1       gc_MakeCall [913019626359@10.92.39.22] call (HMP)
981 205924.811 17448   3   1       gc_MakeCall ok. crnx=8000001
...
984 205924.812 17448   3   1 ev    GCEV_LISTEN
985 205924.813 17448   3   1 ev    GCEV_DIALING crn=8000001 crn_lastMakeCall=8000001
...
988 205924.819 17448   3   1 ev    GCEV_DISCONNECTED crn=8000001 q: 2/52

 

Share this post


Link to post

WireShark trace shows that the outgoing call fails as the device at 10.92.39.22 responds with a FORBIDDEN to VoiceGuide's/HMP's INVITE.

You should speak with administrator of whatever that device at 10.92.39.22 is.

Previous traces showed that this 10.92.39.22 device is already sending calls to VoiceGuide that VoiceGuide answers and can REFER transfer, so you now need to have that 10.92.39.22 device configured to accept calls from VoiceGuide/HMP as well.

image.thumb.png.79ecc1777f0086b8d2c6b39b91642a8b.png

image.png.51c1c91064fe4a3c7259fee39f1fe202.png

Edited by SupportTeam
added the screenshot for the INVITE packet

Share this post


Link to post

10.92.39.22 is NEC 9500 PBX.

I could use the same number 26259 in 3CX softphone to dial out OK. It means PBX setup should be OK.

What line configuration need to be setup in PBX side? My NEC engineer always use 3CX to verify line configuration.

Does "Dailout and Conference" and dialer are using the same command to dial out?

so fare only "PBX Hookflash Transfer - Blind" is working. I tried other option in Transfer Call Module and all of them got disconnected when script hit Transfer Call Module. 

 

Share this post


Link to post

If you can do a WireShark capture the SIP messages of the outgoing call from the 3CX softphone then we can compare the two traces and see what he differences are.

Ultimately it's the PBX that is explicitly rejecting the call so the PBX administrator should see what is the cause of the PBX doing what it's doing.

Same formatted INVITE is sent by "Dial and Conference" as by the Dialer. "Dial and Conference" uses the Dialer module to make the outgoing call.

Share this post


Link to post

Perhaps that 3CX softphone is  registering itself with the PBX as one the PBXs extensions, and that's why the PBX is then allowing that 3CX softphone to make outgoing calls through the PBX?

A good softphone to to use for testing is MicroSIP: https://www.microsip.org/

Share this post


Link to post

That softphone is on a different IP address.

Maybe the PBX allows some IP addresses but not others.

The PBX administrator can check the PBX logs and advise.

image.thumb.png.79716a8305d2076d1ea5cedf501f9f9f.png

Share this post


Link to post

Provided trace is from a softphone (MicroSIP) installed on a different machine with a different IP address.

Maybe the PBX allows some IP addresses but not others.

The PBX administrator can check the PBX logs and advise

image.thumb.png.7dde62ecf677505fc6bab1f63fa0d2f0.png

Share this post


Link to post

NEC NTAC supporting fund that 403 error was related to "User Agent Class is blank"

User Agent must be identified by the 3rd party vendor (minimum 3 characters).

image.png.266507a846dce3033c95cc2fc8491be6.png

Share this post


Link to post

Please try loading an outgoing call using the VoiceGuide Dialer and specify this in the "Call Options" text box:

<sip-header>User-Agent: VoiceGuide</sip-header>

Like this:

image.png.272d19354b1c8314b65d42e5b4d1e927.png

 

This should add a 'User-Agent' header to the outgoing SIP INVITE.

Please do a WireShark Capture of the outgoing call as before, and post the .pcapng WireShark capture file here.

More information on specifying SIP headers on outgoing calls can be found here:

https://www.voiceguide.com/vghelp/source/html/dial_voip.htm

Share this post


Link to post

I did use Dialer and add <sip-header>User-Agent</sip-Header> and I still got 403 error.

Could we add User-Agent during registration phase? It looks like MicroSIP or 3CX do provide User-Agent during line registration.

 

DialerUserAgent.pcapng

Share this post


Link to post

Provided .pcapng trace shows that the SIP INVITE message now does contain the User-Agent header.

Looks like the header was specified to use "MSTIVR" instead of "VoiceGuide" as the User-Agent identifier, but either meets the "minimum 3 characters" advice that was provided.

You should ask the PBX administrator why was this call rejected by the PBX, even though it had the User-Agent header included in the INVITE as requested.

 

image.thumb.png.8d95bf37b2639e6a9fa0baae2d241601.png

Share this post


Link to post

PBX vendor is NEC North America point out that User-Agent should be provided during line registration.

image.png.9b183568cba7539213b77adf6dba1684.png

MicroSIP does provide User-Agent information during registration phase.

image.thumb.png.3cbd7de9332048107778c4b3d0d832f9.pngimage.thumb.png.3cbd7de9332048107778c4b3d0d832f9.png

Share this post


Link to post

Please install MicroSIP on the same machine as VoiceGuide. Do not make any changes or set any Account or other settings on MicroSIP.

Then perform this test:

1. Stop VoiceGuide service and the Dialogic HMP service.

2. Start WireShark capture.

3. Without setting MicroSIP to Register with the PBX (ie. do not set any 'Account' settings) just place a place a call from MicroSIP to the PBX.

4. Configure MicroSIP to Register with the PBX (make sure no other softphone anywhere else is using this same registration/account details at the same time). Wait till you can see that the Registration is working in WireShark and again place a call from MicroSIP to the PBX.

5. Post the WireShark .pcapng capture file here.

Share this post


Link to post

Do have the WireShark trace for the "Step 3" of the test:

Quote

3. Without setting MicroSIP to Register with the PBX (ie. do not set any 'Account' settings) just place a place a call from MicroSIP to the PBX.

 

Provided trace is only for the "Step 4" of the test.

We need to see what happens if MicroSIP does NOT register itself. Just sends call to 912409973549@10.92.39.22 without registration.

Share this post


Link to post

The next release of VoiceGuide (v7.4.4) now includes a fix that should resolve the "403 Forbidden" response issue from the NEC 9500 PBX that has been reported in this thread.

Link to the the new v7.4.4 download has been forwarded to user "Harry C". 

VoiceGuide v7.4.4 will be available for general download from our Downloads page in a few days.

Share this post


Link to post

Please try removing the below Call Options entry from the Call Loader's Call Options text box:

<sip-header>User-Agent: MSTIVR</sip-header> 

using the above entry results in a different User-Agent header being sent with the outgoing call then what was used during SIP REGISTER.

In SIP REGISTER the User-Agent is:

User-Agent: VoiceGuide

And by using the above <sip-header> option, the User-Agent on outgoing call's SIP INVITE is:

User-Agent: VoiceGuide,MSTIVR

Removing the <sip-header> option will make the SIP INVITE's User-Agent header same as the SIP REGISTER's User-Agent header.

Share this post


Link to post

Can see now in second call the User-Agent is just "VoiceGuide" and yet the PBX still responds with a 403.

Maybe the PBX needs to be configured to accept a specific User-Agent ?

The PBX administrator should advise why was this call "403 Forbidden" rejected by the PBX...

 

image.thumb.png.009e47366c59a33470e1dbd460cd6837.png

Share this post


Link to post

Version 774  PBX Hookflash Transfer - Blind wasn't working.

If you just review the Wireshark log and it looks OK, but actually caller got disconnected right after  200 OK (BYE).

after switch back to version 773 PBX Hookflash Transfer - Blind was start working again. it means caller did not get disconnected after 200 OK (BYE).

 

VG773.zip

VG774 (2).zip

Share this post


Link to post

The REFER transfers were done in the same way - the only difference is that in v7.7.4 the REFER message included the "User-Agent" header.

The 'User-Agent" header was not present in the REFER issued by v7.7.3.

In both cases the PBX responded with an ACCEPTED - which is a message used to indicate that the transfer succeeded.

You will need to ask the PBX administrator why you experienced their PBX acting differently in these two cases - even after it responded ACCEPTED in both cases.

Also it may be worth noting that the original call was made to a different extension ext 20038 in case of v7.7.3 , and to ext 20036 in case of v7.7.4, so it may be worth confirming that the configuration of both extensions is the same.

 

image.png.87b1f30798ba2979d927d8ba420c7fde.png

 

 

image.png.13b6098a67a11d5849a0af69529c792e.png

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×