This is gold right here Adam. Thanks. You've summarized everything very well. I've run into a few of these things and had forgotten about them.
It's difficult to impress design on someone without quoting technical limitations. Right now, you've hit the nail on the head with respect to voicemail access. That's going to be my baseline.
I think we might still proceed in testing out hunt groups though. Although we'd use a special configuration file since we don't want every jabber deployment having to see that. I think we might be able to work within whatever limitations that has.
With respect to my phone and dn order, what I was picturing was this.
Phone A and Phone B currently have all the same shared extensions in the same order, say 1001, 1002, 1003.
I want to add extension 2001 on Phone A as DN no. 4
I want to add extension 2002 on Phone B as DN no. 4
Then, I want to configure user1 with all four Jabber devices with 2001 as the primary, but also associate them to Phone A.
Similarly, I want to I want to configure user2 with all four Jabber devices with 2002 as the primary, but also associate them to Phone B.
This should work?
Alternatively, I could shuffle all DNs down one and install the personal extension on each hardware phone. But in the case of a 7940 with two shared lines, that's not possible without a phone swap.
-----Original Message-----
From: Pawlowski, Adam <ajp26@buffalo.edu>
Sent: Thursday, June 4, 2020 1:53 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>; cisco-voip voyp list <cisco-voip@puck.nether.net>
Subject: RE: Jabber and shared (primary) lines
CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
I have been pushing my shop to reduce the number of shared lines that are in use in general, and have been banging on that drum for a while. Having your own line and voicemail meshes better with other services, and keeps your data separate as far as records, messages, etc as privacy continues to be a thing that needs shoring up. That being said while a lot of things are now "person centric" this doesn't account for business processes.
We have deployed Jabber as the primary extension on BOT/TAB/TCT devices for customers who want to operate mobile and primarily cover a shared line, given this situation. Desktop we stack shared lines on as additional - I have a "bot" I can IM that just tosses them on there upon request. I have not tested it with Teams / UCM calling, but, I don't see why it wouldn't work.
My experiences have been:
- The call limits for a line on BOT/TCT/TAB are lower than CSF, which is lower than a desk phone. If you used a shared line to cover a busy line instead of an ACD, then this is where you could feel this pain. We all know what happens in these situations - "my phone didn't ring", "I couldn't transfer", "People got a busy signal", etc. Wrong tool for the job in those situations.
We've been trying to deploy hunt groups, but, in a system built to keep the company "flat", this has been challenging without large administrative overhead. You'd end up boxing people in to partitions where they are transformed calling out on/off premise to meet the requirement of being able to call from the shared line, and that can be a lot of work and doesn't scale well.
- If you're SSO enabled, setting the voicemail to "No Credentials" doesn't work anymore. So, regardless of what you do, you do not seem to be able to have these customers sign in to voicemail via Jabber for the shared line, which creates its own set of problems on how to cover voicemail. Jabber still does not work with dispatch messaging for whatever reason, so you're left with other not great options.
- Jabber multi-line I'm beginning to suspect is less tightly integrated into Jabber's code as it would seem. Since we've deployed the solution, we've run into issues with partial registration on a handful of customers. The right set of interruptions to connectivity can render lines beyond line one unregistered, and Jabber doesn't seem to have any awareness of this. It just monitors the state of the primary line and considers itself happy. In the meanwhile, calls to and from fail. From going blind looking at Jabber's PRT logs, it's become clear that there's a large soup of things in there, and managing it must be an absolute nightmare. Given other development priorities I don't know if this will ever get fixed unless they move on to something else.
I don't understand your question about deskphones with the lines in different order. That's an annoyance when trying to manage or maintain the sets, yes. We've moved to deploying the user's/station DN as primary, only copying this if the customer has multiple seats. We will not deploy a set any more with shared lines as line one all around an office. There are vague prohibitions on this in the UCM documentation, but it also makes identifying the set awful.
Best,
Adam
-----Original Message-----
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Lelio Fulgenzi
Sent: Thursday, June 4, 2020 11:41 AM
To: cisco-voip voyp list <cisco-voip@puck.nether.net>
Subject: [cisco-voip] Jabber and shared (primary) lines
What are people’s experiences with deploying Jabber with a shared line as the primary extension?
So, it would be two sets of four devices: botuser1, botuser2, csfuser1, csfuser2, etc.
But they would all have the same DN.
I doubt that Teams unified client in either CUCM or webex calling mode will support this, but still interesting in hearing stories.
Also, how about associating a hardware phone that has the DNs in a different order?
Go!
Sent from my iPhone
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip