CME with 2 branch offices, branch offices off-net 2way audio on-net 1way audio

[Michael Durham]

I have a CME 12.0 with two branch offices.  Within the main office, on-net and off-net calls are perfect.  Uses within the office can call each other and hear each other as well as calling other businesses and cell phones.

We have two remote site locations and there is a DMVPN tunnel between the sites. When a user at either remote site calls another business or a cell phone, both parties can hear each other and the caller ID is the main office's.  So far, so good.  BUT, when a remote site tries to call an internal main office extension, there is only one-way audio from the main office to the remote site.  The main office user cannot hear the remote site user.  This happens for both remote sites.

The main office has a static IP address as well as one of the branch offices.  The second branch office is provided a dynamic IP address by the cable company. I tried removing one of the branch offices but that did not solve the issue at the other location.  It seems that the RTP packets from the remote location are getting lost.  I am not good with WireShark or I would post its info.

The main office phones are on the 192.168.200.x network and the remote offices have static IPs assigned to the phones at 192.168.200.21 and 192.168.200.31.

Any ideas why we are getting one-way audio to the remote offices?

CME Main office Router tunnel config
interface Tunnel200
description mGRE - DMVPN Tunnel for Mat Remote User
bandwidth 100000
ip address 172.20.0.1 255.255.255.248
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp network-id 999
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile CUSTOMER-IPSEC shared
ip route 0.0.0.0 0.0.0.0 14.77.22.33
ip route 192.168.100.20 255.255.255.255 172.20.0.2
ip route 192.168.200.20 255.255.255.255 172.20.0.2
ip route 192.168.200.21 255.255.255.255 172.20.0.2
ip route 192.168.200.30 255.255.255.255 172.20.0.3
ip route 192.168.200.31 255.255.255.255 172.20.0.3
end

BRANCH ONE Tunnel

interface Tunnel200
description DMVPN mGRE tunnel from Customers Remote Site/Home User to Office HQ
bandwidth 1000000
ip address 172.20.0.2 255.255.255.252
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map 172.20.0.1 14.77.22.45
ip nhrp map multicast 14.77.22.45
ip nhrp network-id 999
ip nhrp nhs 172.20.0.1
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile CUSTOMER-REMOTE-USER-IPSEC
no ip route-cache
ip route 192.168.100.1 255.255.255.255 172.20.0.1
ip route 192.168.200.1 255.255.255.255 172.20.0.1
ip route 0.0.0.0 0.0.0.0 dhcp
end

[Nithin Eluvathingal]

This could be a routing issue, check you VPN configuration  if it has reachability to your phone subnets.

[Roger Kallberg]

There is quite likely not IP connectivity between endpoints at the central office and the remote offices. The RTP stream goes directly between the endpoints, if they do not have connectivity that’s why you have no sound in one direction. Check the routing of traffic and DMVPN configuration.

Also your IP addressing seams to be odd as you have phones at the remote location in the same IP range as at your central office. I’m by far no expert in DMVPN, but that’s another thing I would advise you to look into.

[Michael Durham]

There is IP connectivity between the offices as the CME HQ router is the only CME in the system, the branch offices are using a Cisco 1921 router and it does not run CME.  

The remote locations off-net calls are going through the HQ CME system and working perfectly.  Its just on-net calls not working.  

From each remote location, I can ping the HQ CME system at 192.168.200.1 and any other device on the 192.168.200.x network as well as devices on the 192.168.100.x network.

[Roger Kallberg]

If you have a computer connected in each vlan where you have your phones, with the same IPs as the phones have now, can these ping each other? Aka one connected to the central network and another connected to the remote network.

[Michael Durham]

From each remote location, I can ping back to the HQ office but I cannot ping from one remote location to another. 

HQ CME is 192.168.200.1 and CUE is 192.168.200.2 and an IP phone is 192.168.200.51

REMOTE location is 192.168.200.30 and IP phone is 192.168.200.31

From HQ I can ping 192.168.200.30 & 31

