Showing results for 
Search instead for 
Did you mean: 

Extension Mobility Cross Cluster (EMCC) - Few logical aspects

Vivek Batra

Although EMCC configuration is straight forward... still there are couple of important and logical aspects which may be cumbersome to understand.


These are;


Adjunct CSS

CSS for PSTN Access SIP Trunk



First let see Geolocations. Geolocation is used by home cluster to assign desired Device Pool to visiting phone. Why visiting phone needs selective device pool?


Let say home cluster is in India whereas visiting cluster is in UK.

Now if India cluster user roams to UK and login from visiting phone in UK, s/he may want to see Indian time on phone or UK time depends on the requirement. Geolocation will help here. Let say visiting user in UK wants to see UK timing on his/her phone, then following configuration steps are required;


a. Configure Geolocation and Geolocation filter in visiting cluster viz UK.

b. Assign this Geolocation filter to visiting phone in UK.

c. Configure same Geolocation and Geolocation filter in home cluster viz India.

d. Create Device Pool and assign UK date/time group here. Also assign respective Geolocation in this Device Pool.


Doing so, when visiting phone in UK cluster sends the registration request to home cluster, it includes Gelocation information. Home cluster matches this Geolocation information and if match found with Device Pool Geolocation configuration, respective device pool is assigned to visiting phone.


EMCC template under BAT also plays important role in assigning Device Pool to visiting phone. If you want to assign same Device Pool to all visiting phones, you don't need to configure Geolocation under Device Pool in home cluster. Doing so, default Device Pool (from EMCC template) will be assigned to all visiting phones.



CSS for PSTN Access SIP Trunk

This parameter is configured under Advanced Features in CUCM.

This parameter has two options viz Use SIP Trunk CSS or Use Device Original CSS.


Let's understand this with the help of example.


Again we have home cluster in India and visiting cluster in UK.


Indian home cluster user roams to visiting cluster in UK and makes local call to UK by dialing 0044! (what s/he used to dial when in home cluster). Now which cluster should process this call. Yes you're right. As user is in UK, calls made to UK should ideally be processed by UK cluster. However visiting phone/user in EMCC still registers with home cluster (in India) so first call request will always come to India cluster. Here Standard Local Route Group plays an important role.


In India cluster, let say we have route pattern 0044! pointed to Route List which invokes Route Group having local India gateway. No SLRG invoked. If that is the case, this call will come on the way from UK to India on IP and then go back to UK through PSTN.


To avoid, Cisco recommends to use SLRG in this case if you want this call to be processed by visiting UK cluster. To get this, configure route pattern 0044! in India cluster and point this to Route List having first priority as Standard Local Route Group (SLRG). Now when visiting phone in UK dials number local to UK and home cluster receives this call, it will send this call to visiting cluster (through EMCC SIP trunk) if found call to be processed through SLRG.


Once visiting cluster receives this call on EMCC SIP Trunk, parameter 'CSS for PSTN Access SIP Trunk' plays an important role. Needless to say, 0044! route pattern should also exist in visiting cluster in UK.

When UK cluster receives this call on EMCC SIP Trunk, it has two options to match with respective route pattern depends on configuration of 'CSS for SIP Trunk PSTN Access;


-- Use SIP Trunk CSS - If this is set, inbound CSS on EMCC SIP Trunk will be used to match the route pattern 0044!

-- Use Phone Original CSS - If this is set, CSS of device (visiting phone) will be checked.


Please note that home cluster will send the call to visiting cluster only if SLRG is invoked else local gateway of home cluster will be used.



Adjunct CSS

So after device and line CSS, we have new CSS viz Adjunct CSS (difficult to pronounce, isn't it?)


I'm sure you are well known about line/device CSS approach. Here we are adding one more CSS in the list and is processed in following priority;


Adjunct CSS

Line CSS



Where device CSS has gone? So as user of home cluster is login through device which is a part of visiting cluster and we don't have physical device in home cluster, hence there is no device CSS but to keep the call routing logic same, device CSS is manipulated with EMCC CSS which is configured under Device Profile.


Now if you're familiar with Line/Device CSS approach, we have just one more CSS concatenated with Line and EMCC CSS. Still the question is 'Need of Adjunct CSS'.


Again take the two clusters viz Home cluster in India and visiting cluster in UK.

Home cluster user from India roams to visiting cluster in UK.

Visiting user in UK dials the emergency number 999.

That call request will come to home cluster in India. You can feel that why home cluster in India will be having configuration of emergency numbers of different geographic location. Yes, you are right, home cluster ideally should not have this configuration but to serve EMCC, India cluster should have emergency number configuration for all geographical locations where user can roam to.

So India cluster must be configured with route pattern 999.


Now you would not like Indian home users to see this route pattern as they never make emergency call in UK from India. Adjunct CSS serves this purpose. You should keep 999 in a partition which can be seen by Adjunct CSS only. Adjunct CSS is then assigned to Device Pool. How device pool is assigned to visiting phone has been discussed earlier.


So the Adjunct CSS is a way to keep the emergency number partitions to be not seen by local users and only available to visiting phones/users.




Recognize Your Peers
Content for Community-Ad