s opposed to bandwidth-based mechanisms (such as Resource Reservation Protocol [RSVP]). It is therefore important to control not only the number of calls arriving through the SIP trunk, but also the codec assigned to the calls. In addition to transcoding and codec filtering, a CUBE can support the CAC policy of the enterprise in the following two ways: Limiting calls per dial peer (per destination) Limiting calls based on memory and CPU Limiting Calls per Dial-Peer You can configure the max-conn command on both the inbound and outbound dial- peers of the CUBE to ensure that no more than the configured number of calls connects at one time. Each call, regardless of codec or the direction of the call, counts as one call. When a call arrives at a dial-peer and the current number of calls in the connected state exceeds the configured amount, the SIP INVITE request is rejected with a 503 result code to indicate that the gateway is out of resources. Example 7-7 shows how to configure CAC per dial-peer. Example 7-7 Using Dial-Peer CAC Mechanisms dial peer voice 1 voip max conn 2 Global Call Admission Control The CUBE can also be configured to monitor calls on a global basis; that is, without regard of which dial-peer the call might be active on. This global CAC control can be done based on: A global system count of calls A CPU threshold (as a percentage) A memory threshold (as a percentage) Any combination of the preceding three metrics Chapter 7: Design and Implementation Considerations 127 The CUBE checks these configurations and metrics before it completes the processing of a SIP INVITE request. If system resources used exceed the configured amount, the CUBE returns a result code in the SIP INVITE request, indicating that the gateway is out of resources. Example 7-8 shows how to configure global CAC. Example 7-8 Using Global CAC Mechanisms call threshold global total - calls low 20 high 24 call threshold global cpu-avg low 68 high 75 call threshold global total-mem low 75 high 80 call threshold interface Ethernet 0/1 