That's not a reason to have a CUBE, you can do translation in there if needed, or directly on CUCM.
A direct SIP trunk 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 SP 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 SPs 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 SP, and no way to customize them on the outgoing packets
- No way to manipulate SIP msging from the SP before it hits your CUCM to customize it to what CUCM/IP-PBX prefers to see
- Limited means of complying to the SP UNI (SIP msg manipulation on outbound msgs to the SP, and capabilities such as early-offer)
- Having to implement the SP UNI on CUCM instead of your enterprise 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 SP when this is required on the SIP trunk
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk
HTH
java
if this helps, please rate
