I have a burning question that I've needed help on for years now regarding properly binding media and signaling for SIP in CUBE. Growing up in the Cisco world I've always been told and followed the best practice of binding media and signalling for H323, MGCP, CME and SRST to a loopback on the router and some features simply won't work unless you bind to a loopback. This has worked great until I came across utilizing CUBE for SIP integration with CUCM and a PSTN provider such as AT&T, Verizon or Global Crossing. What's my issue? I can no longer bind my traffic to that loopback address and have a succesful CUBE integration with an external entity or with CUCM. You ask how that's an issue? When I bind to that loopback address which has an internal non public routable IP address CUBE sends out of all interfaces that Loopback interface as the source address so when my SIP traffic gets sent to the PSTN provider they have no way of getting back to that router but obviously it works for talking to CUCM. I thought, simple, that's what NAT is for for the outside connection! I disocvered the hard way that CUBE and NAT are not friends and supported together due to CUBE doing a very basic form of NAT with the address-hiding command. I thought "Cool, address-hiding should be doing this for me!" and no, it is simply following what you tell it by binding all traffic to the specified interface in voice service voip - sip. So my question is simple: What is best practice and the correct way for binding traffic in CUBE for interaction with CUCM and an external PSTN Provider? I've spent hours on Google and Cisco documentation and cannot find a good answer other than this from the SIP Configuration Guide and CUBE Configuration Guide:
When you configure SIP on a router, the ports on all its interfaces are open by default. This makes the router vulnerable to malicious attackers who can execute toll fraud across the gateway if the router has a public IP address and a public switched telephone network (PSTN) connection. To eliminate the threat, you should bind an interface to private IP address that is not accessible by untrusted hosts. In addition, you should protect any public or untrusted interface by configuring a firewall or an access control list (ACL) to prevent unwanted traffic from traversing the router.
Let me stop those who think 'throw an ASA in front of it' or 'don't bind it to a specific interface' is an answer and can throw an argument for why 'no' to both of those answers. I think the answer is a new feature in 15.1(2)T that allws you to apply a voice class for binding SIP and assigning it to the appropriate dial peers but I'd like to hear everyone's input.
