VG does not detect Hang-up for Outdial

[iTime]

Hello,

I think this symptom started happening recently; our VG does not detect hang-up anymore when Call out is made. (For Call-in, VG does detect hang-up signal correctly.)

If you see the log, Call-in detects Disconnect signal correctly and hangs up, while Call-out (there are 2 separate call-out events) will not detect the signal even if the user hung up at "GetPasswordForDialOut" module for both calls. VG would disconnect by the module time out.

We think it was fine before, so not really sure what the cause of this is. After we contacted VoIP service provider, we got the following response:

Quote

I reviewed the outbound call below in which I still see the 481 in response to the BYE for disconnect. Upon analyzing the signaling, I noticed that the contact in the invite is specifying the DNS of our voice server as opposed to the client IP address. I see the client IP correctly offered in the registration string.

I suspect this is contributing to the 481 on disconnect for the outbound call. Please offer the client IP in the contact header of the invite and retest.

 

You can see our VoIP reg in VG Config.xml file.

We tried to provide both client (VG Server) and server (VoIP) inside Reg Server/Client elements interchangeably with no different results.

Your help is much appreciated.

Thanks.

<VoIP_Registration>
<Display>DemoIVR</Display>
<Protocol>SIP</Protocol>
<RegServer>ld01-05.fs.fusionconnect.net</RegServer>
<RegClient>7140000000@192.168.100.130</RegClient>
<LocalAlias>7140000000@192.168.100.130</LocalAlias>
<Expires>180</Expires>
</VoIP_Registration>

</VoIP_Registrations>


<VoIP_Authentications>
<VoIP_Authentication>
  <Display>Broadvox</Display>
  <Realm></Realm>
  <Identity></Identity>
  <AuthUsername>7140000000</AuthUsername>
  <AuthPassword>XXXXXXXXXX</AuthPassword>
</VoIP_Authentication>
</VoIP_Authentications>

 

VG_Log_CallIn.zip

VG_Log_CallOut.zip

[SupportTeam]

On the incoming call, the device at 64.190.228.8 sends a BYE message to VoiceGuide (192.168.100.130). 'BYE' is the 'End of Call' message.

VoiceGuide/HMP is not detecting any disconnect tones etc. It is told by 64.190.228.8 that 64.190.228.8 is ending the call, and hangups up the channel (returning OK to 64.190.228.8).

See trace below of the incoming call:

 

On the outgoing call the 64.190.228.8 did not send any 'BYE' to 192.168.100.130 when recipient of call hung up. You should ask the administrator of device at 64.190.228.8 why that device did not send any 'BYE' when recipient of call hung up.

vgEngine trace shows VoiceGuide timing out awaiting input in module [GetPasswordForDialOut], and VoiceGuide the progressing onto modules [AssignPassword] and [PlayLoginFailed] and the starting the "After Hangup" script PostHangUp_Hiring.vgs and hanging up the call when that script completes.

When VoiceGuide/HMP hangs up the call it sends a 'BYE' to 64.190.228.8. 64.190.228.8 responds to the 'BYE' with a "481". vgEngine trace shows however that VoiceGuide is ready to make new calls (or accept incoming calls) on those channels despite the 481:

132243.744   9   3   1 state Waiting for a call

132339.873   9   7   2 state Waiting for a call

 

The response from the VoIP service provider suggests that their system would like to see IP addresses used instead of domain names in order to correctly respond to the final 'BYE' (and perhaps result in 'BYE' being sent by 64.190.228.8 at call recipient's hangup time?)

Suggest using "64.190.228.8" wherever you are currently using "ld01-05.fs.fusionconnect.net"

Especially in the number dialed and the <CallerId> setting.

 

[iTime]

Thank you.

We have tried to use the SIP IP address as suggested, but no luck.

But we agreed that this be an issue on the service provider's end, and have sent a request along with your comment.

Thanks.

[SupportTeam]

Is is possible to post the WireShark trace of the outgoing calls that were made with IP addresses instead of "ld01-05.fs.fusionconnect.net" ?

We can then have a quick look to see if there is anyhting else there that could be the issue.

[iTime]

Thanks for coming back to us for this issue.

Please find the attached; it has one call out where the user hung up while voice prompt was playing on [GetPasswordForCallOut].

Later, the "BYE" signal was sent by VG Script where we set "TimeOut" that forced workflow to [LoginFailed] module to be disconnected, not by the SIP trunk.

We used the IP address in "RegServer" instead of the DNS name.

Thank you. 

<VoIP_Registration>
<Display>DemoIVR</Display>
<Protocol>SIP</Protocol>
<RegServer>64.190.228.8</RegServer>
<RegClient>714xxxxxxx@192.168.100.91</RegClient>
<LocalAlias>714xxxxxxx@192.168.100.91</LocalAlias>
<Expires>180</Expires>
</VoIP_Registration>

 

vglog.zip

[SupportTeam]

When placing the outgoing call please use the IP address in the <CallerId> setting used on the outgoing call.

The <CallerId> option that is currently being used on these outgoing calls is still using "ld01-05.fs.fusionconnect.net"

Please change the <CallerId> setting to use 64.190.228.8 instead.

The <CallerId> setting is used inside the call's 'Options'.

More information on the <CallerId> setting can be found here: https://www.voiceguide.com/vghelp/source/html/dial_voip.htm

 

[iTime]

We have changed the part for "callerID" but the result is still the same.

Please find the attached.

Thanks.

vg_wireshark_log2.zip

[SupportTeam]

It's possible the SIP Switch is expecting that VoiceGuide/HMP's IP is used in the "Contact:" (and From:) fields.

Suggest trying using the IP address of VoiceGuide/HMP system (which is now: 192.168.100.91) in the <CallerId>

If you still get same outcome then suggest contacting SIP service provider, and provide both traces, the one with 64.190.228.8 being used in the <CallerId> and one where 192.168.100.91 is used.

 

[iTime]

Thanks for the suggestion.

Since that CallerID has been provided in that format (phoneNumber@SIPDNS) for long time for al our clients and they all have been working fine until now, I would say the VoIP provider must have changed something on their end.

We could not test with our IVR IP address yet since the new server with new VG version fails to start (BTW, we have posted a new topic for this), we will have to wait for that to be resolved first.

I will keep you posted.

Thanks.

[iTime]

We have just tested your suggested solution.

You were right; the service provider's SIP trunk has sent "BYE" signal correctly once we sent our "<callerid>" with VG's IP address.

The callerID with the SIP trunk IP address used to work fine until recently so I guess they may have changed something on their end.

Thanks again for all of your help.