Free 350-801 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

When CUCM Self-Provisioning is already enabled and each end user has a PIN, the phone must first appear in CUCM as an unassigned device.

1. The user plugs the new IP phone into the network so that it boots, requests DHCP, downloads the SEPDefault.cnf.xml file, and registers as an unassigned (dummy) device.

2. From that same phone, the user dials the Self-Provisioning IVR pilot (default 9777). After entering the extension/ID and PIN, CUCM automatically associates the device with the end user and downloads the correct configuration.

No manual device-to-user association or special key sequence is required once Self-Provisioning is configured.

A. Administrator association defeats the purpose; CUCM performs the association automatically after the IVR interaction.

C. The IVR pilot is not a hunt-pilot; using a hunt pilot will not trigger Self-Provisioning.

E. # unlocks phone settings but does not invoke Self-Provisioning or user association.

1. Cisco Unified Communications Manager 12.5 Feature Configuration Guide – “Self-Provisioning and Bulk Self-Provisioning for End Users”, Workflow Steps 1-3 (sections “End-User Self-Provisioning Process”).

2. Cisco Unified Communications Manager Administration Guide 12.x – Chapter “Configure the Self-Provisioning Feature”, section “End-user steps: Connect the phone and dial the IVR extension”.

3. Cisco Collaboration SRND (12.x), Chapter 9 “Endpoint Provisioning”, subsection “Self-Provisioning”, bullets “Plug phone into the network” and “Dial Self-Provisioning IVR (9777) to associate”.

The "Alternate Extensions" feature in Cisco Unity Connection is specifically designed to associate multiple phone numbers with a single user's voice mailbox. When an administrator configures an alternate extension for a user, any unanswered calls to that secondary number (e.g., from a mobile phone, a home office phone, or a second desk phone) are correctly routed to the user's primary voice mailbox for message deposit. This directly addresses the requirement of accessing a mailbox from a secondary device's extension.

A. Attempt Forward routing rule: This is a call routing action that forwards a call to a specified extension. It does not associate a secondary extension with a user's mailbox.

B. Mobile User: This setting is related to mobility features like Single Number Reach (SNR), which manages call forwarding to mobile devices, not linking multiple extensions to one mailbox.

D. Alternate Names: This feature allows users to be found in the directory by different names (e.g., a nickname). It is unrelated to phone numbers or device extensions.

1. Cisco Unity Connection Documentation: System Administration Guide for Cisco Unity Connection, Release 12.x, "Users" chapter, "Alternate Extensions in Cisco Unity Connection" section.

The guide states, "Alternate extensions are additional phone numbers at which a user can be reached... When a call comes in to an alternate extension and is not answered, Unity Connection is able to find the correct mailbox to record a message in based on the alternate extension number."

2. Cisco Unity Connection Documentation: User Moves, Adds, and Changes Guide for Cisco Unity Connection Release 12.x, "Setting Up User Accounts" chapter, "Phone Information for User Accounts in Cisco Unity Connection" section.

This section details the configuration fields for a user, explicitly mentioning "Alternate Extensions" as the method to add phone numbers for other devices (for example, a home office or mobile phone) that should be associated with the user's mailbox.

The show isdn status output lists “Serial x/x/x:23 is administratively down – Layer 1 DEACTIVATED.”

This message appears only when the T1/E1 controller itself is shut. With Layer 1 down, the D-channel (timeslot 24) never activates, so no setup messages are exchanged and every call fails. Entering:

controller t1

no shutdown

re-enables the physical layer; Layer 1 changes to ACTIVE, Layer 2 to MULTIPLEFRAMEESTABLISHED, and PRI call processing is restored.

A. Wrong switch-type affects Layer 2 negotiation, but Layer 1 would still be ACTIVE; the problem shown is administrative shutdown.

B. Missing bearer timeslots do not prevent the D-channel from coming up; Layer 1 would remain ACTIVE.

C. E1 (30B+1D) framing is used outside North America; circuit in New York requires a T1 card.

1. Cisco IOS Voice Troubleshooting and Monitoring Guide, “Troubleshooting ISDN PRI Layer 1 – Administratively Down”, steps 1-2 (Release 15 M&T).

2. Cisco Command Reference, show isdn status – description of “administratively down” and required no shut (IOS 15.x).

3. Odom, Guy et al., CCNP and CCIE Collaboration Core CLCOR 350-801 Official Cert Guide, 2020, Chap 6, pp. 269-270 (example output and correction with no shutdown).

During digit analysis, Cisco Unified Communications Manager first eliminates any pattern that does not match the dialed digits.

If several candidate patterns remain, CUCM applies its tie-breaker rules: it prefers the pattern with the most-specific match (longest explicit match/fewest wild-cards) and, if a tie still exists, the pattern that addresses the fewest possible endpoints (for example, a single directory number over a translation or route pattern).

Therefore a valid candidate must match the dialed string (D) and, in a tie, the pattern representing the smallest number of endpoints (C) is chosen.

A. CUCM selects the longest, not the shortest, explicit prefix; this option inverts the rule.

B. A non-matching pattern is discarded before tie-breaking and is never selected.

E. CUCM deliberately picks the pattern with the fewest—not the largest—reachable endpoints to avoid over-broad routing.

1. Cisco Unified Communications Manager Dial Plan Guide, Release 14, Chapter 3 “Digit Analysis – Best Match and Tie-Breaker Rules”, pp. 77-79.

2. Cisco Unified Communications Manager System Guide, Release 14, Section “Digit Analysis”, paragraph “If multiple patterns remain… selects the pattern that has the fewest endpoints”.

3. Cisco Live BRKCOL-2037 “CUCM Dial Plan: The Essential Guide”, 2019, slides 31-33 (Pattern Specificity and Endpoint Count).

Cisco Unity Connection can automatically create and maintain voicemail mailboxes by synchronizing its user database with Cisco Unified Communications Manager through the AXL SOAP interface. During initial Unity Connection configuration you add one or more “AXL servers”; once enabled, Unity Connection queries CUCM over AXL, imports the CUCM end-users, and immediately provisions voicemail boxes for them. SIP or SCCP integrations only provide call-routing; they do not expose the CUCM user directory. LDAP/Active-Directory synchronization is configured after installation and likewise does not occur “when the Unity Connection server is configured” by the initial wizard. Therefore, configuring an AXL server is the required action.

A. SIP integration supplies call-signaling only; it does not deliver user records for mailbox creation.

B. SCCP integration handles call-control, not directory/user synchronization.

D. LDAP/AD sync is performed post-installation in separate menus; initial server configuration cannot pull users directly from AD for automatic mailbox creation.

1. Cisco Unity Connection System Administration Guide, Release 14, “Synchronizing User Data with Cisco Unified CM via AXL,” pp. 18-1 to 18-4.

2. Cisco Unity Connection Design Guide, Release 12.x, “User Provisioning and Directory Synchronization—AXL,” Section 5.3.

3. Cisco Unity Connection Installation and Upgrade Guide, Release 12.x, Chapter 6 “Initial Configuration Wizard,” Step ‘Add AXL Server’ (page 6-12).

Cisco Expressway-E is the Internet-facing node of an Expressway‐C/E pair. When the Mobile and Remote Access (MRA) feature is enabled, Expressway-E provides secure firewall-traversal for Jabber and telepresence endpoints, exposing voice, video, IM-&-P, voicemail and directory services to users outside the enterprise. Activating MRA therefore unlocks the full, intended feature set of the Expressway-E platform. By design, Expressway-E does not allow endpoint registration, does not function as a PSTN SIP gateway, and contains no MCU/bridge resources.

A. H.323 endpoint registrations – Registration services are disabled on Expressway-E; only Expressway-C (or CUCM) can register endpoints.

C. SIP gateway for PSTN providers – PSTN connectivity is delivered by CUBE/ISR, not by Expressway-E.

D. VTC bridge – Expressway-E has no conference-bridge/MCU capability; external CMS or MCU is required.

1. Cisco Expressway Administrator Guide X14.0, “Differences between Expressway-C and Expressway-E”, Table 4, p. 18 – notes “SIP registrar and H.323 gatekeeper disabled on Expressway-E”.

2. Cisco Expressway Basic Configuration for Mobile and Remote Access X14.0, Sec. 1 “About Mobile and Remote Access”, pp. 5-6 – describes enabling MRA on Expressway-E to provide all remote collaboration services.

3. Cisco Collaboration SRND Release 12.x, Ch. 17 “Mobile and Remote Access”, pp. 17-5 to 17-7 – identifies Expressway-E as the public-side component that delivers MRA.

4. Cisco Expressway Series data sheet, DS-4018, “Key Features” – lists Mobile and Remote Access under Expressway-E capabilities; no mention of PSTN gateway, MCU, or endpoint registration.

Transrating fixes packet-size mismatches when the codec itself is identical.

Only IOS-based MTPs (software or DSP-based hardware) can negotiate and repacketize G.711 streams at different sample sizes (10/20/30/40 ms).

The built-in CUCM software MTP is limited to a fixed 20-ms packetization and therefore cannot interwork with a 30-ms endpoint.

Transcoders are irrelevant because no codec change is required.

B. CUCM software MTP supports only 20-ms packets and performs no packetization conversion; cannot interwork with 30-ms endpoint.

C. A transcoder converts between different codecs, not different packet sizes of the same codec; unnecessary here.

D. Hardware transcoder (DSP) again performs codec conversion, not packetization adjustment.

1. Cisco Collaboration SRND 12.x, “Media Termination Point,” Table “Supported Sample Sizes” – CUCM software MTP (20 ms only); IOS Enhanced MTP (10/20/30/40 ms).

2. Cisco IOS Enhanced Media Termination Point White Paper, Doc ID 116076, section “Packetization Conversion,” para 2 – “IOS software or DSP-based MTP can transrate between 10-, 20-, 30- and 40-ms packets.”

3. Cisco Unified CM Features and Services Guide 14, chapter “Media Termination Point,” sub-section “CUCM Software MTP Limitations” – “No support for packetization conversion; fixed at 20 ms.”

In Cisco Unified CM, DHCP service activation only enables the internal DHCP engine. To make the server operational, you must define at least one DHCP scope (subnet) that specifies the usable address pool, default router, option 150, and other parameters for the IP phones. This is done in Cisco UCM Administration via System > DHCP > Subnet. Until a subnet (scope) is added, the CUCM DHCP service will not hand out any leases, so adding the DHCP subnet is the required next step.

A. Cisco DHCP Monitor Service restarts automatically when activated; manual restart is not required.

B. DHCP operation is local to CUCM; no changes to external DNS servers are necessary.

C. TFTP service distributes device configuration files, unrelated to DHCP scope creation and need not be restarted for DHCP to function.

1. Cisco Unified Communications Manager Features and Services Guide, Release 14, “Configure the Cisco DHCP Server,” Steps 1–3 (pp. 281–282).

2. Cisco Unified Communications Manager Administration Guide, Release 12.5, Section “Adding a DHCP Subnet” (p. 2306).

3. Cisco Unified Serviceability Administration Guide, Release 14, “DHCP Monitor Service—Automatic Restart Behavior” (p. 119).

The exclamation-point wildcard (!) in a Cisco Unified CM route pattern represents “one or more digits of variable length.”

Pattern 9.011! therefore permits any international access code (011) followed by any length destination number, allowing a single pattern to cover all international destinations and thus minimizing the total number of route patterns required.

A. 9.011# ‘#’ is an end-of-dial marker; it does not allow additional variable digits, so a separate pattern would be needed for each length.

B. 9.011@ ‘@’ matches only NANP-compliant numbers (North American dialing), not generic international numbers, so it omits many destinations.

D. 9.011 ‘’ is treated as the literal star key, not a wildcard; no digits follow, so it cannot match variable-length numbers.

1. Cisco Unified Communications Manager Administration Guide, Release 12.5(1), “Route Pattern Wildcards and Special Characters,” Table 44: ‘!’ – “Matches one or more digits (variable length).”

2. Cisco Unified CM Features and Services Guide, Release 14, ch. Dial Plan, section “Wildcards (Special Characters),” p. 16-9: describes ‘#’, ‘@’, ‘’, and their specific behaviors; notes that ‘@’ is limited to NANP and ‘#’ marks end of dial string.

3. Cisco Press, “Deploying Cisco Unified Communications (CVOICE) v8.0 Foundation Learning Guide,” ISBN 9781587204173, ch. 5, “CUCM Dial Plan,” p. 177-178: explains that 9.011! is the recommended single pattern for international dialing because ‘!’ covers variable-length subscriber numbers.

For Mobile and Remote Access (MRA), external clients must discover the Cisco Expressway-E server to establish a secure connection. This discovery process relies on a specific DNS Service (SRV) record. The collab-edge.tls. record is configured in the public DNS to resolve to the FQDN of the Expressway-E. The collab-edge service identifier directs collaboration clients, and tls specifies that the connection must be secured using Transport Layer Security, which is mandatory for MRA.

A. cisco-uds.tcp.example.com: This SRV record is used for internal service discovery, directing clients to Cisco Unified Communications Manager (CUCM) for User Data Services (UDS), not for external MRA.

C. collab-edge.tcp.example.com: This record is incorrect because MRA mandates a secure connection. The protocol must be tls (Transport Layer Security), not the unencrypted tcp.

D. cisco-uds.tls.example.com: This record is not used for MRA. The cisco-uds service is for internal UDS discovery, and the collab-edge service is required for external MRA discovery.

1. Cisco Expressway Administrator Guide (X14.2), "DNS Records for MRA", Page 101.

The document explicitly states, "For service discovery, you must configure the collab-edge.tls. SRV record on the public DNS server. This SRV record should resolve to the FQDN of the Expressway-E that you use for Mobile and Remote Access."

2. Mobile and Remote Access Through Cisco Expressway Deployment Guide (X14.0), "DNS Configuration", Page 17.

This guide details the necessary DNS records for a successful MRA deployment, specifying: "External DNS must have an SRV record for collab-edge.tls. pointing to the Expressway-E FQDN."

3. Cisco Collaboration Edge Architecture Preferred Architecture, Design Overview, "Appendix B: DNS for Collaboration Edge", Page 61.

This design guide outlines the required DNS configuration, noting: "The external DNS server must host an SRV record, collab-edge.tls., which points to the A record of the Expressway-E server or, in a clustered environment, the A records of all Expressway-E peers."

The exhibit shows a transcoder profile whose codec list contains only G.711 µ-law, G.711 A-law, G.729r8 and G.729ar8.

A DSP-farm can transcode only between codecs that are explicitly registered in that profile.

Therefore, the permutations that must—and can—be handled by this DSP-farm are:

• G.729r8 ↔ G.711 µ-law (C)

• G.729ar8 ↔ G.711 A-law (E)

All other listed permutations include a codec (iLBC, G.728br8, G.722) that is absent from the profile and hence are not eligible for transcoding by this resource.

A. iLBC is not in the profile; the DSP-farm cannot advertise or transcode it.

B. G.728br8 is unsupported/unregistered in the shown profile; no transcoder match.

D. G.722 (wide-band) is missing from the profile and not supported by IOS-based narrow-band DSP transcoders in CUCM 12.x.

1. Cisco Unified Communications Manager Features and Services Guide, Release 12.5 – “Audio Transcoding in DSP Farms”, Table 10-2 Supported Codecs (G.711 µ-law, G.711 A-law, G.729, G.729a) – cisco.com, p. 10-19.

2. Cisco IOS XE Voice Infrastructure Services Configuration Guide, 17.3 – “Configuring DSP Farm Transcoding”, section “codec pass-through and negotiation”, lists same supported codecs; G.722, G.728, iLBC absent – cisco.com, §“Supported Transcoding Codecs”.

3. Cisco Unified Communications SRND, Release 12.x – Ch. 5 “Media Resources”, “Transcoder Codec Support”, confirms only permutations between registered codecs are selectable – cisco.com, p. 5-21.

(Each reference publicly available on Cisco.com; page numbers refer to PDF versions.)

In ISDN Q.931 / Q.850 signalling, Cause Number 1 is defined as “unallocated (unassigned) number.”

The network switch cannot find any endpoint or directory entry that owns the dialed DNIS, so it immediately releases the call with cause 1. This exactly matches option D: “The dialed number is not assigned to an endpoint.” Media resources, user-busy, or call-rejection conditions use different cause numbers (16-series or 20-series).

A. Media resource problems occur after call setup; no ISDN cause code corresponds—cause 1 is issued before media allocation.

B. “Destination rejects the call” maps to Cause 21 (Call rejected), not 1.

C. “Destination number is busy” maps to Cause 17 (User busy), not 1.

1. ITU-T Recommendation Q.850 (02/1998), §3.2, Table 1 – Cause 1: “Unallocated (unassigned) number.”

