The NICs on CUCM servers are only for fault tolerance, they're not meant for any other purpose. You cannot configure different IPs on them, ONLY fault tolerance.
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
You can use this link to determine the requirements based on what you want to do with the GW:
Software Advisor
http://tools.cisco.com/Support/Fusion/FusionHome.do
HTH
java
If this helps, please rate
www.cisco.com/go/pdihelpdesk
HTH
java
if this helps, please rate
