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:
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.
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.
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.