CUCM 6.1 WAN calls issue

Unanswered Question
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Tommer Catlin Fri, 02/19/2010 - 07:49

its really not a supported design per cisco standards.   We can all assume its a routing issue or hitting some kind of filter somewhere on the internet.

If your IP phone does not have a public IP address also, it probably will not work.  For example:

If you have an IP phone that is registered with 192.168.100.2  and another phone registered with 172.10.20.30....     and CUCM has a public address... it will not work.  Those are not routable addresses across the public.

No offense, but there are many other ways to do this, and using a public IP address is probably the worst possible solution for CUCM, IP phones and voice calls.

tcatlinins,

Thanks for your input, I totally agree that it could be a filter somewhere which I do not have control over. As far as the private IP's not being routable on the WAN I would say that they reach the CUCM using NAT public IP. Other than having a packet delay on the WAN I don;t see any reason why wouldn;t this work even though CUCM is made mostly for LAN environments.

I will contunue my experiment and let you know the results..

Thanks again for you reply.

TN

Tommer Catlin Fri, 02/19/2010 - 08:09

The phone will stay registered with CUCM.  It does the keep alives to the Publishers public IP address.  But the problem comes up with with SCCP or SS7 or signalling.

When IP Phone 192.168.1.100 picks up the phone and dials extension x4000 at IP address 172.10.20.30, CUCM will take 192. and try to route the SS7 or SCCP to 172.   CallManager's public IP can not contact 172 from its public IP address.

You change the phones to completely public IP, routable IP addresses, it should work. (in theory)      CallManager in it's database only has the 172. or 192 address for those IP phones.  It does not know those are NAT addresses from a public IP (say linksys router or something)

Tommer Catlin Fri, 02/19/2010 - 08:30

If you have one way audio, its usually routing.  Meaning the audio has no return path.  So if you can hear me, but I cant hear, means that the route *TO* you is fine, but the return route is bad.

It could be ports, but you have to take a look at the network between to understand if there are any firewalls, etc.

What happens with phones on the same LAN segment, CUCM pegs up the call, the drops out of the voice packets.  Signally still takes place because CUCM is still monitoring the call.  But the actual voice packets are from IP phone to IP phone

Tommer Catlin Mon, 03/01/2010 - 11:50

If you can hold off for 1-2 months, you should be able to order CUCM 8.x.   They have a new feature called for the phone which supports what you are trying to do securing.

The VPN client is actually loaded on the newer phones 79X5 phones.   It will create the secure tunnel with CUCM and do calls.  (Requires ASA licenses, etc)

Actions

This Discussion

Related Content