Solved: Issue with ground start lines and VIC2-4FXO

JAIME KILPATRICK · ‎06-06-2012

To anyone with a lot of experience out there:

I cannot seem to make outbound calls work through my voice gateway. Below are the details of my dilemma.

I am using csim start command via telnet.

I have the following gateway hardware.

2811 w/ PVDM2-16 and a VWIC2-4FXO card.

IOS version is 15.0(1)M5

Voice-ports 0/2/0,0/2/1,0/2/2 have groundstart lines plugged into them. Voice port 0/2/3 has no configuration and is shut down.

These lines have been verified to indeed be ground start lines. I took my buttset to them personally and could only obtain dial tone when I touched a ground wire (That I had attached to the screw that secures the VWIC2-4FXO card into the chassis to the ring side of each line. I would then get dial tone and could place a call to my cell phone (It's a local 7 digit calling area so I dialed 7 digits)

I have a dial-peer setup as such

dial-peer voice 8888 pots

destination-pattern 9T

forward-digits 7

port 0/2/0

I am accessing the gateway via telnet (as ssh does not work with the csim start command)

I have debug vpm all turned on with monitor terminal

Here is the output when the csim start command is issued.

Jun 6 16:21:26: htsp_timer_stop3 htsp_setup_req

Jun 6 16:21:26: htsp_process_event: [0/2/0, FXOGS_ONHOOK, E_HTSP_SETUP_REQ]fxogs_onhook_setup

Jun 6 16:21:26: [0/2/0] set signal state = 0x0 timestamp = 0

Jun 6 16:21:26: dsp_set_sig_state: [0/2/0] packet_len=12 channel_id=128 packet_id=39 state=0x0 timestamp=0x0

Jun 6 16:21:26: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_BUSY, TGRM_CALL_VOICE, TGRM_DIRECTION_OUT)

Jun 6 16:21:26: htsp_timer - 10000 msec

Jun 6 16:21:26: htsp_process_event: [0/2/0, FXOGS_WAIT_TIP_GROUND, E_DSP_SIG_0110]

Jun 6 16:21:26: [0/2/0, FXOGS_WAIT_TIP_GROUND, E_DSP_SIG_0110] -> ERROR: INVALID INPUT

Jun 6 16:21:26: htsp_process_event: [0/2/0, FXOGS_WAIT_TIP_GROUND, E_DSP_SIG_0110]

Jun 6 16:21:26: [0/2/0, FXOGS_WAIT_TIP_GROUND, E_DSP_SIG_0110] -> ERROR: INVALID INPUT

Jun 6 16:21:36: htsp_process_event: [0/2/0, FXOGS_WAIT_TIP_GROUND, E_HTSP_EVENT_TIMER]fxogs_offhook_disc

Jun 6 16:21:36: htsp_timer_stop

Jun 6 16:21:36: [0/2/0] set signal state = 0x4 timestamp = 0

Jun 6 16:21:36: dsp_set_sig_state: [0/2/0] packet_len=12 channel_id=128 packet_id=39 state=0x4 timestamp=0x0

Jun 6 16:21:36: htsp_timer - 2000 msechtsp_release_req: cause 16, no_onhook 0

Jun 6 16:21:36: htsp_process_event: [0/2/0, FXOGS_ONHOOK, E_HTSP_RELEASE_REQ]fxogs_onhook_release

Jun 6 16:21:36: htsp_timer_stop2

Jun 6 16:21:36: htsp_timer_stop3

Jun 6 16:21:36: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_IDLE, TGRM_CALL_VOICE, TGRM_DIRECTION_OUT)

Jun 6 16:21:36: flex_dsprm_close_cleanup

Jun 6 16:21:38: htsp_process_event: [0/2/0, FXOGS_ONHOOK, E_HTSP_EVENT_TIMER]

Jun 6 16:21:38: [0/2/0, FXOGS_ONHOOK, E_HTSP_EVENT_TIMER] -> ERROR: INVALID INPUT

I've scoured the internet looking to make heads or tails of this and the only thing I've come up with is there are some related Cisco bugs that seem to point in this direction however, I have performed a show voice dsp and I get the following:

*DSP VOICE CHANNELS*

CURR STATE : (busy)inuse (b-out)busy out (bpend)busyout pending

LEGEND : (bad)bad (shut)shutdown (dpend)download pending

DSP DSP DSPWARE CURR BOOT PAK TX/RX

TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABRT PACK COUNT

====== === == ========= ========== ===== ======= === == ========= == ==== ============

*DSP SIGNALING CHANNELS*

DSP DSP DSPWARE CURR BOOT PAK TX/RX

TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABRT PACK COUNT

====== === == ========= ========== ===== ======= === == ========= == ==== ============

C5510 001 01 {flex} 26.3.9 alloc idle 0 0 0/2/0 02 0 110/0

C5510 001 02 {flex} 26.3.9 alloc idle 0 0 0/2/1 06 0 125/0

C5510 001 03 {flex} 26.3.9 alloc idle 0 0 0/2/2 10 0 163/0

C5510 001 04 {flex} 26.3.9 alloc idle 0 0 0/2/3 14 0 55/0

------------------------END OF FLEX VOICE CARD 0 ----------------------------

