FXO issue

bigcappa1 · ‎08-24-2009

Hi,

Got an issue with a line that the Telco says is ok. Got three trunk lines going into the FXO card. One line constantly holds the FXO port off hook. It may occasionally remain on hook if it is disconnected but after the first call it remains off hook again. I have switch the line across all 4 ports of my FXO card and it does the same on all 4 ports. I have also swapped the other two working lines across the ports and they are ok across all 4 ports. The Telco has tested the line and made and received calls with their test phone so they are convinced the line is ok. I have attached a debug vpm signal port 0/3/0 is a working port and I can see it going down and then coming backup and remaining on hook. port 0/3/2 has the faulty line and that goes off hook after coming back up. Is there any other way I can prove that the signaling coming from the line is wrong so i can go back to the telco.

Help much appreciated

Thanks

Paul

Nicholas Matthews · ‎08-24-2009

Here are the debugs:

*Aug 24 14:34:38.094: htsp_process_event: [0/3/2, FXOGS_INIT, E_HTSP_INSERVE]fxogs_init_inserve

*Aug 24 14:34:38.094: [0/3/2] set signal state = 0x4 timestamp = 0

*Aug 24 14:34:38.094: htsp_process_event: [0/3/2, FXOGS_ONHOOK, E_DSP_SIG_0100]fxogs_onhook_tip_ground

*Aug 24 14:34:38.094: htsp_timer - 7000 msec

*Aug 24 14:34:38.094: htsp_process_event: [0/3/2, FXOGS_TIP_GROUND, E_DSP_SIG_0100]

*Aug 24 14:34:38.094: fxogs_stop_disc_timer

*Aug 24 14:34:38.094: htsp_timer_stop2

*Aug 24 14:34:38.698: htsp_process_event: [0/3/2, FXOGS_TIP_GROUND, E_DSP_SIG_0100]

*Aug 24 14:34:38.698: fxogs_stop_disc_timer

*Aug 24 14:34:38.698: htsp_timer_stop2

So when we set signal state 0x4, we set the ABCD bits to 0100. This means onhook in groundstart.

After that, we detect E_DSP_SIG_0100 which means we are detecting the ABCD bits of 0100 from the provider. This means offhook in groundstart.

We go onhook, they go offhook.

-nick

bigcappa1 · ‎08-24-2009

Nick,

Thanks for that so from what you are saying if I am reading this correctly is that you are agreeing there is an issue with the line due to the fact that we go off hook when we should remain on hook. The other message from Brandon seems to support this and checking the voltages with the multimeter seems the next way to go. I had already checked the line with a normal phone and it works and this seems to be all the telco did, this was not the sort of investigation I was looking for from them. So multimeter would be the next logical step then I could go back to them with better evidence

Thanks

Paul

Nicholas Matthews · ‎08-25-2009

Hi Paul,

I don't think the multimeter is going to show you anything. The ABCD bits aren't going to be detectable with a multimeter.

You may want to push back on the provider. If the problem follows the line the provider should take ownership of the problem.

-nick

bigcappa1 · ‎08-25-2009

Nick,

Thanks for that is there any docs you know of that would let me investigate this more before I go back to telco. Docs that would allow me to gain a better understanding of your explanation previously

Many Thanks once again

Paul

Nicholas Matthews · ‎08-25-2009

Hi Paul,

This page is very helpful in understanding the bit signaling:

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800a6210.shtml#Topic3D

-nick

Brandon Svec · ‎08-25-2009

Understanding ABCD bit signaling is useful. However, keep in mind it only really applies to *digital* ground start, loop start, etc. (i.e. T1) or at least the point where it becomes digital. An analog telco tech wont and shouldn't know anything about ABCD bits..

Are these ground start or loop start lines? If they are ground start you should *not* be able to get dial tone with a regular analog phone set. You would have to touch the ring side of the circuit to a ground then go off hook, then release the ground to get dial tone.

-- please remember to rate and mark answered helpful posts --

bigcappa1 · ‎08-25-2009

Brandon,

I had them set up as ground start at first

voice-port 0/3/0

signal groundStart

cptone GB

timing hookflash-out 50

impedance complex2

The I tried loop start as that is more comman and when the telco was testing and we were testing we recieved dial tone on an ordinary phone.

The loop start config would only work when i inserted the supervisory command

voice-port 0/3/0

supervisory disconnect dualtone mid-call

cptone GB

timeouts wait-release 5

The result were the same in fact the only differnece I can see was the debugs in loopstart were more detailed so I could see more of what was going on. The is shouwed the good lines going ON HOOK and the bad line did nothing.

When in ground start the bad line went off hook immediatly after connection. In Loop start it stayed off hook after the first call

Bad port

Aug 25 15:54:57.092: [0/3/2] get_local_station_id calling num= calling name= calling time=08/25 15:54 orig called=

*Aug 25 15:54:57.100: htsp_process_event: [0/3/2, FXOLS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]

*Aug 25 15:54:57.100: fxols_wait_setup_ack:

