Waseem elrashidy Report post Posted 03/08/2023 05:59 PM 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
SupportTeam Report post Posted 03/08/2023 08:55 PM (edited) 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: 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 03/08/2023 10:54 PM by SupportTeam Share this post Link to post
SupportTeam Report post Posted 03/08/2023 10:38 PM 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
SupportTeam Report post Posted 03/09/2023 08:35 AM 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
Waseem elrashidy Report post Posted 03/09/2023 02:02 PM 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
SupportTeam Report post Posted 03/09/2023 08:02 PM 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: Share this post Link to post
SupportTeam Report post Posted 03/10/2023 03:22 AM 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: Share this post Link to post
SupportTeam Report post Posted 03/10/2023 04:53 AM 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
Waseem elrashidy Report post Posted 03/12/2023 11:56 AM 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
SupportTeam Report post Posted 03/13/2023 02:52 AM 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) 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
Waseem elrashidy Report post Posted 03/13/2023 03:15 PM 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
SupportTeam Report post Posted 03/13/2023 09:39 PM 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
SupportTeam Report post Posted 03/13/2023 11:06 PM 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
