Extension Mobility/EPNM on 4.1(3)

Unanswered Question
Jan 14th, 2008

I think that I already know the answer to this, but to be sure:

Is there a way to have the EPNM field be associated with the phone itself and not the line? In other words:If a phone has an EPNM of 2125551212 with the default profile and then I log into it, can the phone keep that mask or does it absolutely have to take a new mask associated with my user profile?

Thanks in advance,

Paul

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
William Bell Mon, 01/14/2008 - 16:49

Paul,

The external mask will be the one on the line(s) configured on the user device profile. Depending on what you want to accomplish and your dial plan needs you may give thought to modifying external masks on the translation and/or route patterns visible from the device level CSS on the IP phone you log into.

Regards,

Bill

pstebner10 Mon, 01/14/2008 - 17:23

Hi Bill-

Thanks for the reply. I'm going to try to explain exactly what I am trying to do:

I have a JTAPI control that is able to write to the EPNM field in CCM. This is used for phone location information. So, each physical phone needs a location (ELIN) associated with it. When someone logs in with extension mobility, that epnm is overwritten, negating the changes that I made.

I need to have the epnm always stay the same no matter who is logged onto the phone. I think that CSS is not the answer, since I could have thousands of locations.

Any ideas?

Thanks again,

Paul

William Bell Mon, 01/14/2008 - 21:14

Paul,

Interesting problem. I have played around with AXL/SOAP API and the Extension Mobility API a little bit and believe that these are the tools you will need. The SOAP/AXL API for CUCM is on http://www.cisco.com/pcgi-bin/dev_support/access_level/product_support. Interestingly enough I never have found the EM API there. If you search CCO for "Extenion Mobility API" you will see hits based on CUCM version. I am not sure what version CUCM you are using so I can't supply exact links.

You could build your own web application to handle the client request for EM logon. The EM API and XML SDK will give you plenty to build on here. By handling a client's request you can grab the IP address (can map to location) or the the SEP identifier. Using AXL you could query for the current external mask (logged out phone) by using a SQL query like (in 4.1):

select d.name as 'devicename',dmap.NumPlanIndex, dmap.E164Mask

from Device as d

inner join DeviceNumPlanMap as dmap on dmap.fkDevice = d.pkid

where d.name = 'SEPAAAAAAAAAAAA'

This will give you the index for lines configured on the device SEPAAAAAAAAAAAA (logged out device profile) and the E164 mask (external mask) on said line. You could then use AXL to write this information into the user device profile *before* completing the logon request. I would validate the user credentials first before doing an unnecessary rewrite but I would rewrite before executing the EM logon request to the EM API since you don't want to increase the user's time in getting to work.

One problem is if the user device profile has an external mask you want to preserve for some reason you will need to cache the old value and write it back after a logout event. If the new app handles manual logon and logoff events and has a way to cache values in a database or flat file structure that would address part of the problem. I am not sure how you would handle auto logoff events except by also keeping track of timers with your own application. Meaning you would need a watchdog routine of some type that checks logon time (your local copy of this data value) and then after the auto logout duration expires (as configured in CUCM) your application will need to rewrite values (after a query to EM API to verify if the user is logged off).

There are probably other alternative approaches to this problem, this is just one thought. I haven't done what you are trying to do but I have made custom apps to stand between EM logon requests and the EM API so I could grab information.

Hope that helps.

Regards,

Bill

pstebner10 Tue, 01/15/2008 - 08:23

Bill-

Thanks a million for that info. I am trying something along these lines and the following is happening:

DeviceName

SEP001BD513015C

ELIN

1231231234

Message

Code: 71

Message: Cannot generate profile when there is a user login to the device

Request: updatePhone

StackTrace

at xxx.AXLResponses.updatePhoneResponse(HttpWebRequest httprequest)

at xxx.AXLRequests.updatePhone(Uri uri, String user, String password, String devicename, String e164Mask)

Code: 71

Message: Cannot generate profile when there is a user login to the device

Request: updatePhone

System.Web.Services.Protocols.SoapException:

Code: 71

Message: Cannot generate profile when there is a user login to the device

Request: updatePhone

at xxx.AXLResponses.updatePhoneResponse(HttpWebRequest httprequest)

at xxx.AXLRequests.updatePhone(Uri uri, String user, String password, String devicename, String e164Mask)

at UpdateE164MaskQueue.UpdateE164MaskQueue.OnElapsedTime(Object source, ElapsedEventArgs e)

We are using the administrator account for CCM. Are there restriction on who can change a profile and when?

Thanks again,

Paul

William Bell Tue, 01/15/2008 - 18:36

Paul,

The problem appears to be that you are trying to do an updatePhone after the user logs on. Some thoughts. First, you want to write information into the profile before allowing the profile to logon. Second, you will need to use updateDeviceProfile request. Third, you want to be careful when updating lines on a device profile (or device for that matter) because if you execute the update request with a null 'lines' element then you will remove the lines from the profile. Further if the lines element is present all of the existing lines are removed and replaced with the lines you specify in the update request. Someone may know better but that has been my experience.

So, you first have a web URL that you point CUCM to to handle the logon request. The first thing your web app should do is grab the SEP ID and the IP address of the phone.

Next, you should provide the XML page to the phone necessary to grab logon information (keeping in mind that this information is not encrypted). So, now you have the user ID information and password.

Next, authenticate the user to verify they are who they claim to be. At the same time you need to determine the EM profiles that the user has available to them. One method is to query the LDAP directly (bypass CUCM) or use the AXL getUser request and look at the phoneProfiles section. If the user has more than one profile you will need to prompt the user (another XML render). In the end, you should be able to identify the profile the user is logging on with.

Up to this point you have:

a. ip address of phone

b. SEP address of phone

c. User ID and password. Confirmed they can logon

d. EM profile they wish to use.

Next, query the phone using the SQL query provided in earlier post. You will also need to construct a query to get line information on the device profile. You will want to get more information on the latter query because you are essentially going deconstruct and rebuild the lines (all lines) on the device profile. Once you have the current line configuration for your device profile. You will need to use the updateProfile AXL request to write back the reconfigured lines.

Once you have rewritten the device profile line information you can then use the EM API to log the user into the phone.

It does sound like a lot of work and it is possible that there is a more efficient way to update the lines in the CUCM database but since 4.1 doesn't allow SQL writes I don't know of a better way to do it. Maybe someone else in the community will have a more graceful method. You will want to look at the 4.1(3) AXL schema file (check URL in my original response for the developer web portal, valid CCO is all that is needed). You will also want to play around with the updateDeviceProfile so you know what it needs/expects.

Hope this helps,

Bill

pstebner10 Wed, 01/16/2008 - 13:21

Bill-

Thanks so much for your responses. You have been a big help.

I'm working on re-coding right now and hopefully it will work out.

Thanks again,

Paul

Actions

This Discussion