You should check out the SIP trunk Q&A that Christina just finished.
I've stolen this response from her:
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
Technically you can do it, but it isn't suggested. However if your SIP provider requires registration then you would need CUBE, however.
hth,
nick
