SIP Trunk locking up/not releasing calls

[cmcternan]

Has anyone experienced anything similar this this?

MCD Release 4.0 (10.0.0.10_2)

We have 1 SIP trunk with licenses for 2 simultaneous calls. The SIP calls terminate on a Patton Smartnode BRI adapter.

Every couple of days I will suddenly be unable to make or receive any calls through by BRI line. After some investigation it appears that the MCD seems to believe that the calls are still active.

If I run SIP SHOW ACTIVE ALL from the maintenance command I get the following:

1) Link: SIP_GW Profile: SIP_GW ID: 10a6ac20(382)-10000294
 Started at FRI JUN 24 14:38:41 2011
 Calling: 03XXXXXXXX@192.168.215.7
 Called: 1XXXXXXXXXXXX@192.168.215.7
 State: StateReleasingWaitForResp
 MediaState: StateMediaTerminated (-1,-1)
 Call-ID: 678595632-92469908@192.168.215.2
  Media Session not present

2) Link: BC_GW Profile: BC_GW ID: 10a69d10(473)-10000364
 Started at MON JUN 27 13:35:44 2011
 Calling: 03XXXXXXXX@192.168.215.7
 Called: 1XXXXXXXXXXXX@192.168.215.7
 State: StateReleasingWaitForResp
 MediaState: StateMediaTerminated (-1,-1)
 Call-ID: 2697945168-92470211@192.168.215.2
  Media Session not present

It is showing that there are 2 calls still active on the SIP trunk. If I check the gateway itself I can see that there are no active calls. It seems that the controller is "hung" in some way.

What this means is that I can no longer receive or make calls though the SIP Trunk. The trunk is configured for only 2 simultaneous calls.

If I remove the trunk and run SIP SHOW ACTIVE ALL it will return the same results, it seems that it still thinks the calls are active.

The only way I can get calls active again is to delete the trunk and recreate it with a new name. I have done this a few times but calls will eventually hang again forcing me to re-do it all over again.

Is there any way to clear the calls using the maintenance commands? If I reboot the controller it will flush the list, but this is not really an option in a production environment.

Has anyone else seen similar problems?

Any pointers/ideas would be appreciated.

Cheers

[ralph]

Haven't seen this problem but maybe I have a work around.
I'm thinking you may be able to apply a special COS to the trunks that will disconnect the call after 3 hours.
Again, this is something I haven't tried but I would suspect it would work.

Ralph

[brantn]

SIP BUSY PEER "Name of Peer" and SIP RTS PEER "Name of Peer" will at least fix it being that you only have two trunks I would probably setup a capture even if you filter it to SIP to see if there is a signaling issue. I would also look into session timer on the sip trunks that should tear it down.

[ralph]

This is from a linkedin Group I bounce the question off of:

I work with an ex-Mitel Engineer. He suggested to ask the tech to check the "timers". Perhaps changing the "Session Timer" on the Mitel to 0 (zero) might be worth a try.

Ralph

[cmcternan]

Thanks for the tips.

I just double checked my trunk settings and my timer was already set to 0. Next time the lines lock up I'll try setting the peer to busy and then releasing it.

Still a very odd issue. I have never seen this on any other systems we have deployed. I wonder if it is a bug particular to this release...

[brantn]

This is typically due to a signalling issue a session timer is there to break it when all else fails typically these are set very high on the carrier as they expect you to tear them down with proper signalling. I have seen this before and it depends on the exact signal issue wireshark is your friend.