ping) for inbound traffic. Border Element Redundancy SIP trunks terminate on the session border controller, or border elements, in the enter- prise. These elements have to be redundant for high session capacity SIP trunks, both for scalability and high availability reasons. You can use various ways to provide redundancy for a particular border element platform (in addition to the local and geographic redun- dancy schemes already previously discussed): In-box hardware redundancy Box-to-box hardware redundancy Clustering In-Box Hardware Redundancy In-box redundancy means duplicate processing components exist contained within the platform itself SO that if one hardware component fails, another immediately takes over. In-box redundancy often includes components such as the CPU card, possibly the memo- ry cards, I/O interface cards, and control and data plane forwarding engines. The level of hardware redundancy the CUBE provides depends on the hardware platform on which the function is installed. The higher-end platforms offer more hardware redun- dancy than the lower-end platforms. In-box hardware redundancy is almost invariably seamless, also called stateful failover, SO sessions are not dropped and end users on active calls are generally unaware that a hardware failover has occurred. Box-to-Box Hardware Redundancy (1+1) Box-to-box redundancy, or 1+1 redundancy, means there are duplicate platforms, acting and configured as a single one, in an active/standby arrangement with a keepalive mecha- nism between them. If the active hardware platform fails, the standby platform takes over. One such method is the Hot Standby Router Protocol (HSRP) supported on Cisco IOS routers. With HSRP transparent hardware failover is possible while maintaining a single SIP trunk (that is, a single visible IP address) to the service provider. How well HSRP works in a particular deployment depends on the service provider IP addressing rules and the release of software deployed on the CUBE. HSRP redundancy is not inherently stateful but can