CCNA Voice Gateways And Session Border Controllers Questions

A voice class codec defines the codec preference list, and binding it to the dial-peer governs codec negotiation for calls matching that peer. This satisfies the requirement to enforce a specific codec on CUBE traffic without affecting unrelated peers.

CUBE applies SIP normalization profiles on inbound and outbound dial peers, rewriting headers and SDP. The debug ccsip messages command traces these SIP messages as they are parsed and normalised in real time, exposing the before-and-after header transformations needed to verify the normalisation rules are firing correctly.

The 'show call active voice brief' command provides a concise summary of all active voice calls, including call legs, calling and called numbers, codec, and call duration. It is the standard command to verify current active calls on a Cisco IOS XE voice gateway, making it the correct choice for this scenario.

A 'voice class uri' defines a URI pattern that can be referenced in an inbound dial peer with 'incoming uri via' or 'incoming uri request'. This allows matching based on the Request-URI domain, such as 'example.com', so the gateway can route calls appropriately. It is the standard method for URI-based dial-peer matching on Cisco IOS XE gateways.

Dial-peers are the core matching construct in Cisco IOS voice gateways, pairing inbound call legs with outbound ones via destination patterns. Without them, the gateway cannot route POTS-to-VoIP or VoIP-to-POTS calls, so they are a mandatory component of any voice gateway configuration.

Entering voice service configuration and issuing mode border-element switches the router into Cisco Unified Border Element mode, activating CUBE's session border controller functions such as SIP trunking, dial-peer handling and media interworking on the IOS XE platform.

A voice class uri groups SIP URIs by host or pattern so dial peers can match incoming or outgoing requests against them. This lets CUBE route or apply policy based on the URI host portion rather than only IP addresses or dialled digits.

The destination-pattern matches the dialled number string so the router selects the correct outbound dial peer for that call. It functions as the matching criterion, while session target, codec and digit manipulation are configured separately on the same peer.

For inbound POTS calls, the gateway matches the called number against destination patterns and selects the dial peer with the longest explicit match, not the lowest preference value. The pattern 9.... matches more digits than 9T, so it wins even though its preference is higher. Preference only breaks ties when multiple dial peers have identical match lengths.

The voice class sip-profiles command is used to create a SIP profile that can manipulate SIP headers. Within the profile, you can use rules to add, modify, or remove headers. To insert a custom header like X-Provider-ID: CUBE123 in outgoing INVITEs, you define a rule with the request INVITE and header insertion. This is the correct method for header manipulation on CUBE.

Voice translation-rules match dialled digits using regular expressions, the same pattern syntax applied by Cisco IOS voice translation profiles. This satisfies the stem's requirement that the statement be true: regex patterns define the match and replace clauses that rewrite calling or called numbers before routing, so the claim is accurate.

`session target` defines the destination endpoint for a dial-peer, accepting either an IP address (for VoIP) or a hostname, which directly satisfies the stem's requirement to configure the destination device's address. It is the specific command that binds a dial-peer to its remote peer.

Applying a voice translation-profile to an incoming dial-peer rewrites the called or calling number before outbound dial-peer matching occurs, satisfying the requirement to manipulate digits on inbound calls. The profile's rules execute at that point in the call leg, so translation happens prior to any further routing decisions.

debug voip dialpeer all traces dial-peer matching, showing which peer is selected for the incoming call and why others were rejected. This directly reveals the mismatch causing the routing failure, unlike show commands that only display configuration.

A voice translation-profile with a translation rule can match the '+1' prefix and strip it, modifying the called number before the call is routed. This is the standard method for number manipulation on CUBE. Applying it to the inbound dial-peer from the provider ensures the '+' is removed before the call is sent to Unified CM.

SIP 488 Not Acceptable Here signals that the offered SDP media attributes, typically the codec list, cannot be matched by the receiving endpoint. A codec mismatch between the CUBE and the far end therefore causes calls to be rejected after signalling succeeds.

This SIP profile command copies the Diversion header value to a new History-Info header in the outbound INVITE. It effectively converts the Diversion header to History-Info, allowing CUCM to receive the redirecting number in the expected header. This is a common normalization technique on CUBE for interworking between different SIP implementations.

The debug dialpeer command shows dial-peer matching details for both inbound and outbound calls, including which dial-peer was selected and why. In this scenario, it will reveal whether the inbound call matched the intended POTS dial-peer or fell through to a default, causing the busy condition.

Within sip-ua configuration mode, the timers expires command sets the SIP registration expiry timer in seconds. Setting it to 60 causes the gateway to send a new REGISTER refresh every 60 seconds, which matches the provider's requirement. This is the correct and standard way to adjust the registration expiry interval on a Cisco IOS XE voice gateway, ensuring the registration stays active according to the provider's policy.

SIP profiles provide header manipulation: adding, removing, or modifying headers on inbound and outbound messages. They do not automatically derive the original called number and place it into a Diversion header for forwarded calls. That task generally requires additional logic such as a normalization script or specific CUBE features designed for diversion handling.

Used for header normalization.

SIP profiles allow you to manipulate SIP headers. A sip-header Diversion remove rule within a voice class sip-profiles will remove the Diversion header from the outgoing SIP message. Applying the profile to the outbound dial peer ensures the header is stripped before the INVITE is sent to Unified CM. This is the correct and supported method for header manipulation on CUBE.

Cisco IOS dial-peer matching prefers the most specific destination pattern. The explicit pattern 911 has no wildcards, so it is considered a longer, more specific match than 9T. The gateway selects dial peer 10 for the outbound POTS leg, ensuring emergency calls use the dedicated peer and any special configuration attached to it.

For inbound POTS calls, the gateway matches the dial peer using the incoming called-number command. Without a specific incoming called-number, the POTS dial peer may not be selected for incoming calls. Adding incoming called-number . matches any called number, allowing the POTS dial peer to terminate the inbound call before outbound dial-peer matching occurs.

H.450.3 supplementary services require matching signalling on both call legs. If the CUBE's inbound and outbound dial peers negotiate different protocols, such as H.323 against SIP, the forwarding request cannot be translated, so forwarding silently fails.

The CUBE terminates signalling and media on separate legs, so it can transcode between dissimilar codecs and repacketise flows, letting endpoints with mismatched capabilities interoperate. This satisfies the stem's requirement to identify a function the CUBE performs as a Session Border Controller.

The media flow-around command configures the CUBE to pass media directly between endpoints rather than anchoring it through the gateway. This satisfies the requirement that RTP flows bypass the CUBE, leaving only signalling processed by the router.

The SIP Stack handles SIP signalling messages, including BYE requests that tear down sessions. It ensures the call session terminates correctly by processing the BYE transaction and confirming the dialog ends cleanly, satisfying the stem's requirement for correct session termination within CUBE.