2. Cisco Systems, “Understanding and Troubleshooting ISDN Call Disconnect Problems,” Doc ID 10036, Table “Cause Codes,” cause 1 – Unallocated/unassigned number.

3. Cisco Press, Caslow et al., “Cisco Voice Gateways and Gatekeepers,” 2001, Ch. 3 “ISDN Call Control,” p. 83 – list of Q.931/Q.850 cause codes shows cause 1 as unallocated number.

CUCM treats any account imported from an external LDAP directory as read-only. When that account is removed from LDAP, the next DirSync cycle only changes its state in CUCM to “Inactive LDAP Synchronized User.” Physical deletion is handled by the database garbage-collector task, which runs automatically once every 24 hours (default start time 01:00 server local time). Administrators therefore simply wait for the garbage-collector to purge the inactive record; no manual deletion or service restart is required or supported for LDAP-synchronized users.

A. CUCM disables the Delete button for LDAP-synchronized users; manual deletion is blocked.

C. Restarting the DirSync service refreshes status but does not trigger the garbage-collector, so the user remains.

D. A manual sync again just flags the user as inactive; only the nightly garbage-collector removes it.

1. Cisco Systems, “Administration Guide for Cisco Unified Communications Manager, Release 12.5(1),” Ch. 11 ‘Directory Integration’, sec. ‘Deleting LDAP Synchronized Users’; pp. 11-31–11-32.

2. Cisco Systems, “Features and Services Guide for Cisco Unified Communications Manager, Release 14,” Ch. ‘Directory Synchronization’, para. ‘Garbage-Collection Process’ (page 1420).

3. Cisco Press. Kapur et al., “Implementing Cisco Unified Communications Manager, Part 1,” 2nd ed., 2012, Ch. 6 ‘LDAP Integration’, pp. 414-416 (explanation of inactive user flag and nightly purge).

When Unity Connection communicates with Cisco UCM across a SIP trunk, it must be allowed to send unsolicited NOTIFY messages for Message-Waiting Indicator (MWI) updates and to perform supervised transfer operations that use the SIP Replaces header. Therefore the SIP trunk security profile applied to the Unity Connection trunk must have the options “Accept Unsolicited Notification” and “Accept Replaces Header” enabled.

A. Accept presence subscription – Presence is not used in the Unity Connection voice-mail integration; this setting is unnecessary.

B. Allow charging header – Pertains to SIP charging information for billing; irrelevant to Unity Connection.

D. Enable application-level authorization – Used for SIP application tokens; Unity Connection does not require it for basic voice-mail integration.

1. Cisco Unity Connection and Cisco Unified Communications Manager Integration Guide for SIP, Release 14, “Create a SIP Trunk Security Profile,” Step 6 – lists required boxes: Accept Replaces Header & Accept Unsolicited Notification (pp. 17-18).

2. Cisco Unified Communications Manager Features and Services Guide, Release 14, “SIP Trunk Security Profile Field Descriptions,” explains functions of Accept Replaces Header and Accept Unsolicited Notification (Section “SIP Normalization and Transparency,” pp. 321-322).

Cisco Prime Collaboration requests network devices to send SNMP notifications (Traps and InformRequests). By definition and in Cisco Prime Collaboration Assurance configuration, these unsolicited SNMP messages are delivered to the manager over UDP port 162. Prime must therefore listen on UDP/162 to receive the notifications it solicits.

A. UDP 161 – Used for SNMP polling (Get, Get-Next, Set), not for traps/informs.

B. TCP 161 – TCP transport is optional and for polling; traps/informs still default to UDP 162.

D. TCP 80 – Standard port for HTTP web traffic, unrelated to SNMP or Prime notification delivery.

1. Cisco Prime Collaboration Assurance and Analytics Administration Guide, Release 12.1, “Configuring SNMP,” p. 18: “PCA listens for SNMP traps and inform requests on UDP port 162.”

2. Cisco Prime Collaboration 11.x Quick Start Guide, Appendix B “Port Utilization,” p. B-4: “SNMP Traps/Informs – UDP 162 inbound to Prime.”

3. Cisco Systems, “Simple Network Management Protocol (SNMP) Overview,” Technical Note, 2019, p. 2: “Managers receive traps and inform requests on UDP port 162.”

4. Case, J. et al., RFC 3412 – SNMP Message Processing and Dispatching, §5: “All SNMP engines use UDP/162 as the well-known port for traps and informs.”

