Posts

Showing posts from 2015

EMCC Call Routing

VC Phone CSS
HC Builds the following CSSes for VC Phone (priority order as listed):
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.Line CSS: Configured under the DN of EMCC UDPEMCC 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
Call from VC Phone to HC PhoneSignaling will take place between VC Phone <=> HC <=> HC PhoneMedia will flow directly between VC Phone <=> HC PhoneCall from VC Phone to VC PhoneSignaling will take place between EMCC VC Phone <=> HC <=> SIP/H323 ICT (no…

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 TemplateRegion settings (codec selection) - Advanced features => EMCC => EMCC Feature ConfigurationEMCC Region settings override normal region configurationAll 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 operationEMCC Roaming Device Pool - Determined via Geolocations & EMCC Geolocation FilterHC configures at least one Roaming DP per remote cluster. Each DP uses distinct geolocation characterizing that clusterPhones enabled for EMCC in VC must have be assigned a Geolocation at Device Pool or Phone Device levelLogin process sends phone’s Geolocation from VC to HCPhone’s Geolocation …

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 informationHC TFTP server builds the phone configuration file from temporary phone parameters and UDPHC will notify VC about TFTP Server details. VC will forward the details to the phone into order to contact TFTP server and get configuration filePhone downloads it…

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) HAddressInterfaceHold UptimeSRTTRTOQSeq (sec)(ms)Cnt Num 010.37.221.19Gi0/1.20412 1d00h1100014
R2#sh eigrp service-family ipv4 vrf MPLS neighbors EIGRP-SFv4 VR(saf) Service-Family Neighbors for AS(5) VRF(MPLS) HAddressInterfaceHold UptimeSRTTRTOQSeq (sec)(ms)Cnt Num 010.37.221.21Gi0/1.20414 1d00h1100014
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
HandleAddressPortKeepalive AT410.170.10.2005224424/30 Client name: UCM/10.170.10.200/NodeId=1/9.1.1.20000-5 AT610.170.10.2015733317/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
HandleAddressPortKeepalive AT1610.45.230.105307628/30

CUCM Call Hunting/Queueing - Flow Chart

Image