TA-924 Call Forward Disconnect

[fjd]

Please let me start by saying I have little technical background on this issue, but am trying to solve a problem for a client who is not getting straight answers from his phone provider.

The question concerns call forward disconnect.  Here is the scenario:

Customer PBX is an Avaya Partner RS8. (Pool/Hybrid)    Nine (9) analog inbound lines from the Adtran.  (loop start only)  The rest of the T1 circuit is for backup Internet.    (Windstream)

Customer has set up call forwarding on one extension #24. Call is forwarded to a speed dial on extension 24.  The speed dial number is his cell phone number.  When call forwarding is initiated by pressing a hot key on the Avaya phone, all calls are forwarded to customer's cell phone.  The Avaya seizes a line from the pool to make the outside call.    Now two lines are in use.  When parties hang up lines would not clear and become available again, they just flashed fast busy until lines manually picked up at extension 24.   All calls used to result in the problem until I adjusted the Avaya's Hold Disconnect Time to 300ms from 450ms.  Now the majority of the calls disconnect when both sides hang up.  The problem still occurs when both parties hang up simultaneously, the two line remain hung until manually picked up on ext 24.

Does the 924 offer any service or programming which can solve this call forward disconnect problem?    The Adtran brochure talks about calling feature support regarding Call Forward, Call Transfer (Blind & Attended) but this may be on phone service provider side rather than the Avaya.

Any help or direction regarding this problem is appreciated.  If the answer is technical beyond by abilities, I can pass it on to the techs.

Thanks

Frank

[Anonymous]

Frank,

Thanks for posting.  From the Adtran unit's perspective, this just seems like two independent calls.  As long as the Adtran unit receives a Bye message on the SIP side of the unit, it will remove talk battery on the analog line corresponding to that call.  The default setting is 750 milliseconds as shown below.

voice user 1001

forward-disconnect delay 750

You could increase that setting to 1000 or 2000 ms to see if that improves the reliability of the PBX detecting the far end disconnect.  Also, you can view battery removal and on-hook and off-hook events with the following debug commands.

debug voice verbose

debug interface fxs

Thanks!

David

[fjd]

David:

Thanks for the quick response.  Where in the Adtran GUI can the forward-disconnect be adjusted?  I only have the quick start PDF manual and could not find the proper location.

Our problem occurs when their is a simultaneous "hang-up" by both parties. Are the "bye" messages interfering with each other?   Must the forward disconnect be "set" for each analog line?  We are using what the vendor calls a "dynamic' T1 circuit with both analog lines into the Avaya and the remainder of the T1 for backup Internet.

Thanks,  I am learning a bit more with each post!

Frank

[jayh · Accepted solution]

Consider this scenario as one incoming call SIP-to-PBX and a second outgoing call PBX-to-SIP.

On the incoming call, when the originator hangs up, the TA900 will get a SIP BYE.  This causes it to tear down the call to the Analog port.  When it does so it will by default remove battery for 500 milliseconds.  The Partner system should see this loss of battery and disconnect the call.  If it doesn't, then it won't initiate a disconnect on the outbound leg.

I would change the battery removal to 1000 milliseconds on the TA900.  You can go up to 2000 but 1000 should certainly do it.  In the GUI this is done in the Voice User screen under Forward Disconnect Delay and you'll need to do it for all users.  You can also change the disconnect from remove to reverse battery but most simple PBXs will easily handle disconnect and may not detect reverse.

The outbound leg is similar.  If the inbound leg disconnects first, the PBX should initiate a teardown by opening the outbound loop.  The TA900 will sense this as any other analog on-hook and tear down the SIP side.

If the SIP outbound (called) party hangs up first, then there is often a delay of up to a few seconds before the BYE is sent.  When the BYE arrives, it will drop battery to the PBX via forward disconnect (same remove/reverse battery and delay settings as above).  This should cause the PBX to detect the call going down and it should tear down the inbound leg by going on-hook and removing loop current.

Long story short, the PBX is occasionally failing to detect that either or both of the outside parties has hung up.  Ensure that the battery removal time in the TA900 is longer than the detection time of the PBX, preferably at least double.  Set the PBX to as short as possible.  200 milliseconds shouldn't cause any problems.

Whether both parties hang up at the same time shouldn't make any difference.  Either or both hanging up should tear the call down.

If the outbound called party hangs up first, and the caller stays on the line, it may take several seconds before the PSTN network gives you a BYE, but when it does this should ripple through the PBX and drop the caller.

You may want to tweak the gain settings on the FXS ports if this is a common usage and the parties complain of low volume.  Going too high can result in echo, so don't be too aggressive.

[Anonymous]

Frank,

The forward disconnect delay can be set in the web GUI in each User Account under the "User Config" tab.  It must be set for each voice user that corresponds to an FXS port.  Also, the Bye messages should not interfere with each other since each should have a unique call ID.  If you are unable to resolve the issue by adjusting the forward disconnect delay, you may need to create a Technical Support ticket by calling 888-423-8726.  We would need to see the output of the following debug commands so that we can look for any call control issues.

debug sip stack messages

debug voice verbose

debug interface fxs

Thanks!

David

[fjd]

Gentlemen:

Thanks for your responses!  The insight provided has shown me the problem lies with a telecom provider who does not want to assist with the problem.  The provider will not adjust the "forward disconnect delay"  Here is their position:

This is what I received from my Operations Manager/ Switch Manager of Gulf

Coast Region

Brian, while the Adtrans have the ability to change timing features, we use

a set of standard or global timing settings for everything on the network in

order to eliminate any chances of mismatches and causing issues for other

elements.  These settings are the same for all users and all types of pbxs

that interface with us.  The Avaya pbx would control the disconnects as the

Adtran will pass through the disconnect signal received from the network.  I

would have 2 things checked, 1) have any other settings been changed in the

Avaya that would make it different from any other Avaya we interface with,

2) I would try forwarding to another phone that is not a cell phone, since

the cellular networks do take a substantial time to disconnect. If it worked

to another phone without a problem, then it may be a issue with the timing

being sent from the cell network.

I have spoke with our people here and in other markets and no one can

remember any instance of having to change timing parameters.

For the remainder of the contract I guess I will have to live with the fact "It can be done, it just will not be done"

Thanks again

Frank

[Anonymous]

You can bypass the password to the unit and make the change yourself.