VoiceGuide IVR Software Main Page
Jump to content

Test Call Not Working

Recommended Posts

Dears :

I had installed the last updated version from both HMP and Voiceguide downloaded from your great website on Windows server 2016

I had disabled the firewall over Windows application

Sip phone is installed on win7 PC on same internal network of voice guide server

But always , call open and disconnected directly and some time call answered but I can't here any voice

 

Attached wireshark trace and vG logs , your support is highly apprchiated

 

 

VG.rar

Share this post


Link to post

ktTel trace shows that HMP errors after answering an incoming call:

232 194906.060  6152   3   1 fn    AnswerCall 8000001 (sXMLOptions=[])
233 194906.061  5988               cmdq  AnswerCall_Default cmdq_idx=7
234 194906.064  5988   3   1       adjust_volume default call
235 194906.069  1300               extension - idx=1
236 194906.071  5988   3   1 ev    GCEV_EXTENSION hmp
237 194906.071  5988   3   1       zStore_GC_PARM_DATA idx=1, set_ID=12303 parm_ID=1 value_size=4
238 194906.071  5988   3   1       GCEV_EXTENSION IPSET_IPPROTOCOL_STATE
239 194906.071  5988   3   1       GCEV_EXTENSION completed
240 194906.074  5988   3   1 ev    GCEV_TASKFAIL crn=8000001
241 194906.090  5988               GCEV_TASKFAIL ResultInfo: gcValue=137(0x89|EGC_CCLIBSPECIFIC|cclib specific - a catchall) gcMsg=[CCLIB specific] ccLibId=8 ccLibName=[GC_H3R_LIB] ccValue=[0x6||] ccMsg=[IPERR_INTERNAL - see rtf log] additionalinfo=[]
242 194906.090  5988   3   1 r     Dialogic  GCEV_TASKFAIL 2049 (0 137 6 NOADVICE CCLIB specific IPERR_INTERNAL - see rtf log)
243 194906.091  5988   3   1 ERROR GCEV_TASKFAIL source:unknown
244 194906.123  6152         fn    TsReset(sDev1Name=iptB1T1, sDev1Type=, sDev2Name=, sDev2Type=, sDisconnectionType=MATCH_

 

and the call is then ended.

WireShark trace shows:

image.thumb.png.6ff963a9479c3ff39324e3e1e74514ab.png

 

Looks like MicroSIP at 192.168.127.30 is making a call to 192.168.127.61 (VoiceGuide/HMP), and HMP accepts the call - answering OK. MicroSIP has received the OK as we can also see the "ACK" from MicroSIP.

But very soon after that we see an IP level ICMP message from the MicroSIP machine: 192.168.127.30 to 192.168.127.61 saying that a "destination port is unreachable"... VoiceGuide/HMP ends the call (sending BYE) immediately after receiving that ICMP message.

Have you configured the firewall on the MicroSIP machine (192.168.127.30) to allow incoming RTP packets from VoiceGuide/HMP ? Maybe temporarily try disabling the firewall on the 192.168.127.30 machine and see if this lets the VoIP calls continue.

Edited by SupportTeam

Share this post


Link to post

Looks like you have RDP running between 192.168.127.30 and 192.168.127.61 as well.

Is it possible during this initial call testing to stop using RDP and any other applications that could use the network on either the 192.168.127.30 and 192.168.127.61 machines?

Would be good to limit any other network traffic sent to/from either of those machines, so that WireShark traffic shows pretty much only the VoIP traffic on those machines, and there is no chance of port conflicts between VoIP apps and other apps.

Share this post


Link to post

Please also see this:

The way HMP hung up the call here can be caused by some other program using an IP port that HMP needs, or blocking HMP from opening the port.

Default port on which HMP wants to accept incoming RTP traffic is 49152 (and subsequent calls use higher numbered RTP ports from there). If HMP cannot open that port for RTP then HMP will hang up in a similar way to what we are seeing here.

AntiVirus software could be one reason. if you have anti-virus software on the system the please disable it, restart Windows, and then test incoming calls again.

You can probably do a port scan to see if any other software is using that 49152 port. If it is, then you will need to disable that other software and restart Windows. Or you can just kill that process and test incoming call straight away.

In general, running HMP+VoiceGuide (and WireShark) on an otherwise new clean Windows install would be best.

 

If you still have problems after checking the ports and restarting Windows etc then please follow the below instructions to get more information in the Dialogic RTF LOG tracing :

1. Stop the VoiceGuide service.
2. Stop the Dialogic service.

3. Make the hidden directory C:\ProgramData visible.
4. Go to C:\ProgramData\Dialogic\HMP\cfg
( for older versions of windows go to C:\Program Files\Dialogic\cfg )

5. Backup existing RtfConfigWin.xml,
6. Replace it with attached RtfConfigWin.xml (if it is .ZIPed then unzip it first)
7. Shutdown and restart Windows.

8. Ensure Dialogic and VoiceGuide services are fully started.
9. Place a call into the system.
10. .ZIP up Dialogic RTF logs in Dialogic's \log\ subdirectory.
11. Please post the .ZIPed up logs here.

 

RtfConfigWin.xml

Click link above to download the RtfConfigWin file.

Share this post


Link to post

Dears :

Thanks for your reply , The setup already is fresh 

I had Installed Windows server 2016 + HMP + WireShark + Voice Guide on maching 192.168.127.61 (Voice Guide Server) , There is No Antivirus and already I ad disabled the Firewall on both two machines
192.168.127.61 and 192.168.127.30

I had retest after closing the RDP but unfounatelly with no change still calls disconnected directly.

I had scanned ports useing netstat -ab but 49152 not used by any other application

I had replaced the config file you had sent to me and Placed call from Android SIP phone  , attached the wireshark and dialogic logs as agreed

I note that when I am calling from android SIP phone , some times calls disconnected directly and some time the call answered but without hearing any voice file

Attached is the required logs

first two calls disconnected directly after 1 sec

the third call connected but no voice files has been heard, I disconnected the call after 14 secs nearlly
 

Trace.rar

Share this post


Link to post

Can you please try with MicroSIP instead of Android SIP phone. Android based SIP softphone will be trying to set up the connection using voice coders that are not supported in the evaluation version of Dialogic HMP. So calls could be getting declined because of that.

MicroSIP will include the basic G.711 codec (both ULaw and ALaw) - which is supported. Actually for now it's best for you to just configure MicroSIP to only enable the G.711 ULaw coder, and try test calls with only ULAw enabled

MicroSIP's Settings page:

image.png.8dbfcc9059392956195b46e84448fe37.png

Share this post


Link to post

Dialogic's RTF log traces supplied show the same error that occurs when HMP is unable to open the port used for incoming RTP traffic: port 49152

RTF log shows:

03/09/2023 15:56:54.227   4284        4596 libipm_ipvsc            INTF         CIPVscChannel         ipmB1C1    <=== ::OnStartMediaSession( MsgExpect=1 MsgRc'ed=1)
03/09/2023 15:56:54.227   4284        4596 libipm_ipvsc            ERR1         CIPVscChannel         ipmB1C1    ---  ::OnStartMediaSession: ch=ipmB1C1 ErrorCode=0x7 -Invalid parameter value., PrevError=0x0
03/09/2023 15:56:54.228   4284        4596 libipm_ipvsc            ERR1         CIPVscChannel         ipmB1C1    ---  ConvertDM3ResultToR4Error: RESULT_COMPONENT_ERROR             error code: 0x7
03/09/2023 15:56:54.228   4284        4596 libipm_ipvsc            ERR1         CIPVscChannel         ipmB1C1    ---  ConvertDM3ResultToR4Error: RESULT_COMPONENT_ERROR             converted error code: 0x2
03/09/2023 15:56:54.228   4284        4596 libipm_ipvsc            INFO         CIPMediaDevice        ipmB1C1    ---  Enter ErrorCompleted ErrorCode=0x2 Reason=0
03/09/2023 15:56:54.228   4284        4596 libipm_ipvsc            INTF         CIPVscChannel         ipmB1C1    =<>= ::OnStartMediaSession()
03/09/2023 15:56:54.228   4284        5844 libgcipm.dll            INTF         gcipm                           <==== IPM_hipri_Handler(0x836DAE0)
03/09/2023 15:56:54.228   4284        5844 libgcipm.dll            INTF         gcipm                           ==<== IPM_hipri_Handler() rc=1
03/09/2023 15:56:54.228   4284         876 libgcipm.dll            INTF         gcipm                 ipmB1C1   <==== IPMHandler(0x836DAE0)
03/09/2023 15:56:54.228   4284         876 libgcipm.dll            INFO         gcipm                 ipmB1C1         Event=0x901e
03/09/2023 15:56:54.228   4284         876 libgcipm.dll            INFO         gcipm                 ipmB1C1         IPMHandler: Event = IPMEV_ERROR
03/09/2023 15:56:54.228   4284         876 libgcipm.dll            INFO         gcipm                 ipmB1C1         IPMHandler() before EnterCriticalSection
03/09/2023 15:56:54.228   4284         876 libgcipm.dll            INFO         gcipm                 ipmB1C1         IPMHandler() before LeaveCriticalSection
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MGR     DEBG         sm_callcontrol.:2729  !     0 ! >> ProcessIPMEvent: mediaDevH 4,evt 0x901e,len 0
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediastate.cpp:1218   !     1 ! >> MediaState::ipmEventHandler: IPMEV_ERROR evType 0x901e, datap 0x836daec in ST_TX_START_2FDX
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediaipml.cpp:2675    !     1 ! Mediaipml::isEventBelongToMedia : This is the number of Media Opertion 2 :
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediastate.cpp:1076   !     1 ! >> mediaEventHandler: ev EV_ERROR st ST_TX_START_2FDX duplex mode 1
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediastate.cpp:2636   !     1 ! >> MediaState::evError:Err 2 Invalid parameter,ch ipmB1C1
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediaipml.cpp:3146    !     1 ! >> Mediaipml::unreserveLBRCodecs(channelType = 0)
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_LD      DEBG         ld.cpp:1013           !     1 ! >> LD_Media::mediaReportTaskFail:resultError 6
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:90    !     1 ! >> putEvent with (sharon -> GC) type: (0x801) GCEV_TASKFAIL device 3 reason 6 database 0x7f8a750
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:3335  !     1 ! >>  encodeDefaultEvent : srlLDev=3, crn=1, msgType=0x801, ipReason=6
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:4731  !     0 ! >> encodeSIPIPCMsgInfo
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:2809  !     1 ! >> encodeMsgInfo(ppParm=0x1384f70c, pSipHeaderMgr=0x6eb7fa8, pDb=0x7f8a750)
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:573   !     1 ! << pkBuildGCEvent : [0]
03/09/2023 15:56:54.228   4284         876 gc                      INFO         gcep                  iptB1T1   <---- gc_ep_ProcessGCEvent() - event:0x801h(GCEV_TASKFAIL) on ccliblinedev:3, crn:0x1h
03/09/2023 15:56:54.228   4284         876 gc                      DEBG         gccme                            ---  gc_cme_GCCallStateTransitionEvt() - event:GCEV_TASKFAIL(0x801h) is NOT a transition event.
03/09/2023 15:56:54.228   4284         876 gc                      WARN         gcams_event_handler              ---  gc_alarmdb_PutEvent() -  Post event:0x801(GCEV_TASKFAIL) on linedev:3
03/09/2023 15:56:54.228   4284         876 gc                      APPL         gcep                  iptB1T1    ---  GC event:0x801h(GCEV_TASKFAIL) posted on linedev:3, crn:0x1h
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_PACKER  DEBG         packer_main.cpp:484   !     1 ! << putEvent :[0] exit
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_LD      DEBG         ld.cpp:1025           !     1 ! << LD_Media::mediaReportTaskFail: [0]
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediastate.cpp:2665   !     1 ! << MediaState::evError: [0]
03/09/2023 15:56:54.228   4284         876 gc_h3r       SH_MEDIA   DEBG         mediastate.cpp:1149   !     1 ! << mediaEventHandler: ev EV_ERROR st ST_TX_START_2FDX: [0]
03/09/2023 15:56:54.228   4284         876 gc_h3r                  ERR1         mediastate.cpp:1318   !     1 ! << MediaState::ipmEventHandler :IPMEV_ERROR received from media

 

Which matches this Dialogic technical note:

https://www.dialogic.com/support/helpweb/helpweb.aspx/2849/hmp_is_unable_to_answer_a_call_with_gc_answercall_returning_a_gcev_taskfail/pm_hmp_win

Screenshot:

image.thumb.png.fae9fd6111a9f34029b490b761302065.png

image.thumb.png.975ebb1a854a4659452a7aaa8eb80bca.png

Share this post


Link to post

Is the firewall totally disabled system-wide or just for the VoiceGuide service and for the Dialogic service?

Have you tried adding an explicit rule to the firewall that allows local programs to open UDP ports 49152-49951 and receive traffic on those ports?

Is this server part of a Domain? Are there any group policies etc. which could be affecting things here?

Maybe also try scanning the open/listened ports just before a test call is placed into the system?

 

Also, just in case there is port clash with something else:

Attaching below the .fcd and .config files that configure Dialogic HMP to use UDP ports starting at 19152 (instead of 49152) for the incoming RTP streams.

These files work for the HMP 1 port evaluation license - which looks like what is currently used by HMP on this system.

To use these files:

1. Stop VoiceGuide and Dialogic services.

2. Unzip the attached .zip file and place the two files in that archive in folder C:\ProgramData\Dialogic\HMP\data (backup files already there first).

3. Restart Windows.

fcd_for_eval_lic_with_rtp_port_19152.zip

Share this post


Link to post

Dears:

 

Thanks for your reply. 

1- Already firewall on both machines is completely disabled.

2- I had Configured SIP trunk as you mentioned in your last reply to support m-law codec only.

3- I had replaced the config file and fcd file with the one you had sent and restart the server.

4- I had formatted the microsip machine and installed microsip only and disabled firewall and no anti-virus has been installed on the Micro sip machine

5- I had connected both Microsip machine (192.168.127.8) and VG server (192.168.127.61) back to back in completely separate network , there is no firewall there is no routers , there is even any switch, both machines connected back to back through their network cards directly.

I had made 3 calls, all are received to VG server and calls answered directly and playing wav file but I can/t hear any prompt on microsip machine, Attached logs of the calls , your support is highly appreciated.

 

 

 

 

VG 12-03-2023.rar

Share this post


Link to post

ktTel and 0312_1332_vgEngine traces show that 4 calls were made on 12th March:

185 133259.649   556   3   1 ev    GCEV_OFFERED crn=8000001 ()
398 133611.410   556   3   1 ev    GCEV_OFFERED crn=8000001 ()
610 133711.827   556   3   1 ev    GCEV_OFFERED crn=8000001 ()
822 133834.357   556   3   1 ev    GCEV_OFFERED crn=8000001 ()

The VoiceGuide traces look fine, showing that VoiceGuide did not receive any errors from HMP when instructing HMP to play out the sound files PayGetId.wav and TimeoutThankyou.wav. HMP reported that it played put the sound files and the play completion events were issued by HMP at expected times.

Dialogic's RTF log also looks normal.
 

03/12/2023 13:38:34.401   6496         556 dm3voice                APPL         libdxxdm3             dxxxB1C1  <:::: dx_playiottdata(0x2, 0xb08cdd8, 0x0, 0xaf8e7bc, 0x8000)
...
03/12/2023 13:38:34.401   6496         556 dm3voice                APPL         libdxxdm3             dxxxB1C1  ::::> dx_playiottdata returns 0
...
03/12/2023 13:38:42.865   6496        6656 dm3voice                APPL         VoiceDevice           dxxxB1C1  ::::> SendEvent TDX_PLAY

 

The WireShark trace captures only one call. Looking at the "From:" header it looks like it was the call made at 13:38:34 (tag=f42cb2e6206c41eaba69ba9cb7a165bc)

image.thumb.png.09a28221f258efbfc10a967373deed1b.png

 

The SIP call setup looks fine. It looks like HMP is now using UDP port 19152 for RTP traffic. And we then see the call being ended by the VoiceGuide side 35 seconds later - in line with VoiceGuide timing out after playing the PayGetId.wav and TimeoutThankyou.wav files in the demo Credit Card payment script.

 

The puzzling thing is that no RTP packets can be seen in WireShark from either side after the call is answered.

No RTP voice data can be seen sent from the MicroSIP machine. And no RTP voice data can be seen sent from the VoiceGuide machine...

 

Looking into Dialogic's RTFLOG we see repeated references that its' "Local RTP" IP address is actually 169.254.72.79 ...

eg:

03/12/2023 13:38:34.394   6496        5508 gc_h3r       SH_MEDIA   DEBG         mediaipml.cpp:4365    !     1 ! LOCAL_RTP  169.254.72.79-19152 

where did this IP address of 169.254.72.79 come from?

Obviously there is some configuration on this machine which causes HMP to sometimes think that its' local IP address is 169.254.72.79 - and this probably has something to do with RTP packets not being sent out from the HMP/VoiceGuide machine. Maybe a similar issue is also affecting the MicroSIP machine.

 

Was the VoiceGuide server or the MicroSIP machine ever part of a Domain? 

Was the VoiceGuide server or the MicroSIP machine ever set up to use Active Directory or Directory Services to authenticate user logins?

When Windows was installed on these servers was it installed from original .ISO distribution from Microsoft? Or from some other custom configured installer?

 

At this stage we would recommend that these machines have their hard disk fully reformatted and Windows is installed on these machines from Microsoft's original .ISO sources.

Then install just HMP+VoiceGuide+WireShark on one machine, and MicroSIP on the other and connect the two machines to its own fully separate network using a separate simple hub/switch or back to back as before.

And then test the calls using those clean installations before allowing any other configurations to be made to those systems.

 

Share this post


Link to post

Dears:

Thanks for your reply. 

it's working now properly, and I can hear the prompt normally.

 If I have 120 incoming line i need to run main script on all lines then based on the DID number, I need to change the running script to other Vgs script.

I need your support to change the script of the call based on DID number (Dialed Number) , Is there any block in VG diagram allow me to check the DID number and change the running script based on this number?

Thanks for your support and effort

Share this post


Link to post

The topic below outlines how to set up the routing script that will send calls made to different DIDs to their own respective call-flows:

https://www.voiceguide.com/forums/topic/13176-dnis-routing-run-different-script-based-on-number-dialed/

Usually a single 'Evaluate Expression' block that checks the value of the $RV_DNIS variable is sufficient.

You can use a "Run VBScript" / "Run JavaScript" module for more complex decision making.

 

More information on other variables which let you further customize call handling is here:

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

 

Share this post


Link to post

After creating the routing script you will need to set that routing script to be the starting script on each of the channels.

The scripts that are used on each channel when answering incoming calls are set in VoiceGuide's Config.xml file.

Config.xml file is located in VoiceGuide's \conf\ subdirectory.

After updating the Config.xml file the VoiceGuide service needs to be restarted in order for the new Config.xml to be read in.

Please see the "Configuring VoiceGuide" section of the VoIP Installation guide:

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

Or see the "Setting Which Callflow Scripts Are Used" section on the Script Design Introduction page:  https://www.voiceguide.com/vghelp/source/html/scriptintro.htm

 

 

Note that you can also start running the VoiceGuide script to handle the incoming call without answering the call.

Please see: https://www.voiceguide.com/vghelp/source/html/call_start.htm

This allows you to perform any sort of processing on the call before answering it. This approach also gives you the option of ending the call without ever answering it.

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
×