System Manager and User Management - User Types 1

[learningSkype]

Been using SMGR for several years but never really learned User Management. Ex., how to build a station that uses an extension versus how to build just a SIP user, etc. A little confused about stations, so here's my question. If i go into User Management, then perform a search on an extension via the magnifying glass, say 5000, i see 2 options, 1 says Endpoint 5000, the second one says Off PBX Endpoint Mapping. This tells me i can modify the extension or i can modify station mapping, correct?

Second, if i build a station in CM, then go to SMGR and try to modify it so that i can make it a SIP user, do i need to add a CM Endpoint as well as a Session Manager Profile? i tried this the other day and added both but could not Commit my changes. It let me add the 2 profiles (Session Manager and CM Endpoint), but Commit was grayed out.

 

[kyle555]

To your second question - either do everything from System Manager re:CM station administration, or make sure "enable notifications" is turned on in the SMGR inventory for that CM. You'd need to import the SMGR root ca cert to CM if you haven't already.

So, SMGR pulls the CM config nightly and whenever you do an incremental sync. With those notifications enabled, you can setup a syslog from CM to SMGR and when SMGR sees in the CM history that user learningSkype did 'add station 5000', SMGR uses that as a trigger to 'display station 5000' and learn about it. Without that notification, it'll only learn via incremental sync either manually or at night. You can get yourself into a corner if you add in CM first but SMGR doesn't know about it - you'll do something like adding a user and you can tick 'use existing endpoint' but if SMGR hasn't known about 5000 being added, it won't be in there. So you go ahead without 'use existing endpoint' and SMGR tries to build station 5000 in CM and CM refuses because it already exists.

To your first question, when you type in an extension in that user search in SMGR, it can pull up a User or a Station or OffPBXStationMapping. It's kinda silly and unintuitive that it includes off-pbx station-mapping.

Starting from the basics - nothing stops you from firing up a SMGR and syncing to a CM with no SIP sets and using SMGR to manage those sets. You don't need 1 SMGR user per phone or anything. That's the 'endpoint' you're seeing when you search.

To use SIP telephony, you're using CM as a IP multimedia subsystem with Session Manager as the registrar on top. It's a common enough architecture in other telephony networks. Nortel had signaling servers that IP phones registered to and the sig server needed to get to the call server underneath that controlled TDM stuff.

To be able to have a SIP thing get down to CM (because that's where it's COR, COS, key programming, etc all live), you must build a SIP user.
That SIP user has a SIP handle and communication profile password - that's what the account logs in with.

That account has a Session Manager profile - as in, which SMs will allow that handle+pw to login. In the SM profile, there's also an originating and terminating app sequence (defined in SM-->network config-->apps and appseqs). To use CM, you must have it as your orig+term app sequence. If you left that blank and just built a user with a SM profile, you could log in to Session Manager and it would route your calls according to its dial patterns. But you'll have no features.

So, in that user's SM profile you'd add the orig+term app seq to point to CM. At this point, SMGR requires you to associate a CM Endpoint Profile for that user that the application sequencing will use. That's where you tie the SIP and PBX accounts together. The off-pbx station-mapping is the part that lets CM know how to get to SM for that app sequencing.

Without app sequencing:
1-A call comes in from a SIP trunk to 5000@customer.com. 5000 is registered. SM routes to the SIP client registered as 5000.
2-A call comes in from a SIP trunk to 5000@customer.com. 5000 is not registered. SM rejects the call.
3-5000@customer.com goes off hook. SM routes the request according to its dial patterns.

With app sequencing:
1-A call comes in from a SIP trunk to 5000@customer.com. SM has dial pattern 5000 point to CM. It routes to CM for processing. CM checks your station config and decides you can accept the call (not forwarded to voicemail, not using too many lines, wtv) and CM invokes the termination of the app sequence of your SIP station. It uses off-pbx station-mapping to learn how to get to SM for you (usually AAR but in CM7+ you can specify a route pattern instead) and CM pitches the call out to SM. You'll see something like ims-term and +avaya-cm-line1 in the SIP headers. SM gets this message and sends it to the SIP phone.

2-A call comes in from a SIP trunk to 5000@customer.com. Your SIP station is not registered. The call gets to CM anyway and hits your coverage path.
3-5000@customer.com goes off hook. SM invokes the originating app sequence and pitches to CM. CM will analyze digits based on COR, etc

Behind the scenes, under the hood, SMGR sucks out CM's config and stores it in it's database. SM's replicate that database - so the SMs know about the dial plans in the CMs supporting your users. SM crunches that data into profile information called PPM. When an Avaya phone registers to a SM, it does a HTTPS pull of that data from the SM - kinda like a 46xxsettings file, but very specifically for the account in question. That's how the phones get their key programming or get to know what the digit lengths are. In non-SIP, the PBX handles every digit - if 50xx and 51xx are in your dialplan but not 52xx, it's the PBX that rejects you when you dial 5 and then 2. In SIP, it's the endpoint. So, if you've ever configured a Polycom through it's web interface by hand, you'll see it has a dial plan config in there like 9xxxxxxxxxx|91xxxxxxxxxx|xxxxxxxxxx|1xxxxxxxxxx so it knows when you're done dialing. All that is automagic with Avaya SIP via PPM. That's not to say you have to do anything different to support a Polycom - it can just as easily register to an account defined for a 9600 phone, its just that it won't use any of the extra bells and whistles.

So, I think it's a little silly that station mapping should show in that search. You can define it in 'change off-pbx station-mapping 5000' or in the last page of change station 5000. You'd never need to change it. And you can't even save a SIP station without filling in the last page for the mapping anyway.

That leaves you with 2 results - user and station. You'd pick the user when you wanted to reset their SIP password, or do something with their higher-level SMGR account. You'd pick the station when you wanted to change their PBX phone - like add a key or something.

Make sense?

 

[learningSkype]

thx Kyle, very good and thorough explanation.

today i added a user in SMGR and went through all the mandatory settings. when i got to the "CM Endpoint Profile" section I selected the "use existing endpoints" check-mark to make sure it looked at my CM because i know the extension already exists. so all in all, not hard to set up once you get most of the specifics down.

i'm still confused as to why i tried this last week but couldn't add a user that already existed in CM. i tried last time to do this and found the user already in SMGR. so i just went into edit mode and added 2 things, a Session Mgr. Profile and a CM Endpoint Profile but it wouldn't let me commit. There had to be a conflict somewhere but SMGR wouldn't point it out, it just grayed out all the buttons for Commit or Commit and Continue...