remote IP/SCCP phones connecting to public IP of CME

Unanswered Question
Jul 4th, 2010
User Badges:

I understand that opening up my CME to the Internet involves some amount of risk but I feel that being

careful about how this is done would minimize the risks and make the positives outweigh the negatives.  That

said, I want to confirm what functionality will be available to the remote phones before I proceed with this

project.

What I want to do is to NAT the IP of my CME system and open the minimal amount of ports to have remote SCCP

phones (and also soft phones) connect to it and use its resources.  However since these clients will not

have a VPN established they will only have access to the one public IP of the CME system itself.  They will

not have IP access to other SCCP phones that are registered to the CME and to the VM system, all of which

have private IPs that are not open to the public Internet.  Furthermore, the CME system that these phones

will connect to has SIP connections to other CME systems within the organization also all using private IPs.

I believe that SCCP sometimes uses direct phone-to-phone IP communciations so my question is:  Without a

VPN, how many devices will a remote phone or soft phone be able to communicate with?  How can I determin which devices will talk to the remotes and which not?

Thanks in advance,
Diego

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
William Bell Sun, 07/04/2010 - 10:55
User Badges:
  • Purple, 4500 points or more

Well, remote end points will need to be able to communicate directly to any endpoint you expect to have the remote end point talk to.  So, a remote endpoint talks to a local LAN phone user, a RTP session is established directly between the two endpoints.  The CME is not involved in that call flow.  Two remote endpoints can talk to each other.  If you have any media application hosts outside of CME (e.g. UCCX) then the remote endpoints may need to initiate a RTP session to this media applications (and vice versa).


So, call control/signaling is exchanged between the remote endpoints and the CME call processing agent only.  However, RTP is exchanged between all call parties.  The CME is not inserted into the processes.  Now, in a CUCM environment you do have the concept of a Trusted Relay Point (TRP) that can be used to redirect the RTP flow to a media termination point.  In a way, it proxies the media stream.  I believe the same concept exists in CME based on this document (I have not tested TRP with CME):


http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/feature/guide/TrustedFirewallControll.html


This document isn't an exact match to your scenario, but is definitely worth a look as the concepts are directly applicable.  I don't think that using NAT solely and hoping people don't figure out a way to compromise that thin layer of security is a good idea myself.   But that's just me.


Another consideration is the UC proxy on the ASA.  I have researched this solution from a CUCM perpsective but not from a CME perspective.  It requires the ASA and a special license (for a fee).  Take a look at the CME TRP + FW solution that is discussed in the link provided.  I believe that will be more in line with your objectives.



HTH.


Regards,
Bill

Please remember to rate helpful posts.

DIEGO ALONSO Wed, 07/07/2010 - 05:59
User Badges:

Bill,


That link is definitely very helpful, thank you very much.  I'll post back after reading it if I have any questions,


Rgds,

Diego

DIEGO ALONSO Tue, 07/13/2010 - 19:27
User Badges:

William,


I read the doc you suggested but it doesn't give me a clear vision of how I would do my setup.  I have abandoned the idea of using SCCP directly to the public IP of the CME based on the way SCCP/RTP works with endpoints.  I briefly thought about VPN again but then I remembered how hard it would be to get all the VPN endpoints to talk to each other in a fully meshed fashion.


So thinking a little more I thought about using SIP for the remote phones instead of SCCP.    Wouldn't this bypass the need for the endpoint phones to talk to each other?  I mean right now my office phones connect via SCCP to CME which in turn uses SIP trunks to the PSTN.  The office LAN phones are niether NATed or have a VPN connection to the SIP provider and they work well so it seems that the CME is acting like a gateway for the LAN phones.  The situation would like like this:


Remote SIP phone -> CME -> SCCP LAN based phone.

Remote SIP phone -> CME -> Remote SIP phone


How difficult would it be to setup something like this?  I believe I can reflash my 7965 phones to be SIP based, no?


Thanks,

Diego

Actions

This Discussion