I don't know much about U.S. standards but I'd be surprised if it was required. 
It would probably just depend on your contract with them. I.e., if they have a 
written technical specification of the service you are buying, then obviously 
they need to meet that specification. In Canada, those specifications are 
typically in or referenced by the "tariff" that the telco files with the 
federal regulator and can be found online.

You mentioned that the telco "eventually" plays a tone and an operator 
announcement. Obviously immediate detection would be preferred, but eventually 
is at least better than never. You should be able to configure "supervisory 
disconnect dualtone mid-call" on the voice-port to hangup when it hears the 
tone. Depending on what the tone is, you might have to configure a 
"custom-cptone" so that the voice-port knows what to listen for.

I have a site in a remote rural hamlet that gets its phone lines from a CO in 
another town via an ancient analog multiplexer. Telco tried to get linecards 
for it that support disconnect signaling; they exist but are too ancient to 
find. So I'm stuck using the "eventual" tone at that site. Better than nothing.

-mn


-----Original Message-----
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Hughes, Scott GRE-MG
Sent: September-21-16 3:18 PM
To: Esmaeel Saberi <esmae...@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] FXO Disconnect Detection

Thanks for all the advice. An update on this issue:

We have been in contact with the carrier. They have indicated that others have 
had similar issues, all since moving to a “new” softswitch at the CO. The CO 
tech has apparently verified that the signalling is going out, but doesn’t get 
passed through the DSLAM that is somewhere in between the CO and our premise.

Is there anyone who is knowledgeable about telephone standards & regulations? 
Is the carrier REQUIRED to do disconnect supervision, or is it merely a 
courtesy?

On Sep 12, 2016, at 1:11 AM, Esmaeel Saberi 
<esmae...@gmail.com<mailto:esmae...@gmail.com>> wrote:

EXTERNAL

This link is usefull 😉
https://supportforums.cisco.com/discussion/11127921/fxo-4-voice-ports-always-busy
On Mon, Sep 12, 2016 at 10:34 AM Esmaeel Saberi 
<esmae...@gmail.com<mailto:esmae...@gmail.com>> wrote:
Hello
You must record the sound of busy or congestion tone and define the frequency 
in router

On Mon, Sep 12, 2016 at 5:21 AM Sreekanth 
<sknt...@gmail.com<mailto:sknt...@gmail.com>> wrote:
Hi Scott,

When reaching out to the telco, ask them what kind of disconnect they're doing. 
Is it:
1. Battery reversal
2. Power denial
3. Supervisory disconnect - tone played by the telco to indicate a disconnect

You've mentioned that when the remote party disconnects, the VoIP phone stays 
off hook. Do you hear a disconnect tone during this period? If so, the telco is 
using supervisory disconnect.
In that case, your DSPs on the router may need a tweak. You can do 2 things:

1. Take pcm captures on the router to capture the disconnect tone. Then open a 
case with TAC who can decode this and give you the settings for the supervisory 
disconnect.
2. Do the ds0-dump on the router and capture the tones, decode them yourself 
using Audacity and put in the settings.

DS0-dump: 
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-system/115749-analyze-pcm-data.html

Video for setting up pcm captures and Ds0-dump.
https://www.youtube.com/watch?v=HkPjTBvx_YA

Cheers!

On 12 September 2016 at 05:30, Ryan Huff 
<ryanh...@outlook.com<mailto:ryanh...@outlook.com>> wrote:

Scott,


You are correct, it is the default. Oddly, what I meant to suggest is that you 
try disabling (no battery-reversal) but it seems that I suggested you to enable 
it (in which it has always been enabled). Try disabling the support and see 
what happens.


Apologies!


Thanks,


Ryan

________________________________
From: Hughes, Scott GRE-MG <shug...@grenergy.com<mailto:shug...@grenergy.com>>
Sent: Sunday, September 11, 2016 7:13 PM
To: Ryan Huff
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] FXO Disconnect Detection


:-/ unfortunately, that command must already be a default is IOS 15.5M because 
it doesn't show up in the running config after I put it in.

Thanks for the suggestion though!


On Sep 9, 2016, at 6:21 PM, Ryan Huff 
<ryanh...@outlook.com<mailto:ryanh...@outlook.com><mailto:ryanh...@outlook.com<mailto:ryanh...@outlook.com>>>
 wrote:

EXTERNAL

You may try enabling support for battery reversal detection on the voice port;

voice-port x/x/x
battery-reversal
!

-Ryan

On Sep 9, 2016, at 6:57 PM, Hughes, Scott GRE-MG 
<shug...@grenergy.com<mailto:shug...@grenergy.com><mailto:shug...@grenergy.com<mailto:shug...@grenergy.com>>>
 wrote:

Hi,

I have a Cisco 2921 H.323 gateway tied to CUCM 11 with 4 FXO (loop start) ports 
in a trunk group. Unanswered calls get forwarded to an offsite answering 
service (hairpinning out of the same set of FXO ports). Ports are setup with 
"connection plar opx 1000"

My issue is that ports don't detect when the other end hangs up. When a remote 
party hangs up, the VoIP phone stays off hook and eventually plays a dial tone, 
followed by an operator message.

I suspect that the forwarded calls terminate but both FXO ports in the hairpin 
stay off hook indefinitely.

How can I combat this problem? I can reach out to the telco but need to know 
what to ask for.

I am located in the US, if that makes a difference. I've read many articles 
about supervisory disconnection but none really help with troubleshooting steps 
or timers to tweak.

-Scott


NOTICE TO RECIPIENT: The information contained in this message from Great River 
Energy and any attachments are confidential and intended only for the named 
recipient(s). If you have received this message in error, you are prohibited 
from copying, distributing or using the information. Please contact the sender 
immediately by return email and delete the original message.



_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><mailto:cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>>
https://puck.nether.net/mailman/listinfo/cisco-voip



NOTICE TO RECIPIENT: The information contained in this message from Great River 
Energy and any attachments are confidential and intended only for the named 
recipient(s). If you have received this message in error, you are prohibited 
from copying, distributing or using the information. Please contact the sender 
immediately by return email and delete the original message.




_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



NOTICE TO RECIPIENT: The information contained in this message from Great River 
Energy and any attachments are confidential and intended only for the named 
recipient(s). If you have received this message in error, you are prohibited 
from copying, distributing or using the information. Please contact the sender 
immediately by return email and delete the original message.


 
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to