VoiceGuide IVR Software Main Page
Jump to content

Voiceguide 7.4 + HMP Accepting but not answering the call

Recommended Posts

Hi Support Team, 

We are having a problem in one site we have voiceguide + hmp running.

It is Voiceguide 7.4 + HMP on Windows Server 2008R2.

Calling from a softphone works perfectly, bug when calling from a fixed phone, through a SIP trunk created in Avaya PBX the calls get accepted (I can see the call arriving using the Line Status Monitor) but never gets answered.

Currently my script has "StartWithoutAnswer=1" but I tested changed this value to 0 and the same happens. 

Also, I tested with voiceguide 7.5, same results.

I'm attaching to this post wireshark traces, voiceguide log and HMP Rtf logs.

Could you please take a look and let me know?

hmp_rtflog.txt

voiceguide_log.txt

wireshark_trace.pcapng

Share this post


Link to post

The attached vgEngine trace shows 3 incoming calls:

145647.817  19   3   1 ev    CallState GCEV_OFFERED, crn=8000001, iEvent=0 ,2,0,8, s1:+4075663545@wdw.disney.com|, s2:1055@wdw.disney.com, s3:]. build_date: 28-Aug-14 19:03:09.56
145700.377  19   7   2 ev    CallState GCEV_OFFERED, crn=8000002, iEvent=0 ,2,0,8, s1:+63539@wdw.disney.com|, s2:1096@wdw.disney.com, s3:]. build_date: 28-Aug-14 19:03:09.56
145739.854  19  10   3 ev    CallState GCEV_OFFERED, crn=8000003, iEvent=0 ,2,0,8, s1:PhonerLite@10.61.69.163|, s2:10.61.131.67, s3:]. build_date: 28-Aug-14 19:03:09.56

 

While the WireShark trace does not show the arrival of the calls made from 4075663545 and 63539 numbers, so we cannot see what SIP packets were exchanged at time when those calls arrived on system.

WireShark trace shows the call from PhonerLite. The PhonerLite call arrives at 132 seconds mark in WireShark trace, so it is puzzling why the WireShark trace did not show any calls made from 4075663545 and 63539, as per the vgEngine trace those calls arrived 52 seconds and 39 seconds earlier respectively.

vgEngine trace shows VoiceGuide tried to answer both calls:

145647.943   7   3   1       q_tel +     cmd_AnswerCall 8000001 [0,0,0,0,0][||||]
145647.943   8   3   1       q_tel run   cmd_AnswerCall 8000001 00:00:00 max:1|00:00:00.0010004

145700.394   7   7   2       q_tel +     cmd_AnswerCall 8000002 [0,0,0,0,0][||||]
145700.394   8   7   2       q_tel run   cmd_AnswerCall 8000002 00:00:00 max:1|00:00:00.0010004

 

and RTF log does not show any protocol or other errors:

12/13/2018 14:56:34.989   6524        4332 gc_h3r                  ERR1         sh_db.cpp:1890        !     4 ! ShDb::setCauseAndReasonFromApp: Can not recognize the protocol
12/13/2018 14:56:34.989   6524        4332 gc_h3r                  ERR1         sh_db.cpp:1890        !     4 ! ShDb::setCauseAndReasonFromApp: Can not recognize the protocol
12/13/2018 14:56:47.815   6524        4332 gc                      ERR1         gc_parmblk_mgr                  ----- CParmBlkMgr::ReleaseCParmBlk(): Could not find GC_PARM_BLKP = 0xe68813d in map, return EGC_INVPARMBLK
12/13/2018 14:57:00.377   6524        4332 gc                      ERR1         gc_parmblk_mgr                  ----- CParmBlkMgr::ReleaseCParmBlk(): Could not find GC_PARM_BLKP = 0xe68813d in map, return EGC_INVPARMBLK
12/13/2018 14:57:39.854   6524        4332 gc                      ERR1         gc_parmblk_mgr                  ----- CParmBlkMgr::ReleaseCParmBlk(): Could not find GC_PARM_BLKP = 0xe68813d in map, return EGC_INVPARMBLK
12/13/2018 14:57:39.967   6524        4332 dm3low                  EXCE         BadParameterException at LibCspDm3.cpp:292 (0x6)
12/13/2018 14:57:39.967   6524        4332 dm3voice                ERR1         libdxxdm3             dxxxB1C3  ::::> dx_setevtmsk returns -1

 

Next step would be to try to run WireShark trace again to capture the SIP exchanges for calls arriving over that SIP trunk.

Are the SIP trunk calls perhaps arriving on another network interface that was not monitored in WireShark? All SIP communications should be arriving over same connection. There should be only one network connection used for SIP communications into HMP.

Please also post VoiceGuide's ktTel trace in future. ktTel trace shows what is happening on VoiceGuide's lower layers.

 

 

ws.png

Share this post


Link to post

Hello, 

Find attached the logs files:

  • vgEngine
  • Wireshark trace
  • HMP RTF log
  • ktTel log

This time, in the wireshark trace include all the network traffic (I have not applied sip || rtp filter this time).

There is only one network interface on the computer and is correctly configured in HMP.

I'm trying to get a wireshark trace taken from the PBX. I'll upload here as soon as I get it.

Thanks

20181214.zip

Share this post


Link to post

WireShark Trace shows HMP was sending OK response advising it wants to answer the call, but the PBX never sent back an acknowledgement (ACK) that it received the OK.

This is why HMP can be seen re-sending OK multiple times. HMP is waiting for an ACK from PBX before it will consider call as being acknowledged as answered and the proceed with call.

WireShark screenshot attached.

You should confirm whether the Avaya is sending out an ACK or not. This can be done by capturing a trace of network traffic at Avaya's network interface.

If Avaya is sending out an ACK then it looks like you have a network connectivity issue.

Here is a one article that describes what you could be experiencing: https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/

ws_onecall.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
×