[cisco-voip] Creating Jabber for non-existent phones

[Brian Meade]

Lelio,

I'm actually starting to work on creating some Python scripts to allow bulk
using the Quick User/Phone Add feature such as using it to add Jabber
devices for all users very quickly.  I'm also going to use this for bulk
deploying Remote Destination Profiles/Device Profiles.

I'm not sure if I'll share the full code or keep that internal to ePlus but
I'll share some of my findings around how these internal/non-documented
API's seem to be working behind the scenes.

Create a DN with a specific line template:

POST https://<CUCM>/ucmadmin/directorynumber/addDn/ HTTP/1.1

Body:

{"dnorpattern":"8888888888","universallinetemplate":"3a63b9c6-e867-4a37-82ca-9f5ad55d515c"}

200 OK response will contain the PKID of the new Directory Number.

Set Primary Extension.  Replace PKID after /enduser/ with PKID of the end
user, fknumplan/sortorder is the important part.
This one may be easier to set via AXL API instead.

PUT https://<CUCM>/ucmadmin/enduser/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"externData":{"groupAssociations":[],"extensions":[{"pkid":"","fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","sortorder":1,"lineDirectoryURI":{"fknumplan":"f8cfccf4-a37a-37f9-3b68-e3fa71eb5522","directoryuri":"","fkroutepartition":"","isprimary":false}}]},"credentialInfo":{"useDefaultCredential":false,"password":null,"passwordConfirm":null,"pin":null,"pinConfirm":null},"pkid":"98735c00-12d6-6e16-f985-7778d05806b1","firstname":"Brian","middlename":"","displayname":"","lastname":"Meade","userid":"bmeade-test","fkdirectorypluginconfig":null,"fkfeaturegrouptemplate":"41128559-bd7b-93cc-1166-01acf5b5bd4d","fkucuserprofile":"b2d3d9d0-a6bd-0136-d54f-bfee73f3ed74","userRank":"1","directoryuri":"","telephonenumber":"","mailid":"","manager":"","department":""}



Find a phone to move to a user.  Replace PKID in POST URI with PKID of end
user.  Device list shows PKID of device you want to move:

POST https://<CUCM>/ucmadmin/enduser/movePhones/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"devicelist":[{"pkid":"3784d3e8-62c9-4b26-bfaa-1e7c741511bd"}]}



Add a new phone for a user.  Replace PKID in POST with PKID of end user.
Replace device template PKID with the device template you want to use.
tkproduct is the model number from the typeproduct table.  isProfile is
used to say it's a device profile for extension mobility:

POST https://<CUCM>/ucmadmin/enduser/addPhone/98735c00-12d6-6e16-f985-7778d05806b1
HTTP/1.1

Body:

{"tkproduct":"30041","tkdeviceprotocol":"0","name":"SEPBMEADE","fkcommondevicetemplate":"580497c1-15e1-4e27-91ef-6f1e00f2e417","isprofile":"f","moduleCount":0}



On Wed, Jul 1, 2020 at 2:06 PM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

>
> Hello all. Looking for feedback and opinions and caveats.
>
> Right now, we’re deploying Jabber only to those with phones/DNs. But, we
> need to start deploying Jabber for those individuals without phones/DNs.
>
> Our SOPs include using Quick Add feature. (Thanks a million time Brian
> Meade for the pointer).
>
> My choices so far, to address Jabber for new those without phones:
>
> (a) Create a fake hardware phone first. This has many benefits, namely,
> all SOPs remain the same. Hardware phone would be deleted afterwards.
>
> (b) Use Directory Number admin page to create/update a DN first, then use
> Quick Add page to assign DN to user accordingly and then click manage
> devices and follow remaining SOP steps.
>
> (c) create line templates and use those when creating new extensions under
> quick add. The issue with this is we have so many combinations, I’d need a
> lot of templates.
>
> I’m leaning towards (b), since it gives me the best of both worlds.
>
> Thoughts?
>
> Lelio
>
> Sent from my iPhone
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200701/39bbc013/attachment.htm>