Ports Getting "stuck"

[bfrank]

Yesterday, I noticed a port "stuck" in transfer. I hung up the call from the Status Monitor. Same thing happened today.

 

Now I see those 2 ports aren't getting new calls. That reduces our line availability. If this is a daily occurence, we'll need to restart the service once a week.

[SupportTeam]

Could you please post a copy of VoiceGuide's Debug Printout which cover this event, this will allow us to see what happened.

 

When posting traces/scripts please .ZIP them up and post them as attachments.

 

Please indicate which ports you had problems with and at roughly what time you hung up the ports, so we know where in the log files to look at.

[bfrank]

The "stuck" ports in Status Monitor are labeled with IDs 1 and 8. I attached log files that cover the timespan during which I "hung up" the calls on each of those ports.

 

I hung up the call on port 1 at 10/20/09 11:04:56, and on port 8 at 10/21/09 14:42:57.

 

(I had to cut out parts of the files to stay under the 2MB upload limit).vgEngine.zip

[SupportTeam]

The traces for the "port 1 at 10/20/09 11:04:56" call starts 5 minutes prior, at 11:00:00, and there are no other enties related to that call in the traces.

 

The traces for the "port 8 at 10/21/09 14:42:57" call starts 20 minutes prior, at 14:22:06, and there are no other enties related to that call in the traces.

 

So we cannot see what happened on that line beforehand.

 

Next time it happens please note down the call start time that is showns in Status Monitor, and supply traces which go back to that time.

 

Please also include the ktTel trace. The ktTel level trace shows the actual VoIP/HMP level signalling, and it looks like some missing VoIP call control signalling may have been what has caused this.

 

 

110451.593 32 wcf Action_Hangup call. iPort=1 => iLineId=3

 

144252.453 21 wcf Action_Hangup call. iPort=8 => iLineId=25

[SupportTeam]

When doing the RFC3515 Refer transfer the party initiating the transfer (in this case VoiceGuide) would expect to receive a call control signal indicating that the original call is now disconnected. This usually arrives within 1 second of the RFC3515 Refer transfer being initiated, and we can see in traces provided that all the other RFC3515 Refer transfers were completed quickly and line was then immedialtey disconnected with no problems.

Looks like in the cases where you encountered problems the VoIP control signal informing VoiceGuide that call is now disconnected was never received by VoiceGuide.

To resolve this we have now added code for VoiceGuide to hangup by itself if the disconnected signal does not arrive within 30 seconds.
This will free up the VoIP port, allowing it to handle new calls.

Version with this patch included can be downloaded here: [old link removed]

[bfrank]

Hi. I never actually installed this patch, and this issue (stuck calls) is still a problem for us. I'm ready to try it now, but before I do, is there an updated version of Voiceguide I should be using? Or should I just go ahead and install the patch linked in the above reply?

 

Thanks.

[SupportTeam]

That patch is now merged into main release. Please download and install latest version of VG from our WWW. Please update HMP drivers to HMP version recommended for use.