We have changed IP addressing of our VoIP phones from Public Range to Private 10.x.x.x. Our Main Site IP addresses change took place before I started so don't know if some configuration change was made on CUCM 6.1.3 to make it work. I changed the IP addressing of Voip Phones on one of the Remote site connected to main site (where Publisher / Subscriber resides). At the remote site I enabled the DHCP scope to allocate IP addresses to IP phones. I created the voice vlan and configured the correct voice vlan to switchport IP phone is connected. Phone gets the IP from DHCP scope and also gets correct parameters such as gateway,option 150 etc. Phone gets registered to Subscriber call manager. I have checked the IP cache and I see the session to port 2000.When
I call from our main site to phone assigned to new VLAN ,Remote site phone can hear us but we can't hear them and issue remains the same when call is initiated from remote site to phone's on other VLAN's or sites.
At remote site I installed another phone and assisgned the switchport to new voice vlan then both new phones can communicate to each other but same issue in communication to phones on other vlans / locations
I have checked all the access-lists and FWSM but couldn't see any issues ....ANY IDEA what's causing one way communication issue cos previous team changed the IP addresses on our main site but no such one way communication issue. Interesting thing is that I picked one of the free subnet from Main site IP address planning structure and implemented at remote site and had no issues with communication at all
You can do a simple test:
1) Make a test call and make sure the call is connected
2) While the call is connected (and you got one-way audio), press the question mark (?) button twice on the phone. It'll show you the realtime statistics of transmitting packets and receving packets.
3) Do the same thing on the other phone.
4) Compare the statistics on both sides, you should be able to tell which phone was sending packets, which phone was not receiving it.
If one side is sending packets, the other side is not receiving it, get a network engineer to trace the path.