EMCC Call Routing

VC Phone CSS

HC Builds the following CSSes for VC Phone (priority order as listed):

1. Adjunct CSS: Configured in Roaming DP to support country specific emergency dialing plan (e.g., UK phone remotely registers back to US cluster; user dials 9.999 (UK emergency#) that US cluster will normally not recognize). May skip Adjunct CSS configuration if HC and VC share the same emergency pattern and Local Route Groups are implemented.
2. Line CSS: Configured under the DN of EMCC UDP
3. EMCC CSS: Configured under UDP as 'Extension Mobility Cross Cluster CSS'. Note that UDP doesn't have CSS option for EM. It is available only for EMCC

VC Phone Call Flow

1. Call from VC Phone to HC Phone
• Signaling will take place between VC Phone <=> HC <=> HC Phone
• Media will flow directly between VC Phone <=> HC Phone
2. Call from VC Phone to VC Phone
• Signaling will take place between EMCC VC Phone <=> HC <=> SIP/H323 ICT (not EMCC SIP Trunk) <=> VC <=> Local VC Phone
• Media will flow directly between VC Phones
• The users will dial the phone next to them as if they were in the Home cluster, Home Cluster Dialing Habits should be Maintained
3. Call from VC to PSTN (No SLRG)
• Signaling will take place between VC Phone <=> HC <=> HC GW
• Media will take place between VC Phone <=> HC GW
• Incoming calls for this DID will always be received on the HC GW
4. Call from VC to PSTN (SLRG)
• In EMCC, RP with SLRG doesn't point to LRG configured in Roaming DP. Instead, it sends the call over EMCC SIP Trunk to VC
• VC Cluster checks its own dialplan to route the call. EMCC SIP Trunk needs a CSS to access the dialplan. The selection of the CSS can be defined under 'Advanced Features > EMCC > EMCC Feature Configuration':
• Use Trunk CSS
• Use Phone's Original Device CSS
• VC will use original VC Phone DP to determine the LRG and get the exit gateway (not EMCC SIP Trunk DP LRG). If VC Phone original DP doesn't have LRG configured, call will fail
• Signaling will take place between VC Phone <=> HC <=> EMCC SIP Trunk <=> VC <=> VC GW
• Media will take place between VC Phone <=> VC GW
• Dialing habits should be maintained for HC
5. Emergency Calls
• Emergency Calls require SLRG to route the calls out of the local gateway for proper call handling
• VC Phone will use 'Adjunct CSS' assigned to Roaming DP to match the emergency RP. This RP shouldn't be accessible to HC Phones
• Signaling will take place between VC Phone <=> HC <=> EMCC SIP Trunk <=> VC <=> VC GW
• Media will take place between VC Phone <=> VC GW

Note: If LRGs are already deployed for the Emergency route pattern AND a home and visiting cluster pair have the same Emergency dial string, use of the Adjunct CSS is not required

Calling Party Presentation

• The Calling Party number leaving the VC gateway should be the HC +E164 format
• Calling number transformation can take place on incoming EMCC SIP Trunk, on Route Patterns, or egress on the VC Gateway

EMCC Configuration File/Parameters

Since the phone configuration doesn't exist in HC, phone parameters will be obtained as follow:

• Common Device Configuration & Common Phone Profile - Bulk Administration => EMCC => EMCC Template
• Region settings (codec selection) - Advanced features => EMCC => EMCC Feature Configuration
1. EMCC Region settings override normal region configuration
2. All EMCC Region parameters MUST be configured with same values in ALL clusters. If they are different, RSVP Agent for that cluster will be disabled by Remote Cluster Update operation
• EMCC Roaming Device Pool - Determined via Geolocations & EMCC Geolocation Filter
1. HC configures at least one Roaming DP per remote cluster. Each DP uses distinct geolocation characterizing that cluster
2. Phones enabled for EMCC in VC must have be assigned a Geolocation at Device Pool or Phone Device level
3. Login process sends phone’s Geolocation from VC to HC
4. Phone’s Geolocation is filtered by ‘EMCC Geolocation Filter’ on HC (Advanced features => EMCC => EMCC Feature Configuration)
5. Using filtered geolocation, HC finds the most suitable DP for roaming DP
6. HC uses Roaming DP to build EMCC Phone configuration in database
• Phone Parameters (date-time group, Adjunct CSS, CUCM-Group, etc) - EMCC Roaming Device Pool

Note: If Roaming DP isn't present in HC, VC Phone will inherit UDP DP configured in HC

EMCC Login/Registration Process

• Users from a “Home” Cluster (HC) login to a phone at a “Visiting” Cluster (VC)
• VC doesn't recognize userID and PIN. Accordingly, VC forwards the login request to HC to verify if it knows the user.
• HC confirms the locality of the userID. In case of multiple EMCC clusters, VC forwards the request to all EMCC clusters. The one acknowledging the userID is considered as HC.
• VC complies phone device information and send it back to HC (usreID, passwd, device name, protocol, model, cluster id, geolocation)
• HC will authentication user credentials. If user credentials accepted, HC database builds a temporary phone device using EMCC template combined with received phone information
• HC TFTP server builds the phone configuration file from temporary phone parameters and UDP
• HC will notify VC about TFTP Server details. VC will forward the details to the phone into order to contact TFTP server and get configuration file
• Phone downloads its TFTP configuration from HC TFTP server and then cross registers with HC CUCM

Notes:

• Phone Loads are not enforced during the Login process.  Removed from Home Cluster config.
• If HC locale is different, phone will download new locale from HC TFTP server. If not available, maintains VC locale.
• DLUs are NOT consumed in the Home Cluster for the visiting phone.
• Communication between EMCC Clusters takes place using TLS Encrypted messages. EMCC SIP Trunk isn't used for this purpose.
   
  

How to Check if CCD/SAF is Working?

Step1 Verify that SAF neighborship is established between SAF forwarders.

R1#sh eigrp service-family ipv4 vrf MPLS neighbors

EIGRP-SFv4 VR(saf) Service-Family Neighbors for AS(5)

           VRF(MPLS)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.37.221.19            Gi0/1.204                12 1d00h       1   100  0  14

R2#sh eigrp service-family ipv4 vrf MPLS neighbors

EIGRP-SFv4 VR(saf) Service-Family Neighbors for AS(5)

           VRF(MPLS)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.37.221.21            Gi0/1.204                14 1d00h       1   100  0  14

Step2 Verify the at SAF Client registered with SAF Forwarder

R1#show service-routing xmcp clients

Service-Routing XMCP Clients

Codes: A - Authenticated, T - TCP

    Handle     Address                                    Port  Keepalive

AT  4          10.170.10.200                             52244    24/30 

    Client name: UCM/10.170.10.200/NodeId=1/9.1.1.20000-5

AT  6          10.170.10.201                             57333    17/30 

    Client name: UCM/10.170.10.201/NodeId=2/9.1.1.20000-5

R2#sh service-routing xmcp clients

Service-Routing XMCP Clients

Codes: A - Authenticated, T - TCP

    Handle     Address                                    Port  Keepalive

AT  16         10.45.230.10                              53076    28/30 

    Client name: UCM/10.45.230.10/NodeId=1/9.1.2.13900-10

Step3 Verify SAF routing table. You can see below the SAF Services learned from SAF forwarders and SAF Clients. Service ID 101:2:* refers to CCD Service.

On R1 SAF forwarder, you can see two CCD Services directly connected (learned from SAF Clients 10.170.10.200 and 10.170.10.201) and one CCD service learned from R2 SAF forwarder (SAF Client is 10.45.230.10).

R1#sh service-routing database

Service-Routing Database

Service ID (Service:Subservice:Instance)         Trust     Domain Owner Size

------------------------------------------------ --------- ------ ----- -----

      100:1:46545831-3634-3441-4853-430000000000 Connected *      1       333

      100:1:46545831-3634-3441-4853-4D0000000000 Learned   5      3       333

      100:2:46545831-3634-3441-4853-430000000000 Connected *      1      1426

      100:2:46545831-3634-3441-4853-4D0000000000 Learned   5      3      1426

      101:2:8976FD5D-F82E-62BC-AB80-DF860001B241 Connected 5      4       669

      101:2:8976FD5D-F82E-62BC-AB80-DF860002ED97 Connected 5      6       669

      101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 Learned   5      3       680

Step4 You can see the contents of the CCD Service learned from SAF Clients/Forwarders.

R1#show service-routing database 101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 text

Service-Routing Database

Service ID (Service:Subservice:Instance)         Trust     Domain Owner Size

------------------------------------------------ --------- ------ ----- -----

      101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 Learned   5      3       680

          Owner: SAF Forwarder AS(5) SFv4 VRF(MPLS)

          Sequence: 4       

          AFI: IPv4

          VRF: MPLS, Tableid: 3

          Subscription Handles:  5, 6

          Reachability:

            IPv4: 10.45.230.10:5060, protocol 6 (TCP)

          Service Data:

UCM9.1.2.13900-10sb-cluster10.45.230.10

sip:0a2d209c-6015-65c7-1071-bdaf032de992@CCMPub-SB

4XXX
3XXX

          Service Metadata:

You can see that the CCD Service was originated from sb-cluster with IP address of 10.45.230.10 and learned through SAF Forwarder. Also, the service contains two CCD patterns (hosted DNs) which are 4XXX and 3XXX.

Step5 You can verify the learned CCD Patterns on CCD Requesting clients using RTMT. Go to Call Manager > Report > Learned Patterns.

CUCM Call Hunting/Queueing - Flow Chart