rminating less than 500 sessions (calls) per plat- form, most of the performance engineering needed is likely on the CUBE plat- form itself and not elsewhere in your network. But if you use high-end CUBE platforms terminating 2000 or more sessions per platform, the bottleneck moves to your CUCM servers and most of your engineering work is there instead. On SIP-to-SIP CUBE configurations, do not use the bind command if topology hiding is required (that is, if only one global IP address is available). Instead use the default CUBE configuration, which is to pick up the egress interface address on outbound SIP packets. For H.323-to-SIP configurations, the bind command can be used because there are two addresses available, one for H.323 and one for SIP. Chapter 11: Deployment Steps and Best Practices 261 Define explicit incoming and outgoing dial-peers on your CUBE device. SBC calls have two IP call legs (as opposed to a TDM gateway that has only one), SO it is often necessary to have both dial-peers to control the characteristics of each individual call leg-the default settings might not be what you need in your net- work. This practice also gives you additional control points to combat toll fraud attacks. Security Best practices in the area of security include the following: In a single-site or small network, a firewall or NAT device might be sufficient as the enterprise demarcation and security border device. In larger networks, use a Layer 7 SBC device with additional protection, configuration, and traffic control. If you deploy both a firewall device and an SBC (as most large enterprises do in their campus sites), it is generally recommended to put the firewall on the outside as a first line security defense for all traffic and put CUBE behind it as a second line of defense optimized for unified communications traffic. Use SIP registration on the SIP trunk if it is offered by the SP. Also use Digest Authentication on both SIP registrations and INVITES if available as part of the service. Deploy toll fraud feature