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-boun...@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