*Aug 25 15:54:57.100: [0/3/2] set signal state = 0xC timestamp = 0fxols_check_auto_call

*Aug 25 15:54:57.100: htsp_process_event: [0/3/2, FXOLS_PROCEEDING, E_HTSP_CONNECT]fxols_offhook_connect

*Aug 25 15:54:57.100: htsp_timer_stop

*Aug 25 15:54:57.104: htsp_process_event: [0/3/2, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

*Aug 25 15:54:57.104: htsp_call_bridged invoked

*Aug 25 15:54:57.108: htsp_process_event: [0/3/2, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

*Aug 25 15:55:05.412: htsp_process_event: [0/3/2, FXOLS_CONNECT, E_DSP_SIG_1100]fxols_offhook_disc

*Aug 25 15:55:05.412: htsp_timer2 - 350 msec

*Aug 25 15:55:05.508: htsp_process_event: [0/3/2, FXOLS_CONNECT, E_DSP_SIG_0100]fxols_normal_battery

*Aug 25 15:55:05.508: htsp_timer_stop2

Good Port

Aug 25 15:55:50.300: [0/3/0] get_local_station_id calling num= calling name= calling time=08/25 15:55 orig called=

*Aug 25 15:55:50.304: htsp_process_event: [0/3/0, FXOLS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]

*Aug 25 15:55:50.304: fxols_wait_setup_ack:

*Aug 25 15:55:50.304: [0/3/0] set signal state = 0xC timestamp = 0fxols_check_auto_call

*Aug 25 15:55:50.304: htsp_process_event: [0/3/0, FXOLS_PROCEEDING, E_HTSP_CONNECT]fxols_offhook_connect

*Aug 25 15:55:50.304: htsp_timer_stop

*Aug 25 15:55:50.308: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

*Aug 25 15:55:50.312: htsp_call_bridged invoked

*Aug 25 15:55:50.312: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

*Aug 25 15:55:50.576: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_DSP_SIG_0110]fxols_rvs_battery

*Aug 25 15:55:55.324: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_DSP_SIG_1100]fxols_offhook_disc

*Aug 25 15:55:55.324: htsp_timer2 - 350 msec

*Aug 25 15:55:55.436: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_DSP_SIG_0110]fxols_rvs_battery

*Aug 25 15:55:55.676: htsp_process_event: [0/3/0, FXOLS_CONNECT, E_HTSP_EVENT_TIMER2]fxols_disc_confirm

*Aug 25 15:55:55.676: htsp_timer_stop

*Aug 25 15:55:55.676: htsp_timer_stop2

*Aug 25 15:55:55.676: htsp_timer_stop3

*Aug 25 15:55:55.680: htsp_timer_stop3

*Aug 25 15:55:55.684: htsp_process_event: [0/3/0, FXOLS_REMOTE_RELEASE, E_HTSP_RELEASE_REQ]fxols_offhook_release

*Aug 25 15:55:55.684: htsp_timer_stop

*Aug 25 15:55:55.684: htsp_timer_stop2

*Aug 25 15:55:55.684: htsp_timer_stop3

*Aug 25 15:55:55.684: [0/3/0] set signal state = 0x4 timestamp = 0

*Aug 25 15:55:55.684: htsp_timer - 2000 msec

*Aug 25 15:55:55.956: htsp_process_event: [0/3/0, FXOLS_GUARD_OUT, E_DSP_SIG_0110]

*Aug 25 15:55:57.684: htsp_process_event: [0/3/0, FXOLS_GUARD_OUT, E_HTSP_EVENT_TIMER]fxols_guard_out_timeout

*Aug 25 15:55:57.684: htsp_process_event: [0/3/0, FXOLS_ONHOOK, E_DSP_SIG_0100]

Thanks

Paul

Brandon Svec · ‎08-25-2009

OK, well you should match LS or GS to whatever telco provides which it sounds like is LS in your case. So I would leave that alone. The logs look like you are getting battery reversal as disconnect signal on the good example. Battery reversal is one of two kinds of disconnect signal on loop start lines, but I have never actually seen it in the US. They seem to only do momentary open on ring side here. Are you outside the US?

In any case I think you are going to need to pressure your telco provider to fix and you shouldn't need any more proof then the fact that the trouble follows their line and not your equipment.

Let us know how this works out.

-- please remember to rate and mark answered helpful posts --

Brandon Svec · ‎08-24-2009

From your description I think you have clearly proven the trouble is with the line, not the CPE. I think you just need to pressure the telco provider to get it fixed. Simply making calls in and out with a butt set doesn't prove that a proper disconnect signal is being provided. Since I see these may be ground start lines, you might try reversing polarity on that line and see if that helps. You may also be able to verify disconnect signal yourself with a multimeter. If the outside party disconnects first, the CO changes the tip side of the line from ground to open. You could compare this to a working line and then when you discover the trouble you will have done telco's job for them and you can tell them to fix it ;)

-- please remember to rate and mark answered helpful posts --