[cisco-voip] Extension Mobility login causes Shared line outage on other phones.

[Scott Voll]

Thank you for the well documented reply.  TAC had me add a physical phone
with that DN on it, and associate the Shared DN / phone to the RMUser.  So
Far so good.  Stinks that I have to burn a physical phone..... but my
Helpdesk is Much much happier than getting not ready'd all the time.

Scott


On Wed, Mar 20, 2013 at 5:37 AM, Ryan LaFountain (rlafount) <
rlafount at cisco.com> wrote:

> Hi,
>
> Bill is correct that shared lines for ICD extensions are explicitly
> documented as unsupported and you will get an error when logging into CAD
> stating that the ICD extensions are shared.
>
> What Scott is mentioning is an issue we're working on now where one of the
> first four lines on the phone is shared. CCX automatically puts a CTI
> observer on the first four lines of the phone that have a DN assigned.
> This is to track call movements across lines like JAL and DTAL. But, if
> one of those lines is shared with another device, we don't monitor it
> because we do not want to pick up events for another device. The problem
> comes when activity on that line is really interesting to UCCX, but we
> don't receive it because we don't have an observer on that line.
>
> UCCX monitors the first four lines, not the first four buttons, so if you
> have a DN on line 1, 2, 5 and 6, all four will still be monitored.
>
> The documentation states the above, i.e. That UCCX 'does not monitor
> shared lines' but it doesn't say they are unsupported for personal
> extensions or other extensions on the phone.
>
> Behavior that we've observed due to this could be one of the following:
>
> 1. Agents being set into Not Ready when another EM user logs in (Scott's
> case)
>
> 2. Agents logging out of EM while logged in an Ready in CAD will cause
> them to remain Ready and call transfer attempts from UCCX to them will
> fail.
>
> We are tracking this in CSCuf02375.
>
> HTH.
>
> Thank you,
>
> Ryan LaFountain
> Unified Contact Center
> Cisco Services
> Direct: +1 919 392 9898
> Email: rlafount at cisco.com
> Hours: M ­ F 9:00am ­ 5:00pm
>
>
>
>
> On 2/13/13 11:52 PM, "Bill Talley" <btalley at gmail.com> wrote:
>
> >As I understood it from previous TAC and BU engagements, shared lines
> >were not supported on agent phones. I'm really surprised the agents
> >aren't getting an error when they log in to CAD that there's a shared
> >on the device.   You might be able to get around it by moving the
> >shared line down to line 5 or 6 on a phone, which are not monitored by
> >CCX if I recall correctly.
> >
> >Sent from an Apple iOS device with very tiny touchscreen input keys.
> >Please excude my typtos.
> >
> >On Feb 13, 2013, at 10:37 PM, Scott Voll <svoll.voip at gmail.com> wrote:
> >
> >> So we upgraded to CM 8.6.2 back in November.  we also upgraded UCCx to
> >>8.5.1 at the same time.
> >>
> >> We have been having issues with our Agents going not ready for what
> >>seemed to be a random reason (but only happening in the morning).
> >>
> >> TAC has helped use figure out how to reproduce it.
> >>
> >> our phones are configured with the primary line being unique to the
> >>user and is their UCCx agent number.  But line two is a shared line (our
> >>emergency Medical line).
> >>
> >> What we have figured out is that when a second / third / etc agent logs
> >>into Extension Mobility it kicks the other agents into not ready.
> >>
> >> Is this a Bug with CM or is this working as designed?  The TAC engineer
> >>could not reproduce it, but he had an older version of CM.
> >>
> >> TIA
> >>
> >> Scott
> >> _______________________________________________
> >> cisco-voip mailing list
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >_______________________________________________
> >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/20130320/10b66d24/attachment.html>