 natural disaster on a building or data center. Load Balancing SIP trunks from providers usually come with two (sometimes more) IP addresses. As pre- viously discussed, you might want to have multiple border elements fronting this SIP trunk for both redundancy and scalability benefits. If you choose a load-balancing algo- rithm (as opposed to a primary/secondary active/standby arrangement) for the multiple platforms forming the network border, some network entity is required to do load balanc- ing across the possible destinations. 134 SIP Trunking You can use multiple ways to implement SIP trunk load balancing: Service provider load balancing CUCM route groups and route lists Cisco Unified SIP proxy Service Provider Load Balancing Many SIP trunk providers offer a choice of primary/secondary or load-balancing algo- rithm to the enterprise customer. If load balancing is chosen, this is implemented either on their SIP softswitch or their provider edge SBC. Domain Name System (DNS) You can use DNS SRV records (RFC-2782) to provide multiple IP address resolutions for the same hostname. In this way, the individual platforms in the border element cluster can be addressed dynamically using the information returned by DNS. The operation of this mechanism is shown in Figure 7-7. Cisco Unified CM _sip._udp.cube IN SRV 10 1 5060 cube1.com IN SRV 10 2 5060 cube2.com cube1 10.10.10.5 cube2 10.10.10.6 DNS Server INVITE SIP Proxy 10.10.10.5 CAC reached, 500 Internal Server Error, Q.850=44 INVITE 10.10.10.6 Cisco Unified Border Element Pool Figure 7-7 Using DNS SRV for Load Balancing The attached SIP softswitch (this can be used either on the service provider side or on the enterprise side) queries DNS for the IP addresses of the border element. The originating softswitch uses these addresses to load balance traffic. If a call is presented to a CUBE that is overloaded (its configured CAC threshold has been reached), it returns a SIP 503 Internal Server Error, and the softswitch can use the next available address in the DNS SRV re