VG224

Unanswered Question
Sep 26th, 2010

Guys,

i have a vg224 that is servicing some modems for a customer that does financial transactions. im getting reports that the customer is having failed transactions intermittently.

the network is as follows:

CISCO 3800 with PRI terminated with  h323 dial peers pointing to the vg224 with pots dial peers on the vg which in turn connects to the modems.

its working but intermittently so im not sure exactly where to start troubleshooting. we have tried to recreate the issue without success but before the vg was put into place the issue was not present.

does anyone have any similar setup that is working?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.7 (3 ratings)
Loading.
Christopher Graham Sun, 09/26/2010 - 17:46

First...check for slips/errors on the PRI (show controllers t1).  Clocking issues will kill fax/modem transmissions.

Second, what is your modem config under 'voice service voip'?  Modems can only transmit via passthrough, so make sure you have the following on the 3800 AND VG224:

voice service voip

modem passthrough nse codec g711ulaw

Also, try adding 'fax rate disable' under the POTS dial peer to make sure the VG does not attempt fax relay.

If the issue persists, post your configs and IOS versions

a.gooding Sun, 09/26/2010 - 18:21

Hi there,

appreciate the very quick reply.

ive adjusted the configurations for disable fax relay.

also see attached edited configurations for both the router as well as the VG.

to be honest its the first time ive configured the vg for this so im a little at a lost as to go about troubleshooting this specific intermittent issue.

Steven Holl Mon, 09/27/2010 - 06:22

Do you see the call go to a MODEMPASS state with 'sh call active voice br' when the call is up?

Can you collect 'sh call history voice br' and 'debug voip rtp sess name' after a transmission with an issue?

a.gooding Mon, 09/27/2010 - 06:33

Steve,

i managed to capture this a while ago. im currently arranging with the customer to see if we can replicate the issue. Also attached is a recent call history. Again it is very intermittent so i just want to make sure that the config is fine. im leaning towards some dial-peer issue i might be having or it could be a case of not all of the lines on the modems are working.

the customer did also indicate that since we placed this VG on the network they have been getting terrible response times in some instances and then some extra ordinarly great response times in other instances. this has me thinking dial-peer or timing issues

Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
3EA3 : 19056 644091020ms.1 +750 pid:20 Answer 4528748 active
dur 00:00:11 tx:634/100972 rx:602/95852
IP :17484 SRTP: off rtt:2ms pl:8050/0ms lost:0/0/0 delay:65/65/65ms g                            711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a  MO                            DEMPASS nse buf:0/0 loss 0% 0/0  last 0s dur:0/0s

3EA3 : 19057 644091030ms.1 +730 pid:1 Originate 6703 active
dur 00:00:12 tx:634/100972 rx:602/100668
Tele 2/0 (19057) [2/0] tx:11140/11140/0ms g711ulaw noise:-16 acom:6  i/0:-15/-1                            3 dBm

Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2

Steven Holl Mon, 09/27/2010 - 06:41

At least that side looks okay.  No packet loss, and switched to MODEMPASS.

You should also get that output from the other gateway for a failure and make sure that side also looks okay.

What modem protocol do these modems use to communicate?  It's real modem tones, and not rapid DTMF pulsing, right?  Do you know what speed the modems use?  MODEMPASS supports up to V.90, which is 33.6.  If it is a 56k modem (V.92) you may have issues, and I'd look at getting the endpoints forced to a max of V.90 speeds.

Steven Holl Mon, 09/27/2010 - 06:43

Also, not sure what this call was for, but this one had some jitter; doesn't look like a modem call, though, at a glance:

3E92 : 19049 643918470ms.19047 +690 +17880 pid:1 Originate 6703
dur 00:00:17 tx:892/142252 rx:862/144348 10  (normal call clearing (16))
Telephony 2/0 (19049) [2/0] tx:16330/16330/0ms g711ulaw noise:-29dBm acom:20dBm
  long duration call detected:n long dur callduration :n/a timestamp:n/a3E83 : 19046 643815720ms.19048 +2580 +130220 pid:20 Answer 4517476
dur 00:02:07 tx:6507/1041120 rx:6038/961787 10  (normal call clearing (16))
IP 10.80.32.8:19074 SRTP: off rtt:4ms pl:118660/10ms lost:0/12/1 delay:55/55/105ms g711ulaw TextRelay: off
  media inactive detected:n media contrl rcvd:n/a timestamp:n/a
  long duration call detected:n long dur callduration :n/a timestamp:n/a
