Problem with detecting/passing on disconnection from PSTN

[mwhapples]

I am in the UK and recently got an OBI110. As others have noticed although it may be named the UK version, it still comes with default settings for the US. So I changed the settings as describe at http://www.obitalk.com/forum/index.php?topic=5866.0

The other change I made to the line connection than that listed above is to turn off the silence detection for line disconnect, mainly as sometimes if one has to hold the line may be quiet (either because the other end has no actual hold on their phone so they have just placed the reciever on the desk while they find out information or on very rare occasions the hold system has no music or tones) and I don't like the idea that the OBI110 might disconnect in that situation.

The device seems to work fine except for one small issue. The OBI110 does not seem to detect or pass on the disconnection of the BT PSTN line to the phone, it seems to rely upon the phone disconnecting.

I noticed this with my answer phone, which when connected directly to the BT socket will stop recording immediately when the person hangs up and it does not play the "Thank you for leaving a message" message. However when connected to the OBI110 my answer phone continues to record the disconnect tone and then after quite a few seconds will play the "Thank you for leaving a message" message. I know that the OBI110 is capable of letting my answer phone know of a disconnection as when a message is left on the answer phone from a call coming from my SIP account, it does stop recording immediately upon disconnection (in the same way as I described for the answer phone connected directly to the BT socket).

Any thoughts on what needs changing? I imagine it will be a setting for the PSTN line as I said the phone connection seems to work fine when recieving a SIP call, I just cannot work out what setting needs changing.

[hwittenb]

The other change I made to the line connection than that listed above is to turn off the silence detection for line disconnect, mainly as sometimes if one has to hold the line may be quiet (either because the other end has no actual hold on their phone so they have just placed the reciever on the desk while they find out information or on very rare occasions the hold system has no music or tones) and I don't like the idea that the OBI110 might disconnect in that situation.

The device seems to work fine except for one small issue. The OBI110 does not seem to detect or pass on the disconnection of the BT PSTN line to the phone, it seems to rely upon the phone disconnecting.

By disabling the silence disconnect detection you are relying on a CPC signal or a disconnect tone for the analog signalling by your U.K. phone company to tell the OBi that the distant connection has disconnected.  The default disconnect tone setup under DisconnectTonePattern on the Line Port is not the disconnect tone reported to be in use in the UK.

I find the the U.K. disconnect tone is reported to be either 400@-30,400@-30;2(3/0/1+2) or 400@-30,400@-30;2(*/0/1+2) in a Cisco/Linksys/Sipura format.  I would favor the latter format. 

Tone formats are complicated.  OBihai uses a different tone format spec than Cisco/Linksys/Sipura.  My guess for the OBihai format for the U.K. Disconnect Tone based on the reported value would be
400-30;2

Someone more knowledgeable is encouraged to comment.

[mwhapples]

Hello,
Thanks for the reply. Unfortunately the tone you gave did not fix the problem, but I did find from sipura a different CPC signal duration. Sipura list it as 0.09 so I set it to 90 in my OBI110 and this seems to have fixed the problem.

[Shale]

Hello,
Thanks for the reply. Unfortunately the tone you gave did not fix the problem, but I did find from sipura a different CPC signal duration. Sipura list it as 0.09 so I set it to 90 in my OBI110 and this seems to have fixed the problem.

You might recap what string you put into which variable to make the UK disconnect tone be properly recognized for you. That could be useful to others.

[hwittenb]

In a forum I saw this posting about the BT CPC signal:

In the UK, if you are using BT and are having problems with Asterisk not detecting hangups when using a TDM400P, contact BT and ask what the current "Disconnect Clear Time" setting is for your phone line. Mine was set to 100 and increasing it to 800 fixed the issue. "Disconnect Clear Time" (DCT) is BT's name for CPC. You will need to speak to the BT Faults service--they can check to see what your DCT/CPC is set to and reset it instantly to another value.

BT have two analogue line specifications: single line (BT SIN 351), and multiline (BT SIN 352), which explain the different forward disconnect parameters (http://www.sinet.bt.com/). These specifications state that for single line (like most of us have), the disconnect time is between 90ms and 130ms, for multiline it is 800ms. My impression is that the rest of the World (North America included) has a disconnect time in excess of 500ms, this explains why the default behaviour of zaptel (Digium and Sangoma cards alike) don't play well with single line BT phone lines for disconnect supervision.

When ordering lines from BT - especially feature lines or business lines ask the sales person to set lines to PABX working.
Neill Wilkinson
http://www.voip-info.org/wiki/view/Asterisk+Disconnect+Supervision

Basically that says the problem with BT disconnect detection is not a disconnect tone but adjusting the Line Port CPCTimeThreshold so that it recognizes a shorted drop in voltage.  The default CPCTimeThreshold on the OBi110 is 450ms.  The above posting says that it needs to be only 90ms or you need to get BT to raise the time the voltage is dropped, the "disconnect clear time".  The problem you can encounter with a shorter threshold is false signal detection.  I believe this is what mwhapples confirmed that he changed.

[mwhapples]

Just to confirm, yes I did drop the CPC duration for the phone line in the OBI110 configuration to 90ms and it solved the problem. I assume it is not relying on tones at all. At this point I have not yet had any false detections, calls only have been terminated when they were intended to be, although I must note that this has only been a few days, but I will know what to tweak should I get unexpected disconnections.