IP trunks, 1 way audio from 8300 to G3si

[Bee77]

I have a customer in San Diego that i have translated some IP trunks to their Mexico City location. The IP trunks come up fine, i can place calls to Mexico City from SD, never fails except for the audio on the Mexico City side. I'm dumbfounded at this moment, because everything is programmed the way it needs to be and the way i always have but Mexico City can never hear the audio however SD can always hear audio no problem. At first, one would think it's an issue on the Mexico side, however, when doing some Layer3 (i believe) debugging or traces, we found that the 8300 wasn't sending the audio packets of considerable file size. The file size was only 1k, which obviously isn't the whole file. Can anyone shed some light on this why the 8300 isnt' sending the audio packets or packets of greater size? i'm running g.729 to Mexico because of bandwidth limitation and everythign works fine except for the audio packets not being sent in larger file sizes like it should.
-Wes

 

[nohuhu]

Bee77,

it seems to me that you have codec mismatch.
check what network region each location belongs to. check ip-network-map for correct mapping of ip addresses to network regions. check ip-network-region settings for inter-region ip-ip direct audio setting and inter-region codec set mapping. then check the codec set if it allows g.729 to be used. by default codec set #1 is used and it doesn't include g.729, only g.711.

 

[Rod25]

I had an issue similiar to this and it ending up being a firewall issue...

 

[Bee77]

well, i did populate the IP-Network-mapping table with the IP address for the local machine in there telling it that it was part of network region 1 which had codec 1 assigned, but in that same network region, i'm telling NR 1 to talk to NR 2 via codec 2 which is g.729 on the third page.
NR 2 is defined as Codec 2 for the Mexico Location. All the other settings that dwalin specifies are set. I don't think it was a codec mismatch because the trace actually told me that initially when i was setting it up and i fixed that. the call wouldn't even complete or go thru because of the initial codec mismatch.
If it's a firewall issue, how come when my guy in the router watching layer 3 packets pass only saw a 1k audio file attempt to pass, which really just isn't large enough.
i hope it had to do with the network mapping table. I haven't tried a call yet, but if that was it, i'll be damned!

 

[Bee77]

ok, so i found my own problem, which always seems to be the case because i seem to do unique things sometimes that no one else can help me on.
i guess i'll tell what my problem was too so that you all know and learn.
i went into the media gateway of the g700 and (in the end) looked at my "show ip route mgp" which showed:
192.168.50.0 255.255.255.0 192.168.50.x (x being the Ip address of the g700 inband interface. So it was being told to look to the g700 as the "gateway".
i usually do this so i dont' know if i had an off-day, but i tried a traceroute to the Medpro address from the media gateway before i did a change and it didn't give me any information as if it wasn't reachable.
So i changed the IP route to reflect another route
0.0.0.0 0.0.0.0 192.168.50.1 (the last IP address being the actual gateway/ router for the customer) which is usually what i do anyway. Once i did that and the traceroute for 30 hops was successful. I tested a call and audio was heard both ways, so it's fixed. thanks anyway for your response. NO matter how good of definity programming you know or do, one really has to know the g700 commands to really get things to work properly.
-Wes