Mid-Call Signalling
The purpose of Mid-call Re-INVITE Consumption is to ensure smooth interoperability of supplementary services like audio Hold/Resume and call transfer. This feature should be used as a last resort only when there is no other option in Cisco UBE. This is because configuring this feature can break video-related features. For Delay-offer Re-INVITE, the configured codec will be passed as an offer in 200 message to change the codec, the transcoder is added in the answer.
CUBE can alter the contents of any header in any SIP or SDL header of any request or response (SDL or "Session Description Language" is where things like media, DTMF relay, etc are negotiated - you see a SDL sub-component of the above SIP INVITE message - which is known as a "SIP Early Offer"). So let's tell CUBE to alter that Contact header of that particular INVITE message, but only out to AT&T. As a preface to our configuration example, it is worth noting that SIP Profiles allow for pattern matching and replacement in a similar (but not exact) method to that of Voice Translation Rules, and like them, are based (loosely) on the GNU SED stream editor. We will use this to match and replace a few possible dynamic values of the string. Like Voice Translation Rules, reference "sets" of matched information in the replacement string with \1 which calls Set 1 from the matched pattern to the replacement pattern. Also like Voice Translation Rules, any part of the string (beginning or end) that we don't match, passes through to the replacement pattern, unaltered
SIP Profiles
Protocol translation and repair is a key Cisco Unified Border Element (CUBE) function. CUBE can be deployed between two devices that support the same VoIP protocol (SIP), but do not interwork because of differences in how the protocol is implemented or interpreted. CUBE can customize the SIP messaging on either side to what the devices in that segment of the network expect to see by normalizing the SIP messaging on the network border, or between two non-interoperable devices within the network.
Service providers may have policies for which SIP messaging fields should be present (or what constitutes valid values for the header fields) before a SIP call enters their network. Similarly, enterprises and small businesses may have policies for the information that can enter or exit their networks for policy or security reasons from a service provider SIP trunk.
In order to customize SIP messaging in both directions, you can place CUBE with a SIP normalization configuration at the boundary of these networks as shown in this image:
SIP Early Offer
SIP negotiates media exchange by means of the Session Description Protocol (SDP), where one side offers a set of capabilities to which the other side answers, thus converging on a set of media characteristics. SIP allows the initial offer to be sent either by the caller in the initial INVITE message (Early Offer) or, if the caller chooses not to, the called party can send the initial offer in the first reliable response (Delayed Offer).
By default, Unified CM SIP trunks send the INVITE without an initial offer (Delayed Offer). In general SIP Delayed Offer is preferred for Unified CM SIP trunks because MTPs are not needed to establish a Delayed Offer call for voice, video, or encrypted media. If SIP Early Offer is desired, Unified CM has two configurable options to enable a SIP trunk to send the offer in the INVITE:
Early Offer Support for Voice and Video Calls (Insert MTP If Needed) Enabling Early Offer support for voice and video calls (insert MTP if needed) on the SIP Profile associated with the SIP trunk inserts an MTP only if the calling device cannot provide Unified CM with the media characteristics required to create the Early Offer. In general, Early Offer support for voice and video calls (insert MTP if needed) is recommended over Media Termination Point Required because this configuration option reduces MTP usage (see Figure 14-4). Calls from older SCCP-based phones registered to Unified CM over SIP Early Offer trunks configured with this option will use an MTP to create the Offer SDP, and these calls support voice, video, and encrypted media. Inbound calls to Unified CM from SIP Delayed Offer trunks or H.323 Slow Start trunks that are extended over an outbound SIP Early Offer trunk will use an MTP to create the Offer SDP; however, these calls support audio only in the initial call set up but can be escalated mid-call to support video and SRTP if the call media is renegotiated (for example, after hold/resume). For guidance on when to use Early Offer support for voice and video calls (insert MTP if needed)
DTMF interworking
One of the features of Cisco Unified Border Element (SP Edition) is the ability to interwork between the various dual-tone multifrequency (DTMF) signaling types. DTMF interworking is used when the two endpoints do not use the same type for relaying DTMF tones.
DTMF dialing consists of simultaneous voice-band tones generated when a button is pressed on a telephone. The challenge comes from a scenario where one side uses Real-time Transport Protocol (RTP) and the other uses Session Initiation Protocol (SIP) signaling to enable advanced telephony services. Examples of the types of services and platforms that are supported by DTMF interworking are various voice web browser services, Centrex switches or business service platforms, calling card services, and unified message servers. All of these applications require DTMF interworking for the user to communicate with the application outside of the media connection.
Box-to-box failover and redundancy
The Cisco Unified Border Element (CUBE) provides high availability (HA) via box-to-box redundancy configurations when implemented on a Cisco Integrated Services Router Generation 2 router (ISR G2) platform. CUBE box-to-box redundancy leverages the long available router-based Hot Standby Routing Protocol (HSRP) router technology.
HSRP technology provides high network availability by routing IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces - if any interface goes down, the whole device is considered down, the Standby device becomes active and takes over the responsibilities of the Active router.