I've been struggling with this issue for over a month and both I and TAC seem to be stumped.
I have a customer with a small office that we are trying to migrate to a centralized CCM cluster. They have a 1760V with 4 analog lines that we want to connect to an FXO card. When we connect the lines to the router for testing I get the following behavior.
PSTN caller calls into the system.
The IP phone user hears the phone ring and answers the call.
The IP phone user sees the call disconnect After a second or two, the call begins to ring again on the IP phone If the IP phone user answers the call again, the call disconnects and the process repeats The PSTN caller hears ringback the whole time.
The problem seems to be that the router is interpreting a disconnect coming from the telco.
008192: .Jul 31 08:36:28.484: htsp_process_event: [2/0,
008193: .Jul 31 08:36:28.488: [2/0] set signal state = 0xC timestamp = 0
008194: .Jul 31 08:36:28.488: htsp_timer_stop
008195: .Jul 31 08:36:28.488: htsp_process_event: [2/0, FXOLS_CONNECT,
008196: .Jul 31 08:36:28.716: htsp_process_event: [2/0, FXOLS_CONNECT,
008197: .Jul 31 08:36:28.744: htsp_process_event: [2/0, FXOLS_CONNECT,
I've talked to the CO guy but he's been little help. I did have them run a ground start trunk for testing but it exibits the same behavior.
I've tried every combination of battery-reversal supervisory disconnect etc... that I can think of but I cannot seem to solve this problem.
TAC does not think its hardware related but I'm going to send a replacement router out just in case.
I'm hoping someone might have some suggestions for me.
Thanks in advanced.
I have seen this problem before where the polarity on the wires were reversed and/or the physical wiring is physically 4 pairs instead of 2. The physical wires going into the fxo ports should be 2 wire.
Please have the telco verify that the polarity is not reversed [ make sure that verify/re-verify ] as sometimes they claim to check, but are not diligent enough when checking.
If the gateway is somehow detecting battery-reversal, then it will essentially disconnect the PSTN call leg, which will cause the ip phone to see a disconnect. Next, because the PSTN continues to ring the call, a second call will come in [ from the view of the ip phone ]. To test if battery reversal is causing the problem, you can temporarily disable battery-reversal detection on the voice port by using the following command:
router#test voice port 1/1/0 detector battery-reversal
If after disabling battery-reversal, and this problem dissapears, then there is your problem. Please note that the test voice port command only lasts until the router is rebooted.
What happens if you connect a regular analog phone to the FXO line and place calls from that phone? This would help you can eliminate any wiring or telco issues.
If the polarity was reversed or the wire is physically 4 wires instead of 2, this test would not prove useful as the circuitry inside a regular telephony is not as sensitive as the circuitry inside the fxo cards.
Thanks for the wealth of information.
I tried disabling the battery reversal but that didn't make any difference. According to TAC, we have the polarity reversed on this connection right now so I'm going to have to get that addressed before I do anything else. Unfortunately this customer site is out in the middle of nowhere and it will be a few days before anyone can get out there.
I'll update the thread when I get a chance to test again.
I was able to test with battery reversal disabled and it did not make any difference.
I also verified that the connection is only using 2 wires and I had the onsite contact swap the pins, which did no good. Is that sufficient to verify the polarity?
Any other suggestions?
I had this exact problem and it was wrong start method. The lines were part of a centrix system and required loopstart in stead of groundstart on the FXO ports.
Well, It looks like this was a hardware problem after all. I sent a test router running the same ios version and it worked fine.
I'm not sure what component failed yet but I assume it will turn out to be the voice card or possibly the PVDM.
i have exactly the same problem, but in my case we already replace the hardware and the problem persists. Additionally, 2 out of 4 of these FXO ports works they way it should be and the call gets answered> The additional 2 FXO ports continue to experience the problem already discussed even after hardware replacement.
Cisco is looking into the issue but so far not much from them.
gateway is h323 with 12.3(11)T11 and CM 4.0.2
I had a similar problem with a different customer a few weeks ago. In this case the call would disconnect when first answered and ring back but when answered the second time it would stay connected. The problem in this case was how the telco was doing caller id. I had to set the caller-id alert to 3 rings so the router would not present the call to the IP phone until the 4th ring. I'm not sure it this applies to your case but thought I'd mention it.
Please post the solution once you find it. I'll be interested to see what it is.
The problem was with the line. After punch down the lines again all started working.
Thanks for your replies, if you encounter similar problem, check the lines from the extended-d marc also.
I had the exactly same problem you have mentioned and I must say changing caller-id alert ring to 3 has resolved the issue.