- This topic has 4 replies, 1 voice, and was last updated 11 years, 7 months ago by MikeM to W1max.
29th August 2007 at 13:26 #31521PaulRGuest
Incoming calls are routing through through a Quintum AXT1600 however when calling party hangs up the phone the line at the other end is not released. Have checked CAS signalling configuration and set line template to Belguim/France Greece/…..UK. Also Disconnect detection on Line port configuration set to Battery Removal, though have tried the other options. Please advise of any otherconfigurations to check and any trace parameters I can use for diagnostics. Latest firmware p105 applied.29th August 2007 at 13:52 #31522WebmasterGuest
You’re in the UK? If so, use the settings we use. We worked through this problem with Quintum a while back on P104.
In the CAS SG, set SignallingType to “Loop Start, Forward Disconnect” and set ForwardDisconnectDelay to “75”. You may need to reverse the line.
Expirement, but those settings work for us.31st August 2007 at 09:55 #31523PaulRGuest
Thank you for the advice. The settings you reccommended have worked.
Paul.12th March 2009 at 06:01 #31524W1maxGuest
Hi, Incoming SIP calls from Comverse through Quintum Tenor CMS. However when calling party hangs up the phone the line at the other end is not released. This doesn’t happens to connected call, it only happens to unconnected calls. Unconnected call means ringing, calling party hangs up the call…but the line isn’t cut off, it keeps ringing. Latest firmware P105.12th March 2009 at 18:21 #31525MikeM to W1maxGuest
Without know the signaling and such I can only offer generalities here. In general, it is not the CMS that initiates the disconnect. Typically it comes from the line side (E1/T1) through standard signaling like an ISDN disconnect. Unless you are using a channel bank with loop start. That may be a different story. Or the disconnect is coming from the IP side as an H323/SIP disconnect. In either cases, when the CMS receives these messages, it will pass them along to the other end to disconnect the line.
If this is easy to reproduce, you should probably run some standard event logs to see where the message is coming from (if at all) and what happens.