Learn in 10 mins or less my 4 effective techniques, when troubleshooting “One Way Talk Path”.
By the end of this post you will know 4 methodologies for troubleshooting “one way talk path” issues. From physical connections, to switching, IP Network Regions, IP Network Maps, and much more.
Just recently I found myself facing this predicament, where the customer was complaining of “one way talk path” issues whenever someone called their local main number.
What made it more interesting, was the fact that outgoing calls were working just fine.
This site had a branch gateway connected back to a Core phone-switch located miles away. When I arrived to the site, I tried duplicating the problem and found that only incoming calls to the local number was experiencing the “one way talk path” problem.
I developed these 4 steps to help you along the way.
- 1.- Data Gathering
- 2.- Start with the basics
- 3.- Avaya IP Forms
- 4. The Solution
- *. Quick Tip
1.- Data Gathering
- Site Documentation
To be more efficient in your data gathering, ask for the PBX and Switch Configurations.
The PBX Configuration Forms normally contains PBX IP Addresses such as Call Server, Media Processors, Control Lans (CLANs), Voice VLAN, etc. This particular customer had the wrong subnet mask assigned to the VoIP network.
The Switch Configuration Forms usually have IP Address Schemes of both Voice and Data Topologies; the key with this document it’s identifying the Default Gateways, Firewalls, Routers and NAT Devices.
Both of these documents should list the main site VoIP components, Branch Gateways, as well as Network devices.
2.- Start with the basics
Here you are employing the basics of troubleshooting the building wiring, phone firmware, and port allocation.
Building Wiring – Using a CAT5/6 tester check the length, and connectivity of the cable. It is important to understand how the switch port is configured. (e.g. 100 Megs or 1 Gig).
Patch Panels and Patch Cords – It is always good to test from point A to point B; including the patch cords and patch panels. You can do this by utilizing the existing cords already in-use.
Switch Port Speed and Duplex Settings – If possible disabled auto-negotiation, and hard code the speed to 100/Full. These settings should be checked at the Media Gateway and Phone level.
Firmware – If this is a new deployment, or upgrade, always check with the compatibility matrix from Avaya. Always read the Product Notices, and related updates.
Port Allocation – Always check that End-Points are connected to their designated network switch ports (e.g. VLAN Members).
3.- Avaya IP Forms
Now that you have confirmed that the wiring, and switch configurations are correct, it is time to move to the next step, IP Network Regions, IP Network Maps, and Survivable Forms.
IP Network Regions (NRs) – This is a feature of Avaya Communication Manager that allows for resource allocation, based on site location. e.g. IP Phones, Media Gateways, IP Trunks, MP80/MedPros, CLANs, etc; all of which could be grouped in the same region.
Other benefits of Network Regions are the ability of setting QoS, Codec Sets, and WAN Bandwidth. To learn more about Hairpinning and Shuffling refer to this post= http://www.ipservtechnologies.com/voice-transcoding/
Inter-region IP-IP Direct Audio (Media Shuffling). This will allow calls to stay in the TDM bus, and not use the Media Processor’s resources. If you feel that you don’t have enough, then switch this to YES.
UDP ports and TCP ports ranges will need to be added to a firewall rule if using one between branches.
IP Codec Set – If bandwidth is an issue, it is very important to take into consideration how will the packets be compressed, by using the right Codec typed; from G.729A to G.711MU.
These rules are set from 1 thru 7, and they can be manipulated under the IP-Codec-set forms.
IP-Network-Map Form – This form allows the assignment of the Network Regions to each individual network/subnet. If left blank, the system will assigned the default NR 1.
In my case, that was one of the main issue; all the resources were assigned automatically to the main site using NR1; instead of using its local resources using NR5.
Once I was able to clean up the system, by assigning the correct subnet mask, IP Network Region, Codec-sets, I then asked the IT Engineer to verify Firewall policies, VLAN Port memberships, Route Tables. They came back and said that everything was configured correctly and that I needed to do packet captures, which I knew wouldn’t help me resolve the problem.
4.- The Solution
After a handful of discussions, it turned out to be a NAT issue in the firewall. They had a NAT entry for each IP route there was. Once they turned this feature off, calls started to work just fine. In reality, all of these steps mentioned above are crucial for a good implementation.
*.- Quick Tip
The reason I felt very confident that it wasn’t our issue, was because I had simulated calls by bypassing the data infrastructure.
To do this, follow these steps=
- 1.- Grab an IP Phone and assigned it a static IP Address (the IP Address has to be in the same range as the Call Server)
- 2. – Subnet mask= same as your Call Server
- 3. Call Server IP= Your local PBX IP Address
- 4. Router= 0.0.0.0
- 5.- Call Server Port= 1719
- File Server= 0.0.0.0
Leave the rest of the settings the same.
Using a power brick, connect one patch cord to the phone, and the other directly to the Media Gateway’s LAN port. Once connected, the phone should be able to register to the local Call Server, allowing you to run test calls, using the local resources.
Please note: I reserve the right to delete comments that are offensive or off-topic.