FXO Port only answers sometimes

So I have an VWIC 2FXO card here, being serviced by a PVDM-12 in a 1760 (which I realize the PVDM-12 is unsupported but it works fine with the digital lines).

It is connected to an analog line off of our avaya PBX, loopstart, nothing fancy. Here is the config:

voice-port 2/0
connection plar 1000

When I dial in to it, I can see it ringing with my debug:

bottom244#show debug
Voice Port Module session debugging is on
Voice Port Module DSPware overlay debugging is on
Voice Port Module error debugging is on
Voice Port Module signaling debugging is on
Voice Port Module voaal2 debugging (type3  ) is on
Voice Port Module trunk conditioning is on
Voice Port Module tgrm debugging is on

Here is the debug when the phone rings:

*Mar 10 01:35:18.533: htsp_process_event: [2/0, FXOLS_ONHOOK, E_HTSP_IF_INSERVICE]
*Mar 10 01:35:18.533: htsp_process_event: [2/1, FXOLS_ONHOOK, E_HTSP_IF_INSERVICE]
bottom244(config-voiceport)#
bottom244(config-voiceport)#
*Mar 10 01:35:36.803: htsp_process_event: [2/0, FXOLS_ONHOOK, E_DSP_SIG_0000]fxols_onhook_ringing
*Mar 10 01:35:36.803: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_PENDING, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
*Mar 10 01:35:36.803: htsp_timer - 125 msec
*Mar 10 01:35:36.911: htsp_process_event: [2/0, FXOLS_WAIT_RING_MIN, E_DSP_SIG_0100]fxols_ringing_disc
*Mar 10 01:35:36.911: htsp_timer_stop3
*Mar 10 01:35:36.915: htsp_timer_stop
*Mar 10 01:35:36.915: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
*Mar 10 01:35:47.472: htsp_process_event: [2/0, FXOLS_ONHOOK, E_DSP_SIG_0000]fxols_onhook_ringing
*Mar 10 01:35:47.472: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_PENDING, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
*Mar 10 01:35:47.472: htsp_timer - 125 msec
*Mar 10 01:35:47.584: htsp_process_event: [2/0, FXOLS_WAIT_RING_MIN, E_DSP_SIG_0100]fxols_ringing_disc
*Mar 10 01:35:47.584: htsp_timer_stop3
*Mar 10 01:35:47.584: htsp_timer_stop
*Mar 10 01:35:47.584: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
*Mar 10 01:35:48.462: htsp_process_event: [2/0, FXOLS_ONHOOK, E_DSP_SIG_0000]fxols_onhook_ringing
*Mar 10 01:35:48.462: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_PENDING, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)
*Mar 10 01:35:48.462: htsp_timer - 125 msec
*Mar 10 01:35:48.574: htsp_process_event: [2/0, FXOLS_WAIT_RING_MIN, E_DSP_SIG_0100]fxols_ringing_disc
*Mar 10 01:35:48.574: htsp_timer_stop3
*Mar 10 01:35:48.574: htsp_timer_stop
*Mar 10 01:35:48.574: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_IN)

So I know the router is seeing the phone ring, but why doesn't it pick up all the time? It only picks up using PLAR 1 in 10 times. Weird? Any ideas?

Find more posts tagged with

Comments

Jollycork

your FXO analog line off your PBX gives it dialtone, voltage, loopstart, on/off hook signaling [basically an FXS]?

does the phone at extension 1000 ring?

I take it your call manager is running off the 1760 so might post your dial peer config for your
inbound POTS calls or simply post the run config.

Netwurk

A mod should probably move this to CCVP as you're likely to get better answers there. Troubleshooting an FXO port hooked to a PBX is an advanced topic IMO.

hypnotoad

Yeah, the phone at ext 1000 rings about one out of ten times. The PBX supplies voltage, ring, loopstart, all that good stuff. I figure the 1760 should answer the phone since it sees the ringing coming in. Weird.

Jollycork

without more to go on, shug....

could be your DSP ... but ... have you tried using a secondary number on that extention ephone-dn that is the number the PBX assigns to the line. Don't think that would make a difference unless your using the connection plar opx but worth a shot.

The 1760 should direct the call to the extension every time a call come into the FXO port.

pitviper

Try the "no battery-reversal" command under the voice-port. I’ve used it to fix disconnect issues (typically when piggybacking off of a telco IAD) but it may be worth a shot.