From REMOTE I can ping 192.168.200.1, 2, and 51

I cannot ping the second remote location 192.168.200.20 or 23

[Roger Kallberg]

What is the reason for why all sites share the same IP network? This is quite unorthodox.

[Nithin Eluvathingal]

You need to rectify the issues related to your network. As @Roger Kallberg mentioned RTP stream is between the phones, you need to make sure that there is two way reachability between the phones. 

[Michael Durham]

I do not know how many times I need to say this but THERE IS connectivity from the HQ CME system to the remote phone and I can ping both ways.  ALSO, If the remote site can make an off-net call and there IS two-way audio then they routing is not the issue since ALL calls are processed by the HQ CME system.  The remote sites DO NOT have any routers that can run CME.

As far as the remote phones having an IP on the same network, why wouldn't this work?  Each site only has one phone and it is statically configured. And since the phones are run by the HQ CME system ONLY, again, I ask why is this wrong?  

If the remote sites had their own CME system or many phones, then I understand why not doing it this way.

I can try to configure one of the remote sites with its own IP address network to see if it helps but I doubt it will.

The problem is still there and has not been resolved as of yet.  

Maybe someone could tell me how to trace the RTP packets for on-net calls to see where they are going, that would help.  

I just do not understand why RTP packets for off-net calls do not get lost but on-net calls do.

Lets clear this up a little, there is ONLY one CME system and it is located at the HQ site. The two remote sites only have one IP phone which is connected back to the HQ CME system which processes ALL inbound, outbound, on-net, and off-net calls.  On-net calls are one extension calling another within the office and remote locations.  Anyone at the HQ location can call another user at this location (extension to extension and intercom) with good two-way audio.  When they call the remote locations, the remote location can hear the HQ caller but the HQ caller cannot hear the remote location.  One cavoite to this is if the remote location dials the 10 digit phone number of the HQ, both parties CAN hear each other.  However, if the remote user dial the direct four digit extension, it has one-way audio only.  Off-net calling is when an HQ or remote user calls a third party such as another business, cell phone, or home phone that is not on the CME system.  ALL off-net calls from BOTH HQ and both remote sites have good two-way audio.  And ALL calls are going over the 192.168.200.x network, HQ AND remote.

[Roger Kallberg]

For off-net calls the RTP stream is between the phone and the router, this is why you get 2-way audio.

To “track” the RTP stream your best friend is a packet capture tool, for example Wireshark.

That the phones have connectivity with the CME just means that signaling will work, that’s what makes the call ring on the far end receiving the call. However this have no part in the sound being sent between the phones, aka the RTP stream. This is what we have tried to get you to comprehend.

By reading your outline I suspect that the reason why you get 2-way when a remote phones call the long 10 digit number might be that you likely, possibly without knowing it, send the call out to the PSTN and then it hairpins back again. Then the RTP stream is this, calling phone->gateway->PSTN->gateway->called phone. This is different than for a call that keeps on-net as that would have this RTP stream, calling phone->called phone. The CME is not apart of this at all, other than for signaling.

You should be able to use different IP networks on your sites even if all phones connects to one shared CME at your central site.

[Carlo Poggiarelli]

To add a hint to what correctly suggested Roger and Ninith (+5 both) to analyze the rtp path you can perform a show voip rtp connections during a one-way call to see which ip address are trying to connect and verify if the communicatio for those subents is guaranteed.

The output should look like this

VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 2931549 2931551 28666 27880 10.10.51.4 10.10.51.240 NO NA
2 2931551 2931549 28670 50664 10.10.51.4 192.167.35.44 NO NA

these are 2 call legs one from the Cube to the phone and the other from the CUBE to the provider's SBC

So , the first thing I would do in case of one-way call (in this case) would try to ping  from 10.10.51.4  to 10.10.51.240 (these are directly connected so no expected issue) and from 10.10.51.4  to 192.167.35.44

Please let us know.

HTH

Regards

Carlo