cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
349
Views
20
Helpful
7
Replies
floatingpurr
Beginner

Lock phone via AXL

Hi folks, I'm wondering if there is a way to lock a phone using CUCM's AXL. I'm looking for different available locking flavors, e.g.:

 

- lock dialing

- lock specific number patterns

- ...

 

or something equivalent. Is there anything available out of the box?

 

Thanx

1 ACCEPTED SOLUTION

Accepted Solutions

  • Extension Mobility sounds like perhaps the best fit:
    • The CUCM admin configures two device profiles for the target phone - i.e. one with 911-only and one with full access
    • At the phone, the user presses a button to access the E/M login screen, types in a pin, then the phone changes configuration (e.g. to the full access profile).  Via the same screen the user can logout (e.g. to the 911 only profile)
  • IP Phone Services API can be used to build web-site like applications the user interacts with via phone screen/touchscreen/buttons, etc.
    • This kind of application will require a web-server/service in place to provide the application logic.
    • There is no on-phone CGI/scripting capability - a server is always required.
    • The web service can initiate an Extension Mobility login/logout on behalf of the phone, or do something more specific/granular via AXL (such as change the phone's CSS)

Note: any phone CSS (or other) configuration will need to be done via CUCM AXL - there are no on-phone config APIs

 

View solution in original post

7 REPLIES 7
npetrele
Cisco Employee

One way to limit what users can dial is to use a Forced Authentication Code (addFacInfo in AXL).  Here's a description of what it does from the help page:

 

2022-02-09_105226.png

As for locking phones, you can do this with 3rd party software.  Or you can use extension mobility and calling search spaces. This fellow does a better job than I can do. Go to this community link and scroll down to William Bell's response.

https://community.cisco.com/t5/ip-telephony-and-phones/lock-unlock-for-cisco-phone/td-p/1463137

 

In general, you will want to do this by manipulating the configured calling search space on the phone, i.e. so that only the 911 CSS is in effect.  Note that CSS can be configured at the device level, and at the line/DN level (aka routePartition)

floatingpurr
Beginner

Thank you folks. Thank you for your suggestions. I guess there isn't any simple solution to set up a simple PIN-lock mechanism, without affecting "core" configurations or using a 3rd party software. Right?

Extension mobility (EM) gives you the ability to set up a simple PIN-unlock mechanism. But as far as I know, you can't use an AXL EM API alone to lock the phone. You need to add CSS and configure it all to work. I haven't tried William Bell's method, but it makes sense to me.

Thank you. Can you trigger the CSS variation directly from the phone with an API-like call?

  • Extension Mobility sounds like perhaps the best fit:
    • The CUCM admin configures two device profiles for the target phone - i.e. one with 911-only and one with full access
    • At the phone, the user presses a button to access the E/M login screen, types in a pin, then the phone changes configuration (e.g. to the full access profile).  Via the same screen the user can logout (e.g. to the 911 only profile)
  • IP Phone Services API can be used to build web-site like applications the user interacts with via phone screen/touchscreen/buttons, etc.
    • This kind of application will require a web-server/service in place to provide the application logic.
    • There is no on-phone CGI/scripting capability - a server is always required.
    • The web service can initiate an Extension Mobility login/logout on behalf of the phone, or do something more specific/granular via AXL (such as change the phone's CSS)

Note: any phone CSS (or other) configuration will need to be done via CUCM AXL - there are no on-phone config APIs

 

Thank you @npetrele and @dstaudt, I really appreciate your hints. AFAIU, the advantage of the bare extension mobility approach is relying only on the CUCM with its very own capabilities (e.g., redundancy, availability, scalability, etc...). Introducing another server in the machinery definitely adds more capabilities to what you can do at the application level. AFAIU, this server can't be a simple single box, otherwise you are probably in front of a Single Point of Failure. You might really want some type of architecture to keep such a system up & running (e.g., server replicas).

Create
Recognize Your Peers
Content for Community-Ad