PSTN - 2 - PSTN Bridging

David Trad · ‎07-29-2009

HI Cisco Staff,

As per the subject heading, we have pretty much flogged this problem to death, so i will try my best to outline it and what we did with tac across all sites affected with this issue:

The Problem:

Incoming call comes into the UC-500 from the PSTN network (FXO), then is imediatly onforwarded to either a Fixed line or Mobile via another PSTN line (FXO), here is where the problem begins.

When either leg of the call hangs up, there is no call tare down, both lines appear to have closed of the circuit (Mobiles for certain), and like wise with a fixed line (Most times), however the UC-500 Locks the ports down, they become unusable, and remain up until a "shut" ---- "no shut" is carried out on the port.

This issue is plaguing many of customers, and many systems i have worked on over the past 8 months, i am not sure if this is limited to the way Australian Carries operate their PSTN services, or if this is an inherit problem with Analogue services in general.

However we have run TAC case after TAC case, each time achieving a zero outcome, all possible configuration have been made and even some funky tricks that really only ever had minimal succes, minimal in the sense that at times we were able to achieve a tare down of one leg of the call.

Temporary Resolution:

We have begun where possible to move clients over to SIP trunks, this obviously has it's advantages in reducing call costs, however it does not resolve the problem as many clients are still apprehensive of VoIP services, and there is not point turning black and blue of trying to convince them otherwise.

Possible Solution:

I am possibly residing somewhere in daisy land or up with the fairies with my suggestion, but hey it is only worth a try.

Let me try and map out how this would work:

Incoming call comes in on a FXO port
System detects a call forward in place
Instead of diverting it to another FXO port it passes the call off to a virtual DN so to speak
This vritual DN does nothing but handle Call Bridging of two analogue lines, it passes of the second leg of the call to the FXO port and manages the call
The DN bridge detects a closed circuit much the same way as a Desk Phone would and begins tare down of that leg, subsequently it tares down the other leg as well.

I am going to assume at this stage this can be a hard coded thing, the system might already do it so my suggestion really becomes moot, but i am struggling to understand why a proper tare down can not be completed such as a Key system would do it. I am resigning to the fact that moving over to IP based services does bring about it's own set of problems, and some of them are just unexplainable to the customer, and you can not always keep blaming the telco's and the way they operate their network, sooner or later the buck has to stop somewhere i would imagine.

I am only posting about this problem because i am just getting tired of everyone complain about it, and friends in the industry asking me to try and help them with this problem as well, i simply don't have an answer for something like this, even after spending countless hours with TAC trying to resolve it.

I hope we can open up some dialogue on this issue and work together to try and resolve it.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

David Harper · ‎07-29-2009

Hi Dave,

What you have here is a well known problem with analogue services that unfortunately is not ammenable to an easy solution. ISDN and SIP do not have this problem because they have explicit messaging that signals that the remote party has disconnected. In the case of analogue services, there is also explicit signalling, but there are several different mechanisms, including:

1. Power denial - the DC power supplied by the exchange is disconnected briefly.

2. Battery reversal - the polarity of the DC power supplied by the exchange is reversed briefly.

3. Disconnect tome - a tone or tone sequence is played by the exchange.

Any of these methods may be chosen by a given telco when they set up their infrastructure. Unfortunately, in Australia, a service running off the Telstra infrastructure (ie most of them) will only use method #3. What this means is that the UC500 has to listen to the line and detect the disconnect tone to know that the remote party has disconnected. If it does not detect that tone, then the port will stay active until the local party hangs up. If you have a hairpin transfer or forward that is looping a call in one FXO and out the other, then you can get the behaviour you describe.

Because we need to detect a specific tone sequence, it means this disconnect mechanism can be problematic if the frequency or cadence of the disconnect tones varies, or if the signal is significantly distorted. The UC500 is configured to detect the tone sequence that is standard in the Telstra network, as that represents the majority of services deployed in Australia, and is used as a reference for many other infrastructures deployed by the different telcos. However, sometimes you will run into an infrastructure that uses a different tone or sequence, and then the config needs to be modified. Unfortunately, you will typically not find this out in advance, and also you will typically not get any detailed specs from the telcos support line. What this means is that in these cases it is necessary to capture a sample of the tone and analyse it to determine frequency and cadence and then configure the UC500 appropriately.

In other parts of the world, this is less of a problem as they will frequently use either of method #1 or method #2. Although then you can be vulnerable to false positives due to poor wiring.

As for your suggestion, having a virtual DN to do the bridging is all well and good, but when all the parties involved are connected via FXO lines, then you have the same problem with detecting the remote disconnect. When you have a handset involved, disconnect detection is performed by the user and he signals that disconnect to the UC500 by hanging up the handset, which then allows the call through the FXO port to be cleared. Obviously this isn't viable with a virtual DN.

Cheers,

Dave.

David Trad · ‎07-29-2009

Hi Dave,

I knew you would chime into this discussion, but to be the first CAB of the rank..... I'm honored

(<------------ American Spelling it would seem)

Dave you should know me quite well by now after the many hours takingup your time ;) so you would know i am clutching at straws here to try and solve a problem that is overwhelmingly annoying and frustrating to deal with.

The interesting thing with this problem is that i have never been able to replicate it with SNR, for some reason SNR does not get affected by they issue, my technical proficiencies can not provide me the answers to that one.

Thanks for your reply Dave, whilst i pretty much knew word for word what you were saying due to the amount of time and effort spent on this problem and hearing it over and over again, i probably don't hear it enough for me to let it go and keep finding a work around. I suppose though this thread might be important to other Aussie battlers faced with this annoying problem.

I do however state once more, i was clutching at straws with my post and i had to write it up cause i was loosing sleep over it, i needed to vent my frustration, where better then on the forums and not in the office.

I guess for now we will continue to soldier on trying to convert out clients over to ISDN or SIP trunks, even GSM gateways since those and the services are coming down in price significantly.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

joe.borg · ‎12-26-2009

Hi,

I'm facing the same exact issue described in this post with a recent install. I'm (painfully) aware of the issues surrounding FXO disconnect - in particular when using loopstart signalling since this signalling mechanism has no explicit disconnect signal. To this end I've configured the usual 'workaround'; that is the appropriate cptones in conjunction with supervisory disconnect dualtone midcall. This configures the router to 'listen in' on the call and detect a given call progress tone and subsequently disconnect when the tone has been detected.

All well and good so far and this solution works fine for me for normal FXO to VoIP calls. However, in the scenario described in this post (i.e. FXO to FXO hairpinning when the VoIP user has a call forward to a PSTN phone), this solution doesn't work. As described in the original post, when either FXO/PSTN side disconnects, both FXO ports remain off-hook on the Cisco gateway.

I originally thought that this issue might be due to the fact that hairpinned calls on the same voice port require no DSP intervention and hence the gateway would not 'listen in'. To this end, I configured 'no local-bypass'. This is per the guideline here. However, this didn't change matters in any way :-(.

At this stage I'm therefore wondering whether:

1. 'no local-bypass' does in fact make sure the DSPs are engaged on the modern/UC platforms (I'm aware the command has been around ins ome shape or form since the MC3810)?

2. If it does then whether it should in fact address the problem described or whether there's any other obstacle I'm missing?

Thanks

Joe