User Community Feedback

Submitted ideas will be evaluated by our product teams for upcoming releases and will be responded to so you know where things stand. For product support, please use the community forums or contact TAC.

NOTE: All Cisco employees & Channel Partners must enter Ideas through this Ideas Portal.

Extension Moblity Cross Cluster - "Adjunct/Line/Profile CSS on Home Cluster" option

We would like to see a system option added to Additional Features > EMCC > EMCC Feature Configuration ... or ... Extension Mobility Service Parameters ... or ... CallManager Service Parameters ...
To permit the same kind of Adjunct CSS + Line CSS + [Device Profille] EMCC CSS construction, using Geolocation data from the Device, to locate a matching Device Pool for the above settings ... when an EM Device Profile is logged-in at the Home Cluster ... in the same way that EMCC constructs CSS today when an EM Device Profile is logged in from a Remote Cluster.
We have a legacy "PSTN" calling restriction standard that carries forward "8" (0-7) "Class of Restriction" levels (sometimes called "Facility Restriction Levels") and, outside of Extension Mobility, we are able to use a "Line/Device" Calling Search Space approach to much more efficiently manage our CSS(es): PSTN restrictions (Block Patterns) in the Line CSS combined with client-based, "abbreviated" dial plans. Approaching ~100 internal divisions / clients in the Device CSS(es).
We have the capability to use EAN and E164 long-form dialing to permit Global OnNet dialing, but our scale and divisional structure requires us to provide and maintain a large number of (4-5-digit) client-internal dial plans.
The original Extension Mobility feature "breaks" that Line/Device CSS model by utilizing the Line CSS from the logged-in user profile, and the "Device" CSS from the underlying physical device, wherever that phone happens to be.
Extension Mobility Cross Cluster has an existing mechanism to specify "EMCC Calling Search Space" on the User Device Profile, which is essential for the Home Cluster to have when a device from a Remote Cluster registers to it.
That combined "Adjunct/Line/EMCC-CSS" construction works great for the matrix-CSS design described above: (A) 112/911/999 Emergency Call routing is tied to the Adjunct CSS and based on the Geolocation of the calling device, (B) Line CSS, contains "PSTN-level" blocking patterns depending on the User Device Profile's Line settings, and (C) EMCC-CSS at a lower priority level from Adjunct and Line permits the User to "bring" their department's "short" dial plan with them when they log into a "Remote" Cluster.
But this only works when logging in at a Remote Cluster.
If a user logs in at an alternate phone within their Home Cluster, EMCC passes the EM service login through to the legacy "EM" feature, which takes the Device CSS of the phone (which could be a completely different department dial plan) and mixes it with the logged-in User's Line CSS.
In the current environment, to provide the granularity needed in our CSS(es) will require on the order of 800 named CSS(es) to fully migrate our legacy POTS and PBX users over to Call Manager. (8x100)
It would be a huge help to bring the Adjunct+Line+EMCC CSS feature construction to "Local" Extension Mobility logins, as a system-level feature, andwould bring our CSS(es) down an order of magnitude to ~108. (8+100)
Also a benefit, as Geolocation features on Devices become more robust and 911 2.0 more prevalent, locating a matching Device Pool with its particular Emergency Location Group setting based on Geolocation data from the phone on the local cluster will add robustness to the Native Emergency Call Routing feature where EMCC is active.

  • Kenneth Meeuwse
  • Nov 7 2020
  • Will not implement
  • Kenneth Meeuwse commented
    May 05, 2022 00:50

    Circling back around on this.

    For the proctor question: "...what is the problem that this solves. For PSTN access from EM devices, there already is the LRG configuration which makes sure that the correct gateway, based on logged in device location, is used for PSTN access."

    The issue with using LRG is that it assumes that one's dial plan is "location" based, and the call is to be steered to a Gateway versus inter-tenant OnNet. Short codes or Enterprise Significant Numbers that include a departmental or routing prefix based on physical site. LRGs can be triggered by the device's location (IP subnet) to route (usually PSTN) calls to a nearby gateway.

    Our departmental dial plans are not "location" based, but instead "department division based", so one could have several "short" or ESN dial plans sharing a common multi-tenant building depending on the tenant departments occupying the space. LRG could direct calls from these particular divisional dial plans to a nearby gateway based on the IP subnets (physical location / ERL), but we use a Line/Device CSS model to parse the Department's dial habits into the "Device" CSS (not Location) and PSTN OffNet into the "Line" CSS.

    This works fine for Devices (which can utilize a Line/Device CSS method), also for EMCC logged in devices IF they are logging in at a Visiting Cluster.

    However, since an EMCC login falls back to legacy "EM" when logging in at a Home Cluster, one cannot use the Device Profile's Extension Mobility Cross Cluster CSS as a combined CSS with Line CSS.

    In the older "EM", pre-EMCC mode, a Device Profile utilizes the Line CSS in combination with the Underlying physical Device's CSS, which precludes bringing the EM user's "department dial plan" with them (from their EMCC CSS which is an EMCC feature enhancement) in a hotel / hot desk scenario if they are logging in at a location that's also on their Home cluster.

    For logging in at a Visiting Cluster, the EMCC CSS is inserted with the Line CSS and this works.

    Having EMCC login function as "real EMCC" instead of falling back to the older "EM" when logging in at the Home Cluster would draw on the existing EMCC CSS feature in a flat single-cluster environment or in multiple-cluster environments where each covers a large geographic area.

  • Kenneth Meeuwse commented
    April 22, 2021 15:13

    Ideally, this new feature would permit use of the assigned Device Profile CSS in combination with the Line CSS by either:

    1. Adding a system wide option to utilize Device Profile CSS (currently called "EMCC CSS") in combination with Line CSS (instead of the local Device's CSS) in legacy Extension Mobility mode.

    or

    2. A system wide option to utilize EMCC routing logic (Adjunct-CSS + Line-CSS + UDP/EMCC-CSS), within the Home cluster, assuming EMCC function is activated and provisioned. SLRG and other "roaming" Device Pool features could be utilized by populating the Geolocation fields -- generally the DP of the device originating the call would possibly match "itself" for Geolocation. This could be useful but we would want to ensure that the UDP CSS would not be modified for internal dialing.

    Option 1 might be easier to accomplish programmatically, and then combine with the existing EMCC routing functions if/when a customer has multiple clusters.

  • Kenneth Meeuwse commented
    April 20, 2021 23:03

    Apologies for the delay in response. Several critical projects took over before I was able to consolidate my thoughts here.

    We are a large and diverse Enterprise with many (60+) Divisions that overlap within geographic footprint. But we exist only in one U.S. state. No international gateways. We use a globalized (normalized/localized) dial plan for routing, but have many individualized “Division-level”, translation patterns (Short) dial plans to permit abbreviated dialing by users at least within their respective Division and, where permitted by legacy numbers, logical partner Divisions.

    The emergence of SLRG has simplified PSTN access to gateways, without dependence on the older, Device CSS (in the Line+Device CSS model).

    In our case, we have almost no geographic gateway need (except in a few cases outside the most central of our PSAP. In most cases, our outbound PSTN (SIP) and/or Emergency Services 911 calls (PRI) route to common, redundant gateways, and thus are not dependent on local gateway exit.

    Further, current docs associated with EMCC imply that for support of users logging in EMCC, one should only use SLRG for Emergency Service number(s). Unless something has changed, it is my understanding that an Emergency Services (or any) SLRG call initiated from a phone logged in at a visiting location (to the Home cluster) sends “any” SLRG call toward the EMCC trunk back toward the visiting cluster for routing.

    https://www.cisco.com/c/en/us/support/docs/voice/call-processing/213965-emcc-call-routing-explanation-and-config.html

    “In EMCC environments it is best practice to use the SLRG for emergency calls only. This is because the SLRG in EMCC is used to send the call back to the visiting cluster through the EMCC SIP trunk.”

    We have three clusters and envision turning up EMCC so that any user can utilize EMCC at the other cluster locations.

    With SLRG as a known replacement for Device-CSS-based local gateway routing, Device CSS (in a Line+Device CSS concatenation) allows us to simplify implementation of our many, overlapping “Short” dialing (5-digit abbreviated) plans with a common, 8-level PSTN class-of-restriction model.

    We support an Enterprise of 60+ “Divisions”, each of which formerly had individual PBX, carrier service, DID ranges, extension ranges. Our provision of Call Manager as a service to these internal divisions, we can be thought of as a service provider to 60+ individual customers with existing, legacy short dial plans and existing DIDs cross LATA.

    Line CSS(es):

    0-Division-Internal-Only

    1-Enterprise-Only

    2-Local PSTN

    3-Regional PSTN

    4-State calling PSTN

    5-U.S. calling PSTN

    6-International-PSTN

    7-Operator-extended/VIP/Unrestricted PSTN

    Device CSS(es):

    Administration originated short dialing

    Emergency Services originated short dialing

    Human Services Agency

    Information Services originated short dialing

    Inspection Services originated short dialing

    Library originated short dialing

    Public Health originated short dialing

    Public Utilities originated short dialing

    Public Works originated short dialing

    Transportation Agency originated short dialing

    … (50+ additional organizations)

    Matching one Device CSS per entity with one of the 8 common PSTN class-of-restriction models Line CSS helps us avoid creating 480 separate “Line only” CSS(es).

    Of course, we will consolidate and merge dial plans where we can, but many of these entities have and expect to have their own Short dial plans, yet these entities are not necessarily separated by Location. They often overlap.

    In many cases, we have shared building spaces (even shared floors and Emergency Response Locations) that have more than one served Division – each with their own (short) dial plans – residing. So we cannot depend on Location or subnet detection in a Device Mobility model to select the particular Division user’s short plan.

    We utilize voice-subnet detection for Emergency Responder use and “Dispatchable Location” (Address+Floor/Suite), and this space could encompass two-to-three of our internal Divisions (short dial plans) in that space. The PSTN access and e911 codes are all common, since we are in the same U.S. geographic space.

    Example: Inspection Services Customer Center may have staffed representatives from City Planning division, Recreation and Parks, Building Inspection, Public Works working in teams in the same physical space.

    There is also geographic overlap in these “entity” dial plans at other physical locations: say a community Library part of the larger Library system, that has a Public Health clinic on-site but part of the larger Public Health organization.

    Utilizing a Line+Device CSS design allows us to have a common set of PSTN class-of-restriction levels (block patterns in the Line CSS), along with a Division-specific internal, short dial plan (in the provisioned Device CSS) as translation patterns to globalized numbers.

    This works well in the non-Extension-Mobility environment. It would work well within the EMCC environment – WHEN the user is logged into a Visiting Cluster.

    Where it does not work currently is when a user logs into Extension Mobility – assuming an EMCC environment is established – and the EMCC login passes the function through to the (Home) cluster as a standard EM.

    Standard EM utilizes the Device CSS associated with the guest device (not the logged-in user’s Device and/or Profile CSS) together with the Line CSS. So, the EM user “loses” their known short dialing for an unknown dial plan at the visited phone.

    We cannot utilize DMI/PLoc/DMG as a possible remedy because the IP Ranges here at voice subnet IP phones are physically based for ERL detection. Not Division – entity’s short dial plan. Voice subnets assigned by our Network Service division are based on physical ERL / Switch/IDF location, not customer client.

    What we would like to see is the ability to Utilize existing “EMCC CSS” (optionally renamed “Device Profile CSS) on the user’s Device Profile instead of the guest device’s CSS in a combined Line+Device CSS at the visited “hotel” phone.

    A system-wide option to utilize “EMCC” style CSS combination: Adjunct+Line+UDP/EMCC CSS … or a way to utilize UDP CSS instead of the underlying Device CSS when in regular EM … would be very useful to consolidate division/department level (Device/UDP) dial plans with a common PSTN (Line) dial plan.

    ---

    Note, we also have one more trick utilized in Device Mobility / DMI -> PLog/DMG -> Device Pool. We can detect registration of a phone from an “unknown” subnet / IP range (undefined ERL) and using DMG match modify Device CSS to permit only limited functionality (911 and Help Desk) until this is corrected. This ensures new voice subnets are fully provisioned for CER and PSALI before end-users moving devices on their own into that space, create an unknown location.

    ---

    At present, if we want our user clients to retain their known short dial plans when hotel (EM) sitting at a guest device intra-cluster, we would need to multiply our Line CSS(es) to create a separate series of 8 per Division – containing both the appropriate PSTN block codes, with the specific Division dial plan translation codes. This is not very scalable at 480 Line CSS(es) needed.

    Short dialing is inherently "internal" cluster or intra-cluster calling. So with a globalized dial plan, a Division level "short" translation pattern is need to globalize the destination.

    I hope this explains the use case, and I would be happy to discuss any further options.


  • Sanjay Sinha commented
    January 15, 2021 14:00

    Please provide additional information on what is the problem that this solves. For PSTN access from EM devices, there already is the LRG configuration which makes sure that the correct gateway, based on logged in device location, is used for PSTN access.
    For assigning device pool based on location, we do that for EMCC login, but not for EM.. For EM, device pool/Emergency LRG is assigned based on the IP address of the logged in device, not the location. In general, not all devices support sending the location information