sip trunk off prem call fwd not tearing down call when complete

[mattyboy]

have a mitel mcd 3300 rel 8.0  with sip trunks the sip trunks are working audio is fine incoming and outgoing are fine the customer has an embeded vmail and it has an option that dial an offsite call center then then transfer back to the site via a DID
it looks like this operation locks up a link on the sip trunk and doesn't release it  a busy and a RTS of the peer tears down the link

here is what it looks like   anything thoughts or ideas how to tear down these calls?

[lundah]

Sounds like a mismatch in the SIP Peer Profile settings. Without more detail, hard to be more help than that.

[mattyboy]

it looks to be calls coming to the auto attd,   the locked up links are either an outside call talking to a vmail port or an outgoing call from a vmail port to  a speed dial that is an offsite phone number . doing a force busy on the peer and return to service doesn't clear them

they are using a device from lightpath called a siparator which doesn't require a registration it has an ip on the network and that is what the 3300 sends calls thru ,   a normal call that gets to an ext shows the bye and tears down the link when the ext goes on hook , they had a configuration for a 3300 that we followed I am trying to trap a call that locks up the link

this was a system with 3 working pri circuits they just ported incoming to sip , the sip trunks were used outgoing with no issue for a few months

[johnp]

Seems to me that they do not respond to a bye

[mattyboy]

I can recreate the issue at will now   it has to do with the fwding offsite   If I call into the Mitel embedded auto attd and hang up during the greeting the sip link gets torn down n0  issue so DID traffic and incoming that goes to a Mitel ext outgoing no problem either this morning I called and traffic was very slow and I was able to get a pcap from the Mitel I called from my cell to the auto attd and chose an option that gets fwd'd to another offsite IVR and during that greeting I hung up   and after I hung up the incoming leg and the outgoing leg of that call were locked up   the system inserts the outgoing caller ID for the vmail ports to a DID that rings back to the auto attd I am wondering if the BYE needs to be specific to the port that handled the call?  the vmail is set for unscreened transfer

thanks for the input

[mattyboy]

issue has been resolved, the carrier looked at the pcaps I sent them and it was the way their equipment was handling our refer request when the vmail transfers offsite.  on a bad call there was no BYE in the string and a 200 ok  request was sent 3 times from the carriers sipartor device  10.5.1.100 to the 3300 10.5.1.1 after our invite. this left all the sip links up,   first pic is a bad call where the links stayed up forever , the second pic is after the carrier changes and if the caller hangs up at anytime during the call the links are torn down properly there is a bye sent so the mitel can tear down the links properly