Unity Connection determines the subscriber mailbox from the SIP Diversion/Redirecting number delivered by CUCM.

If the SIP trunk toward Unity Connection is not configured to send this header, Unity Connection cannot match the call to a user and therefore plays the default (Opening) greeting.

Enabling “Redirecting Diversion Header Delivery – Outbound” on the CUCM-to-Unity Connection SIP trunk causes CUCM to include the necessary header. A trunk reset is required for the new setting to be applied to active call legs.

A. Rebooting Unity Connection does not change SIP header delivery; problem is in CUCM trunk configuration.

C. Checking the box without resetting leaves existing trunk instances running with old settings; change will not take effect until a reset.

D. Logs aid troubleshooting but do not modify signaling; voicemail mismatch persists.

1. Cisco “Integration Guide for Cisco Unity Connection 12.x and Cisco Unified Communications Manager using SIP”, Section ‘Configuring the SIP Trunk’, steps 12-14, pp. 6-7 – requirement to enable “Redirecting Diversion Header Delivery—Outbound”; states Opening Greeting played when unchecked.

2. Cisco Unity Connection 12.x “Troubleshooting Guide”, Topic ‘Caller Hears Opening Greeting Instead of Subscriber Greeting’, para. 2 – confirms Diversion header necessity.

3. Cisco Unified Communications Manager Administration Guide 14, Chapter ‘Resetting and Restarting Devices’, subsection ‘Resetting a SIP Trunk’ – reset required for configuration changes to take effect on the trunk.

When Cisco Expressway is deployed in the standard core/edge pair (Expressway-C inside, Expressway-E in the DMZ), it delivers two flagship functions.

1. Firewall-traversal for B2B and MRA traffic, providing a highly secure path through enterprise firewalls (option A).

2. Mobile and Remote Access (MRA), which lets off-premises users register to CUCM and use voice, video, IM&P, and directory services through a TLS–SRTP tunnel—no separate VPN client is required (option D).

B. Expressway offers basic call detail records; it is not designed for deep edge-traffic visibility or analytics.

C. Local registration/monitoring is still performed by CUCM; Expressway only proxies remote endpoint registrations, so coverage is not “complete.”

E. Utilization/adoption metrics come from Webex Control Hub, CUCM, or analytics tools, not from Expressway.

1. Cisco Expressway Series Data Sheet, “Features and Benefits – Secure firewall traversal; Mobile and Remote Access,” pp. 1-2, Cisco Systems, 2023.

2. Cisco Unified Communications Mobile and Remote Access via Cisco Expressway Deployment Guide, v14, Sec. 2.1 “Solution Benefits,” Cisco Systems, 2023.

3. Cisco Expressway Administrator Guide, X14, Ch. 20 “Call Detail Records” (limited reporting only), Cisco Systems, 2023.

For SIP phones the transport protocol that CUCM actually uses (UDP, TCP, or TLS) is taken from the device’s “Phone Security Profile.”

If the phone is still assigned to a Secure profile (TLS), CUCM will attempt to signal on TCP/5061. Because the administrator changed CUCM to use UDP, the signaling ports/protocols no longer match and the phone cannot set up calls.

Assigning or editing the phone to a Non-Secure SIP Phone Security Profile whose Transport Protocol is UDP restores registration and call establishment.

A. Common Phone Profile controls soft-key, feature and firmware parameters, not signaling transport; changing it will not affect UDP/TCP/TLS selection.

B. SIP Dial Rules manipulate digit strings dialed by the user; they have no impact on SIP transport.

C. SIP Profile adjusts timers, message contents and options; the transport protocol continues to be governed solely by the phone security profile.

1. Cisco Unified Communications Manager Security Guide, Release 14, “Configure SIP Phone Security Profiles,” Table 2-1: Device Security Mode vs. Transport Protocol, pp. 2-9–2-10.

2. Cisco Unified Communications Manager Administration Guide, Release 14, “Adding a SIP Phone,” step 7: “Select the appropriate Phone Security Profile; this setting determines whether UDP/TCP (Non-Secure) or TLS (Secure) is used,” pp. 2663-2664.

3. Cisco Unified Communications Manager Security Guide, Release 12.5(1), Chapter 3 “How CUCM Determines SIP Transport,” para. 2.

P-35 https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/350-801/page_35_img_1.jpg