Media Gateway G450 Trace

[BoyofBlue09]

We are having some intermittent problems with an loud echoing type sound on outgoing calls when the call is ringing out. As soon as the call is connected the issue clears. I'm assuming it could be a gateway problem but wasn't sure how to trace which gateway a call is being initially set up on. We have 10 gateways on site. Can anyone please advise how I can trace this or if they have had a similar problem before and if you resolved it? Thanks

 

[kyle555]

Maybe it's the carrier? You can list trace the station making the call and see what channel it picks to go out. Presuming PRI, that'd tell you what gateway it was.

Presuming you're getting ringback from the gateway that has the PRI your call is going out on, you'd think nothing changed relative to the RTP path between ringback and talking.

If you're able to reproduce the issue, and suppose you had a phone on the other end that would ring indefinitely, would you find that it's the first few seconds of ringback and then it clears up and rings normally indefinitely until answered? Or would you find that it only clears up when answered?

There are some commands to check RTP in the G450.
rtp-stat-service will turn it on
show rtp-stat sesions will print sessions it's logged
show rtp detailed XXXX where that's the ID will show you good information.

Now, that's only relevant to the RTP received by the G450. It has no way of knowing how the RTP it sent to the IP phone was received on the phone side.
I believe the "remote statistics" part is for other gateways that know about it. You can enable some media stats in the network regions or sys-param ip-options but you can't specify more than 1 IP to have the phone send RTCP for.

You could just packet capture the phone and see if the first few packets are sputtery/jittery.

Off hand, if I wanted to blame it on a network problem, I'd suggest seeing if there's H323 inspection on a firewall. It can make it so all RTP ports are closed and only once it sees H323/H248 signaled messages setting up a RTP stream between IPA:2000 and IPB:2001 does it open the ports. It could account for dead air, but maybe something on a 'network intelligence' side of things is taking that second to kick in. A wireshark of the IP phone having the problem and a quick RTP stream analysis might yield some clues.

g450-1-001(super)# show rtp sessions

ID    QoS Start date and time End Time Type            Destination
----- --- ------------------- -------- --------------- ---------------------------------------
54006     2019-04-17,10:06:47        -           G711U                             10.1.10.9


g450-1-001(super)# show rtp de 54006

Session-ID: 54006
Status: Active, QOS: Ok, EngineId: 10
Start-Time: 2019-04-17,10:06:47, End-Time: -
Duration: 01:29:18
CName: gwp@10.1.18.51
Phone:
Local-Address: 10.1.18.51:2120 SSRC 854417224
Remote-Address: 10.1.10.9:36202 SSRC 1879088995 (0)
Samples: 1071 (5 sec)

Codec:
G711U 200B 20mS Off, Silence-suppression(Tx/Rx) Disabled/Disabled, Play-Time 5360.840sec, Loss 0.0% #0, Avg-Loss 0.0%, RTT 61mS #0, Avg-RTT 61mS, JBuf-under/overruns 0.0%/0.0%, Jbuf-Delay 12mS, Max-Jbuf-Delay 32mS

Received-RTP:
Packets 268049, Loss 0.0% #0, Avg-Loss 0.0%, RTT 9mS #0, Avg-RTT 9mS, Jitter 0mS #0, Avg-Jitter 0mS, TTL(last/min/max) 248/248/248, Duplicates 1, Seq-Fall 4, DSCP 46, L2Pri 0, RTCP 1131, Flow-Label 0

Transmitted-RTP:
VLAN 0, DSCP 46, L2Pri 0, RTCP 1079, Flow-Label 0


Remote-Statistics:
Loss 0.0% #0, Avg-Loss 0.0%, Jitter 0mS #0, Avg-Jitter 0mS

Echo-Cancellation:
Loss 0dB #1070, Len 0mS

RSVP:
Status Unused, Failures 0

Done!