a.gooding Mon, 09/27/2010 - 07:00

Those are actually the same questions ive been asking the customer since the issue. i think they are motorola modems but they should be getting back to me with some details on the modems.

im not too sure what that call is though. Its not a modem call but if i recall they did have a single fax machine terminated on this vg as well. its probably that and i advised them that all fax rates have been disabled so that fax machine will not work right now in any event.

ill see if i can schedule some testing and get the details of the modems.

Steven Holl Mon, 09/27/2010 - 07:32

Just to clarify your item here:

im not too sure what that call is though. Its not a modem call but if i recall they did have a single fax machine terminated on this vg as well. its probably that and i advised them that all fax rates have been disabled so that fax machine will not work right now in any event.

If you have 'fax rate disable' configured, but modempass is configured, all faxing will still work.  We'll switch to a modempass state for the fax calls, for sg3 and low speed faxes.

a.gooding Wed, 09/29/2010 - 11:16

The customer advised that the baud is 1200 for thier modem bank (Netkit Smartnet ACP 550).

is there anyway to match that speed?

also, remember, the call comes into a main 3800 router via a E1 circuit. i then have a pots dial-peer to match the numbers and then a VOIP dial-peer to go to the VG.

i noticed i didnt have modem passthrough on the voip DP on the main router so i just enabled it.

would this make a difference?

Steven Holl Wed, 09/29/2010 - 11:28

Yeah you want to have modem passthrough enabled on both the PSTN and the VG224 gateways.  You should bring up a test call and make sure each side shows 'MODEMPASS' in 'sh call active voice br' for that call leg, and that there is no packet loss or latency throughout the transmission.

a.gooding Wed, 09/29/2010 - 11:36

yeah im setting up the call with the customer now.

one thing i was thinking.

the number coming in is always one number that is the pilot tied into a trunk - 6703. this passes to the VG but on the VG i have all the associated ports in a trunkgroup and set to sequential. should i put the station number on each fxs? (or am i confusing myself)

Steven Holl Wed, 09/29/2010 - 11:52

Not sure what you're getting at with that last question.  Station-id is just for CLID purposes.  If these are SCCP controlled FXS, you shouldn't need that as it will inherit it from the DN.

a.gooding Wed, 09/29/2010 - 12:01

FYI

this isnt integrated with the call manager at all.

the last question was probably my misunderstanding.

currently on the call with the customer and i have three debugs running

voice ccapi , vpm sig and modem

should i enable anything further?

ill post the debugs as soon as they are finished. i asked them to initiate about 20 transactions and see if they get the issue.

Steven Holl Wed, 09/29/2010 - 12:15

Get 'debug voip rtp sess name' from each side.  You should see 192 NSEs sent and received on each side which is how we switch to modempass.

If anything fails, get 'sh call history voice br' after a failure from each side.  Look for packet loss/latency, and make sure that the call shows it went into a MODEMPASS state.

a.gooding Wed, 09/29/2010 - 12:41

just missed that debug. we did 20 transactions and all were sucessful.

for each i also noted the modempass on each occasion. there were two transactions that took a little longer than usual and i noticed that the FXS went off hook then on hook, went to another port then went back to the original port and completed the transaction. this still didnt give any comm error and the transaction went through fine (although it took a while).

My mistake is that i shouldnt have adjusted the dial-peer on the router to allow modempass before the testing. im hoping that this is the fix so ive asked them to monitor the backend and advise if they are seeing any duplicate transactions after today. Below is what i was collecting as a sample of the calls. What's the lost 3/0/0? Were those failed calls?

media inactive detected:n media contrl rcvd:n/a timestamp:n/a  MODEMPASS nse bu
:0/0 loss 0% 0/0  last 0s dur:0/0s

18D4 : 8739 16435160ms.1 +760 pid:310 Originate 6703 active
dur 00:00:03 tx:207/32652 rx:204/32172
IP 10.80.32.20:16980 SRTP: off rtt:0ms pl:1945/5ms lost:3/0/0 delay:105/105/105
ms g711ulaw
media inactive detected:n media contrl rcvd:n/a timestamp:n/a  MODEMPASS nse bu
f:0/0 loss 0% 0/0  last 0s dur:0/0s

Steven Holl Wed, 09/29/2010 - 12:44

That means you dropped 3 RTP packets in the 10.80.32.20--->[device the command was taken off of] direction.  That could be enough to cause a modem transmission issue.

Actions

This Discussion