I believe the firmware should be new enough to have resolved the issue.

If someone could possibly provide me with a little direction here that would be great. Below are summaries of the tests I've done.

Configured as loopstart, it complains of a power denial which I think would be normal since there is no connection until the grounding has been established. Please correct me if I'm wrong btw.

Jun 6 16:31:26: htsp_timer_stop3 htsp_setup_req

Jun 6 16:31:26: htsp_process_event: [0/2/0, FXOLS_ONHOOK, E_HTSP_SETUP_REQ]fxols_onhook_setup

Jun 6 16:31:26: [0/2/0] set signal state = 0xC timestamp = 0

Jun 6 16:31:26: dsp_set_sig_state: [0/2/0] packet_len=12 channel_id=128 packet_id=39 state=0xC timestamp=0x0

Jun 6 16:31:26: TGRM: reg_invoke_tgrm_call_update(0, 2, 0, 65535, 1, TGRM_CALL_BUSY, TGRM_CALL_VOICE, TGRM_DIRECTION_OUT)

Jun 6 16:31:26: htsp_timer - 1300 msec

Jun 6 16:31:26: htsp_process_event: [0/2/0, FXOLS_WAIT_DIAL_TONE, E_DSP_SIG_1100]fxols_power_denial_detected

Jun 6 16:31:26: htsp_timer2 - 1000 msec

Jun 6 16:31:26: htsp_timer_stop

Jun 6 16:31:27: htsp_process_event: [0/2/0, FXOLS_WAIT_DIAL_TONE, E_HTSP_EVENT_TIMER2]fxols_power_den_disc

Jun 6 16:31:27: htsp_timer_stop

Jun 6 16:31:27: htsp_timer_stop2

Jun 6 16:31:27: [0/2/0] set signal state = 0x4 timestamp = 0

Jun 6 16:31:27: dsp_set_sig_state: [0/2/0] packet_len=12 channel_id=128 packet_id=39 state=0x4 timestamp=0x0

Jun 6 16:31:27: mars_flex_dsprm_current_codec_comp:DSP:0 FLEX Complexity Codec htsp_release_req: cause 34, no_onhook 0

Jun 6 16:31:27: htsp_process_event: [0/2/0, FXOLS_ONHOOK, E_HTSP_RELEASE_REQ]fxols_onhook_release

I've reverse polarity on the circuit and the debug simply tells me that the polarity is reversed so I know that the circuit is correct as is. (It's not complaining about it.)

Again, I have tested the lines and they work just fine with the buttset using a ground to the ring side from the router chassis.

I'm preplexed at this point. Any help would be greatly appreciated.

Thanks,

Jaime

acampbell · ‎06-07-2012

Jaime,

Can you try

Router# configure terminal 
Router(config)# voice-port x/y/z
Router(config-voiceport)# shutdown
Router(config-voiceport)# groundstart auto-tip delay
Router(config-voiceport)# no shutdown
Router(config-voiceport)# exit
 
 Retest

Regards,
Alex.
Please rate useful posts.

Regards, Alex. Please rate useful posts.

View solution in original post

Tracy Larson · ‎06-06-2012

config t

voice-port 0/2/0

signal ground-start

shut

no shut

Tracy Larson · ‎06-06-2012

If you already have that, make sure you did the shut no shut. The ports wont change signalling properly without it.

JAIME KILPATRICK · ‎06-07-2012

Tracy,

Thanks for the reply. Unfortunately, I had shut/no shut these voice ports repeatedly. The only thing I have yet to attempt is a full reboot of the gateway. That will be this evening during a maintenance window. In the mean time however I have done one thing that completely blows my mind away. Get this...

I have a telnet session to the gateway and run the csim start command. In a second session I ran the command test voice port 0/2/0 detector tip-ground on during the waiting period for the ground and guess what, the call rings out and completes to my test phone. Essentially, what I believe the test command does is force the gateway into thinking that it received the ground response from the CO. At this point I haven't determined if the gateway is simply not detecting the tip-ground acknowledgement or if the CO just isn't sending it. I guess that's a test I need to conduct at this point. Anyone have any tips on how to do that? If I use a buttset on these lines it works fine since the buttset doesn't care about a tip-ground acknowledgement. Does anyone have a solid process for testing this scenario?

clileikis · ‎06-07-2012

Hi there,

I've had the same issue a couple weeks ago, either rebooting the gateway or recreating the voip dial-peer (or removing the port command/putting the port back on) after converting from loop/ground start on voice-ports solved the problem.

HTH,

Chris

JAIME KILPATRICK · ‎06-07-2012

Chris,

Thanks for the reply. I just tried to do what you suggested (aside from the gateway reboot since I have to do that under a maintenance window) and it didn't work. I removed all dial-peers related to the 0/2/0 voice port. I even removed the trunk group command from the voice port. I shut/no shut the voice port. I rebuilt a dial-peer for that port and no luck. I'm starting to think that the CO isn't sending me a ground acknowledgement. Maybe their equipment simulates GS but doesn't simulate it according to the GS standard kind of like how the old VIC-4FXO cards used to no look for the acknowledgement? If so, does anyone know of a command in IOS to have the router not wait for that?