VoiceGuide goes unresponsive after some duration (Answ: NAT translation was timing out)

[iTime]

Hello Support,

Our VG server goes unresponsive after certain duration (i.e. 30 minutes) as if it is a evaluation version.

But you can tell the license has been activated.

Once we restarts it becomes OK once again.

Could you tell what the issue is?

Thank you.

IVR_Log.zip

[iTime]

We noticed that the Expiration timer is the key issue here.  For example, the configuration showed 180 seconds.  After 180 seconds, Voiceguide is no longer responding.  It's like it's not reinitiating the connection after the timeout expires.

VoIP_Registration>
<Display>COSPIVR</Display>
<Protocol>SIP</Protocol>
<RegServer>peer3.thevoicemanager.com</RegServer>
<RegClient>5036169012@xxx.xxx.xxx.xxx</RegClient>
<LocalAlias>5036169012@xxx.xxx.xxx.xxx</LocalAlias>
<Expires>180</Expires>
</VoIP_Registration>

 

Thank you,

[SupportTeam]

Quote

Our VG server goes unresponsive after certain duration (i.e. 30 minutes) as if it is a evaluation version.

This system is working in evaluation mode. vgEngine trace shows:

140540.175  11                reg   *******************************************************
140540.175  11                reg   UNREGISTERED EVALUATION VERSION, lines: 30 id: LK004445
140540.175  11                reg   *******************************************************

 

[SupportTeam]

Quote

After 180 seconds, Voiceguide is no longer responding.  It's like it's not reinitiating the connection after the timeout expires.

Sounds like the VoIP registration is not correctly set up.

Please make a WireShark trace capturing the SIP REGISTER communications done at the VoiceGuide service startup time. Include at least one call in the trace. Keep the WireShark trace running for at least 3 minutes (until the SIP Registration expires and new calls stop being sent to VoiceGuide system). Once we have the WireShark trace we will then be able to advise how to set up the <VoIP_Registration> section of the Config.xml file.

[iTime]

Hello,

Attached is the wireshark capture that you have requested.  Also, we've included all other logs as well. 

Please advise.

 

Thank you,

 

IVR_log2.zip

[SupportTeam]

WireShark shows that the device at 216.86.41.167 (Asterisk PBX?)  immediately replied with a "410 Unauthorized".

So looks like the user/number 5036169012 / 5036169012@166.78.32.134 is not recognized by it. Maybe you should use 5036169012@216.86.41.167 ?

216.86.41.167 device logs may show more information as to why the REGISTER request was replied to with a "410 Unauthorized".

Also, VoiceGuide seems to be installed on IP address 172.24.17.5, so that IP address should be used in "Local Alias" (if IP address is used as part of alias).

Another option that you could look into is setting up a SIP trunk form Asterisk to VoiceGuide.

 

[iTime]

Thank you.

We will contact the service provider and speak further.

 

[SupportTeam]

Another thing to note is that despite the Registration of 5036169012 not being made, the device at 216.86.41.167 does send a call to VoiceGuide (at IP address 172.24.17.5).

This suggests that there is already a route set up in 216.86.41.167 that sends certain calls to VoiceGuide.

If after a while those calls stop arriving at VoiceGuide then you may want look at the networking setup between 216.86.41.167 and 172.24.17.5

If you have any NAT type devices in the path it is possible that the original REGISTER request opens the connection between 172.24.17.5 and 216.86.41.167, and the connection is kept open as long as there is regular traffic between the two, but if for some time there are no packets sent from 172.24.17.5 to 216.86.41.167 then the address translation information in the NAT device expires and any packets from 216.86.41.167 will no longer be delivered to 172.24.17.5. In those cases having regular REGISTERs between the two devices maintains the address translations in any NATs in the path.

[iTime]

That's such a detailed tip for this issue.

Actually this started happening after we changed the network environment for this server, including the original IP address.

Since this connection was supposed to be Static, your tip sounds more convincing.

I will pass this to our Network Admin.

Thank you again.