Reasons as to why not to have a Direct SIP Trunk to service provider from Cisco Unified Communications Manager

Document created by cesar.fiestas on Aug 28, 2009
Version 1Show Document
  • View in full screen mode

When I started to play and test with SIP and Cisco Unified Communication Manager I was using my UCM 6.x server to connect to my sip trunk service provider using my internet connection, although after a while I was facing some restrictions, flexibility and I also realize that it wasn't the most secure way to connect to my SIP trunk service provider directly from my UCM (even though it was for testing purposes only), anyhow the other day while i was researching on the internet I found a great comment from a guy from cisco which summarizes exactly the reasons why would you want to have a CUBE between your UCM cluster and your SIP Trunk Provider, here his comment



A direct SIP Trunk to the SP is certainly technically feasible, but it is an inflexible and insecure solution and therefore strongly NOT recommended.


Reasons to terminate a SIP trunk on an enterprise demarc such as CUBE include but are not limited to:

-Lack of call admission control (SLA enforcement and DOS attack mitigation) on the SIP Trunk

-Visibility of the CUCM and endpoint IP addresses to the Service Provider Network (and therefore to potential hackers)

-Very limited SIP Trunk load balancing and redundancy capabilities

-No SIP Trunk sharing between multiple CUCM clusters or other IP-PBX/proxy call agents in the enterprise

-No SIP malformed packet or other protocol level attack mitigation for your CUCM

-No way to troubleshoot voice quality problems to determine if it's your network or the Service provider network at fault

-Much more limited toll fraud prevention techniques on the SIP trunk

-No way to control IP QOS settings on the incoming packets from the Service provider, and no way to customize them on the outgoing packets

-No way to manipulate the SIP msging from the Service Provider before it hits your CUCM to customize it to what CUCM/IP-PBX prefers to see
-Limited means of complying to the Service Provider UNI (SIP msg manipulation on outbound msgs to the Service Provider, and capabilities such as early-offer)

-Having to implement the Service Provider UNI on CUCM instead of your enteprise preferred policies (and having to replicate this on every CUCM and IP-PBX routing calls to the SIP Trunk)

-Having no way of doing a SIP registration to the Service Provider when this is required on the SIP trunk



Thanks to hattingh @ cisco for such a nice explanation,



This document may be subject to changes or updates, this document was written by Cesar Fiestas