Re: [cisco-voip] 8865s and MRA CUCM registration failover issue

[Aman Chugh]

Phone are setup using sip profile to refresh registration every 120 seconds
by default . You should see expressway pass these to cucm servers every 120
seconds from the phone.

I would recommend you to turn up expressway logs to see if the phone is
sending sip register to Cucm 1 ,  cucm 2 and cucm 3 .

I had tested with two cucm subscribers in a group but not with a third one.


On Wed, Nov 27, 2019 at 3:15 PM Erick Bergquist  wrote:

> New bug filed, still working on issue with MRA phones not failing over
> to second CCM in UCM group.
>
> CSCvs10183 -- 8845/8865 MRA phones do not failover to tertiary CUCM
>
> On Wed, Oct 30, 2019 at 5:47 PM Erick Bergquist 
> wrote:
> >
> > Anthony,
> >
> > Meant 12.5.5.  Looks like you’ll be doing similar setup as this one.
> >
> >
> > On Wed, Oct 30, 2019 at 5:35 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
> >>
> >> Erick,
> >>
> >> It doesn't look like there was an X8.12.5.  Did you mean X12.5?  Or was
> that a version they pulled?
> >>
> >>
> https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-release-notes-list.html
> >>
> >> What is "this" in the context of your question? The Jabber IM only, or
> the TC/CE endpoints?
> >>
> >> Also, I'm going to be doing a clustered X8.11.4 deployment here shortly
> and will have three CUCM CPEs, and so I'll be doing some testing and
> whatnot.
> >>
> >> If I run into issues, I'll let you know, but I will also be filing a
> defect, should one need be created at that time.  Possibly even a
> documentation defect, since the guides don't specify quantity of CUCM
> servers; it's left at simply: CUCM fail over.
> >>
> >> On Wed, Oct 30, 2019 at 5:09 PM Erick Bergquist 
> wrote:
> >>>
> >>> Is there a 8.12.5 enhancement to help with this specifically?   On
> >>> 8.11.4 at moment.
> >>>
> >>> On Wed, Oct 30, 2019 at 2:58 PM Benjamin Turner <
> benmtur...@hotmail.com> wrote:
> >>> >
> >>> > This will work with jabber since you are not  testing the failover
> of presence. And phone models TC/CE would would work regardless of a
> clustered C and E. 12.5 should have fixed these issues but..
> >>> >
> >>> > Get Outlook for Android
> >>> >
> >>> > 
> >>> > From: cisco-voip  on behalf of
> Erick Bergquist 
> >>> > Sent: Wednesday, October 30, 2019 4:05:06 PM
> >>> > To: Ryan Ratliff (rratliff) 
> >>> > Cc: voip puck 
> >>> > Subject: Re: [cisco-voip] 8865s and MRA CUCM registration failover
> issue
> >>> >
> >>> > Understood, will keep pushing that angle and try to get some answers
> >>> > on the differences and 88xx MRA capabilities.
> >>> >
> >>> > Thanks.
> >>> >
> >>> > On Wed, Oct 30, 2019 at 1:57 PM Ryan Ratliff (rratliff)
> >>> >  wrote:
> >>> > >
> >>> > > The implementation is different for TC/CE, phones, and Jabber
> (Teams I would expect to mirror Jabber).
> >>> > >
> >>> > > I still think a bug is warranted, if nothing else to track the
> expectation. Back in the x8.11 days we had to get the docs updated to
> reflect that fact that phones weren't redundant without clustered
> Expressways, this seems to be a variant of that.
> >>> > >
> >>> > > -Ryan
> >>> > >
> >>> > > On 10/30/19, 3:54 PM, "Erick Bergquist" 
> wrote:
> >>> > >
> >>> > > Pair of expressways, clustered.  DX 70/80s happen to work fine
> with
> >>> > > all 3 over MRA.
> >>> > >
> >>> > > On Wed, Oct 30, 2019 at 1:13 PM Ryan Ratliff (rratliff)
> >>> > >  wrote:
> >>> > > >
> >>> > > > IIRC (it's been a looong time since I looked into this)
> failover with RMA was based on device->Expressway-E redundancy, not so much
> Expressway->CUCM.
> >>> > > > This is why you don't get any redundancy without a clustered
> Expressway.
> >>> > > >
> >>> > > > I'd recommend treating it as a bug and pushing for one to be
> created. If you have two Expressway-Es in the cluster (and the phone knows
> this via DNS lookups) then it should maintain connections to an active and
> standby CUCM.
> >>> > > >
> >>> > > > If anyone happens to have a cluster of 3 Expressways to test
> with, I wonder how that would look.
> >>> > > >
> >>> > > > - Ryan
> >>> > > >
> >>> > > > On 10/30/19, 2:57 PM, "cisco-voip on behalf of Erick
> Bergquist"  erick...@gmail.com> wrote:
> >>> > > >
> >>> > > > Following up on this, still working to figure this out
> and have been
> >>> > > > working with TAC.
> >>> > > >
> >>> > > > Does anyone know if the 8865s when using MRA use only
> the first 2
> >>> > > > servers in UCM group or will also the third server if
> present?
> >>> > > >
> >>> > > > On the 8865 phone web page it shows all 3 servers from
> UCM group.
> >>> > > >
> >>> > > > On the phone information page on phone itself, it shows
> the Active
> >>> > > > Server and Stand-by Server only.
> >>> > > >
> >>> > > > When we make the first server unreachable (CCM1) the
> 8865 over 

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Lelio Fulgenzi]

In actuality, it’s less complicated than that. All the system does is look for 
a properly formatted SIP address. If it finds it, the button pops up. This is 
effectively how I tested gmail to org A and got it to work.

The issue is that the way they have implemented the detail look up, i.e. 
looking in your own calendar or the originator’s. Or something like that. 
There’s fall back, but that breaks with CH Org to CH org when both are o365 
hybrid calendar integrated.


This applies to Webex room devices as well.

https://help.webex.com/en-us/wt50w0/Meetings-with-Video-Addresses-in-Your-Cisco-Webex-Teams-Meetings-List

Supported Video Address Formats
sip:alphanume...@example.com
sips:alphanume...@example.com
sip:123_4...@example.com
sip:12...@example.com
12...@example.com
dial meeting
dial conference
12...@example.com


From: Matthew Loraditch 
Sent: Thursday, January 23, 2020 4:47 PM
To: Lelio Fulgenzi ; Anthony Holloway 
; Cisco VoIP Group 
Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms

Interesting. Its like they added extra logic to it instead of just if webex 
info exists add button

Get Outlook for iOS

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com
 |
e: mloradi...@heliontechnologies.com
[Helion Technologies]
[Facebook]
[Twitter]
[LinkedIn]
[cid:image011.jpg@01D5D20E.92EE3F00]

From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Thursday, January 23, 2020 4:37:02 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>; 
Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>; 
Cisco VoIP Group mailto:cisco-voip@puck.nether.net>>
Subject: RE: [cisco-voip] Webex + OBTP + Multiple Rooms

[EXTERNAL]


You’d think… but like I explained in my response, this does not work if both 
Orgs are CH orgs with O365 calendar integration enabled.



It almost goes against what you’d think. Webex to Webex didn’t work. But Gmail 
Calendar to Webex did. 



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Matthew Loraditch
Sent: Thursday, January 23, 2020 4:30 PM
To: Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>; 
Cisco VoIP Group mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms



Presuming a Microsoft environment the recipients can just forward the invite to 
the relevant room mailboxes no matter the org. As long as the webex section is 
unaltered the meetings should be picked up by the webex obtp process



Get Outlook for iOS



Matthew Loraditch​

Sr. Network Engineer

p: 443.541.1518

w: www.heliontechnologies.com

 |

e: mloradi...@heliontechnologies.com

[Helion Technologies]

[Facebook]

[Twitter]

[LinkedIn]

[cid:image011.jpg@01D5D20E.92EE3F00]



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Sent: Thursday, January 23, 2020 4:20:19 PM
To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms



[EXTERNAL]



Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?



I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.



And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.



If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Lelio Fulgenzi]

Not fixed yet. ☹

From: Lelio Fulgenzi 
Sent: Thursday, January 23, 2020 4:42 PM
To: Lelio Fulgenzi ; Anthony Holloway 
; Cisco VoIP Group 
Subject: RE: [cisco-voip] Webex + OBTP + Multiple Rooms

I just pinged my contact. Let’s hope they’ve resolved this.

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Thursday, January 23, 2020 4:35 PM
To: Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>; 
Cisco VoIP Group mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms

I spent some time with this. If you’re talking about the same Org, it’s very 
easy. Either the host books all rooms, or the participant can forward the 
invite to the room they want. In this case, forwarding has to be enabled on the 
original invite and the room resources has to be set to auto-accept forwarded 
invites and also to include all details in the calendar entry.

When you start talking about org to org, things start to get freaky. I don’t 
begin to understand the intricacies, but it comes down to whether the system is 
setup to use the originator’s details or the room’s details. They’re working 
things out last time I checked.

In my case, I was trying to test org to org, from my trial org to my production 
org. Because they were both Webex enabled O365 orgs with calendar integration 
enabled, this would _not_ work and won’t work until they fix things. Basically, 
Org A sets the meeting, and the participant from Org B forwards to their room 
to book the room. But the room device never sees the appt. (but the calendar 
does).

When I was asked to test an external org, like gmail, I was able to create a 
calendar entry and invite Org B and Org B was able to forward to their room, 
and the room device showed the OBTP. There were some odd things in play, like 
title and stuff, but they’re working on some of that as well. I think there 
were a bunch of room settings to fix some of them as well.

I’m hoping that with the next upgrade, and some other back end improvements, 
they will have org to org forwarding appts working whether or not they’re both 
CH orgs, both with O365 calendar integration enabled or, one is a non-webex, 
non-CH org and the other is a webex org.

Not sure if that makes sense how I wrote that down.





From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Anthony Holloway
Sent: Thursday, January 23, 2020 4:20 PM
To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms

Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Matthew Loraditch]

Interesting. Its like they added extra logic to it instead of just if webex 
info exists add button

Get Outlook for iOS

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com

From: Lelio Fulgenzi 
Sent: Thursday, January 23, 2020 4:37:02 PM
To: Matthew Loraditch ; Anthony Holloway 
; Cisco VoIP Group 
Subject: RE: [cisco-voip] Webex + OBTP + Multiple Rooms


[EXTERNAL]


You’d think… but like I explained in my response, this does not work if both 
Orgs are CH orgs with O365 calendar integration enabled.



It almost goes against what you’d think. Webex to Webex didn’t work. But Gmail 
Calendar to Webex did. 



From: cisco-voip  On Behalf Of Matthew 
Loraditch
Sent: Thursday, January 23, 2020 4:30 PM
To: Anthony Holloway ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms



Presuming a Microsoft environment the recipients can just forward the invite to 
the relevant room mailboxes no matter the org. As long as the webex section is 
unaltered the meetings should be picked up by the webex obtp process



Get Outlook for iOS



Matthew Loraditch​

Sr. Network Engineer

p: 443.541.1518

w: www.heliontechnologies.com

 |

e: mloradi...@heliontechnologies.com

[Helion Technologies]

[Facebook]

[Twitter]

[LinkedIn]

[cid:image005.jpg@01D5D20B.56026B50]



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Sent: Thursday, January 23, 2020 4:20:19 PM
To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms



[EXTERNAL]



Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?



I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.



And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.



If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Lelio Fulgenzi]

I just pinged my contact. Let’s hope they’ve resolved this.

From: cisco-voip  On Behalf Of Lelio 
Fulgenzi
Sent: Thursday, January 23, 2020 4:35 PM
To: Anthony Holloway ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms

I spent some time with this. If you’re talking about the same Org, it’s very 
easy. Either the host books all rooms, or the participant can forward the 
invite to the room they want. In this case, forwarding has to be enabled on the 
original invite and the room resources has to be set to auto-accept forwarded 
invites and also to include all details in the calendar entry.

When you start talking about org to org, things start to get freaky. I don’t 
begin to understand the intricacies, but it comes down to whether the system is 
setup to use the originator’s details or the room’s details. They’re working 
things out last time I checked.

In my case, I was trying to test org to org, from my trial org to my production 
org. Because they were both Webex enabled O365 orgs with calendar integration 
enabled, this would _not_ work and won’t work until they fix things. Basically, 
Org A sets the meeting, and the participant from Org B forwards to their room 
to book the room. But the room device never sees the appt. (but the calendar 
does).

When I was asked to test an external org, like gmail, I was able to create a 
calendar entry and invite Org B and Org B was able to forward to their room, 
and the room device showed the OBTP. There were some odd things in play, like 
title and stuff, but they’re working on some of that as well. I think there 
were a bunch of room settings to fix some of them as well.

I’m hoping that with the next upgrade, and some other back end improvements, 
they will have org to org forwarding appts working whether or not they’re both 
CH orgs, both with O365 calendar integration enabled or, one is a non-webex, 
non-CH org and the other is a webex org.

Not sure if that makes sense how I wrote that down.





From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Anthony Holloway
Sent: Thursday, January 23, 2020 4:20 PM
To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms

Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Lelio Fulgenzi]

You’d think… but like I explained in my response, this does not work if both 
Orgs are CH orgs with O365 calendar integration enabled.

It almost goes against what you’d think. Webex to Webex didn’t work. But Gmail 
Calendar to Webex did. 

From: cisco-voip  On Behalf Of Matthew 
Loraditch
Sent: Thursday, January 23, 2020 4:30 PM
To: Anthony Holloway ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Webex + OBTP + Multiple Rooms

Presuming a Microsoft environment the recipients can just forward the invite to 
the relevant room mailboxes no matter the org. As long as the webex section is 
unaltered the meetings should be picked up by the webex obtp process

Get Outlook for iOS

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com
 |
e: mloradi...@heliontechnologies.com
[Helion Technologies]
[Facebook]
[Twitter]
[LinkedIn]
[cid:image005.jpg@01D5D20B.56026B50]

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>>
Sent: Thursday, January 23, 2020 4:20:19 PM
To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms

[EXTERNAL]

Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Lelio Fulgenzi]

I spent some time with this. If you’re talking about the same Org, it’s very 
easy. Either the host books all rooms, or the participant can forward the 
invite to the room they want. In this case, forwarding has to be enabled on the 
original invite and the room resources has to be set to auto-accept forwarded 
invites and also to include all details in the calendar entry.

When you start talking about org to org, things start to get freaky. I don’t 
begin to understand the intricacies, but it comes down to whether the system is 
setup to use the originator’s details or the room’s details. They’re working 
things out last time I checked.

In my case, I was trying to test org to org, from my trial org to my production 
org. Because they were both Webex enabled O365 orgs with calendar integration 
enabled, this would _not_ work and won’t work until they fix things. Basically, 
Org A sets the meeting, and the participant from Org B forwards to their room 
to book the room. But the room device never sees the appt. (but the calendar 
does).

When I was asked to test an external org, like gmail, I was able to create a 
calendar entry and invite Org B and Org B was able to forward to their room, 
and the room device showed the OBTP. There were some odd things in play, like 
title and stuff, but they’re working on some of that as well. I think there 
were a bunch of room settings to fix some of them as well.

I’m hoping that with the next upgrade, and some other back end improvements, 
they will have org to org forwarding appts working whether or not they’re both 
CH orgs, both with O365 calendar integration enabled or, one is a non-webex, 
non-CH org and the other is a webex org.

Not sure if that makes sense how I wrote that down.





From: cisco-voip  On Behalf Of Anthony 
Holloway
Sent: Thursday, January 23, 2020 4:20 PM
To: Cisco VoIP Group 
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms

Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Webex + OBTP + Multiple Rooms

[Matthew Loraditch]

Presuming a Microsoft environment the recipients can just forward the invite to 
the relevant room mailboxes no matter the org. As long as the webex section is 
unaltered the meetings should be picked up by the webex obtp process

Get Outlook for iOS

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com

From: cisco-voip  on behalf of Anthony 
Holloway 
Sent: Thursday, January 23, 2020 4:20:19 PM
To: Cisco VoIP Group 
Subject: [cisco-voip] Webex + OBTP + Multiple Rooms


[EXTERNAL]


Excuse my ignorance here, but how do you see people using Webex OBTP when the 
host is booking a room+device, and there is a remote office or two, and they 
would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one 
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the participants 
are in Org B, which eliminates the first scenario, but promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly by 
just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Webex + OBTP + Multiple Rooms

[Anthony Holloway]

Excuse my ignorance here, but how do you see people using Webex OBTP when
the host is booking a room+device, and there is a remote office or two, and
they would like the OBTP to join in their rooms too?

I could see two scenarios: 1) the host would need to book all rooms on one
invite, or 2) the participants book their own rooms.

And come to think of it, what if the host is in Org A, while the
participants are in Org B, which eliminates the first scenario, but
promotes the second.

If in scenario 2, are the participants getting the OBTP to work correctly
by just manual copy/paste the invite body into their own separate invite?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CCX phone agent over MRA?

[Lelio Fulgenzi]

p.s. I just caught that bug description and your comment. Omg.

From: Anthony Holloway 
Sent: Thursday, January 23, 2020 3:30 PM
To: Lelio Fulgenzi 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] CCX phone agent over MRA?

Are you talking Finesse IP Phone Agent (FIPPA)?

If so, the below enhancement defect requesting that these types of details be 
documented (I mean should we even have to request that?) states that they 
tested FIPPA via MRA and it worked.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi51697

Just know that you'll have to add your UCCX server addresses to the HTTP Allow 
list on Expressway-C.

And this makes sense to me, since FIPPA is stateless and all needed information 
is included in the URL to perform the actions like Login, Logout, Reason Codes, 
Ready, Not Ready, etc.   The actual ringing of the phone and answering etc., 
are just phone functions, which we know works over MRA.  That's kind of the 
point.  ;)

What I am not sure of is whether the FIPPA push to phone works, if you're even 
using that; wherein, upon a new call, UCCX attempts to push content to the 
Agent's phone using the Phone API, but I would think, though I cannot confirm, 
that this would fail, since the phone IP is actually like 192.168.1.1 or 
something, and UCCX wont know to contact Expressway-C about it, nor would 
Expressway-C forward the API call on to the phone, etc.

Finesse itself, the web app on port 8445, would not be available over MRA, as 
the document states, and would require a VPN or other networking solution to be 
available to the Agent.  Brian Meade 
commented on a 
previous conversation to a similar topic that a reverse proxy would help in 
this scenario.

On Thu, Jan 23, 2020 at 2:07 PM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Can anyone say whether or not a CCX phone agent (or finesse agent in the 
future) is supported over MRA?

The MRA guides say:

The Expressway does not support some Cisco Unified Contact Center Express 
(Unified CCX) features for contact center agents or other users who connect 
over MRA. Jabber for Mac and Jabber for Windows cannot provide deskphone 
control over MRA, because the Expressway pair does not traverse the CTI-QBE 
protocol. However, if these Jabber applications, or other CTI applications, can 
connect to Unified CM CTIManager (directly or through the VPN) they can provide 
deskphone control of MRA-connected clients.

We're looking at a simple phone agent setup, no desktop agent/control, etc.

Thoughts?
___
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

Re: [cisco-voip] CCX phone agent over MRA?

[Lelio Fulgenzi]

FIPPA in the future, but for now, just regular IPPA, since we’re on 10.x and 
we’re still using that.

Would be interested in hearing about that old school tech. 

We’re looking at what options we have for any easy go-bag for CCX agent to grab 
and work from off-site.

From: Anthony Holloway 
Sent: Thursday, January 23, 2020 3:30 PM
To: Lelio Fulgenzi 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] CCX phone agent over MRA?

Are you talking Finesse IP Phone Agent (FIPPA)?

If so, the below enhancement defect requesting that these types of details be 
documented (I mean should we even have to request that?) states that they 
tested FIPPA via MRA and it worked.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi51697

Just know that you'll have to add your UCCX server addresses to the HTTP Allow 
list on Expressway-C.

And this makes sense to me, since FIPPA is stateless and all needed information 
is included in the URL to perform the actions like Login, Logout, Reason Codes, 
Ready, Not Ready, etc.   The actual ringing of the phone and answering etc., 
are just phone functions, which we know works over MRA.  That's kind of the 
point.  ;)

What I am not sure of is whether the FIPPA push to phone works, if you're even 
using that; wherein, upon a new call, UCCX attempts to push content to the 
Agent's phone using the Phone API, but I would think, though I cannot confirm, 
that this would fail, since the phone IP is actually like 192.168.1.1 or 
something, and UCCX wont know to contact Expressway-C about it, nor would 
Expressway-C forward the API call on to the phone, etc.

Finesse itself, the web app on port 8445, would not be available over MRA, as 
the document states, and would require a VPN or other networking solution to be 
available to the Agent.  Brian Meade 
commented on a 
previous conversation to a similar topic that a reverse proxy would help in 
this scenario.

On Thu, Jan 23, 2020 at 2:07 PM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Can anyone say whether or not a CCX phone agent (or finesse agent in the 
future) is supported over MRA?

The MRA guides say:

The Expressway does not support some Cisco Unified Contact Center Express 
(Unified CCX) features for contact center agents or other users who connect 
over MRA. Jabber for Mac and Jabber for Windows cannot provide deskphone 
control over MRA, because the Expressway pair does not traverse the CTI-QBE 
protocol. However, if these Jabber applications, or other CTI applications, can 
connect to Unified CM CTIManager (directly or through the VPN) they can provide 
deskphone control of MRA-connected clients.

We're looking at a simple phone agent setup, no desktop agent/control, etc.

Thoughts?
___
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

Re: [cisco-voip] CCX phone agent over MRA?

[Pawlowski, Adam]

From experience with xml services, if uses a post to push the phone to open XML 
objects, then, no that won’t work. You’ll either see it as the Expressway C’s 
IP like you said which doesn’t work as it can’t forward anything back, or if 
you chase the X-Forwarded-For header you get the device’s IP which also 
probably doesn’t help you, unless you’re using the Expressway to secure 
telephony or proxy it on-net somewhere you have direct access to.



From: cisco-voip  On Behalf Of Anthony 
Holloway
Sent: Thursday, January 23, 2020 3:30 PM
To: Lelio Fulgenzi 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] CCX phone agent over MRA?

Are you talking Finesse IP Phone Agent (FIPPA)?

If so, the below enhancement defect requesting that these types of details be 
documented (I mean should we even have to request that?) states that they 
tested FIPPA via MRA and it worked.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi51697

Just know that you'll have to add your UCCX server addresses to the HTTP Allow 
list on Expressway-C.

And this makes sense to me, since FIPPA is stateless and all needed information 
is included in the URL to perform the actions like Login, Logout, Reason Codes, 
Ready, Not Ready, etc.   The actual ringing of the phone and answering etc., 
are just phone functions, which we know works over MRA.  That's kind of the 
point.  ;)

What I am not sure of is whether the FIPPA push to phone works, if you're even 
using that; wherein, upon a new call, UCCX attempts to push content to the 
Agent's phone using the Phone API, but I would think, though I cannot confirm, 
that this would fail, since the phone IP is actually like 192.168.1.1 or 
something, and UCCX wont know to contact Expressway-C about it, nor would 
Expressway-C forward the API call on to the phone, etc.

Finesse itself, the web app on port 8445, would not be available over MRA, as 
the document states, and would require a VPN or other networking solution to be 
available to the Agent.  Brian Meade 
commented on a 
previous conversation to a similar topic that a reverse proxy would help in 
this scenario.

On Thu, Jan 23, 2020 at 2:07 PM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Can anyone say whether or not a CCX phone agent (or finesse agent in the 
future) is supported over MRA?

The MRA guides say:

The Expressway does not support some Cisco Unified Contact Center Express 
(Unified CCX) features for contact center agents or other users who connect 
over MRA. Jabber for Mac and Jabber for Windows cannot provide deskphone 
control over MRA, because the Expressway pair does not traverse the CTI-QBE 
protocol. However, if these Jabber applications, or other CTI applications, can 
connect to Unified CM CTIManager (directly or through the VPN) they can provide 
deskphone control of MRA-connected clients.

We're looking at a simple phone agent setup, no desktop agent/control, etc.

Thoughts?
___
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

Re: [cisco-voip] CCX phone agent over MRA?

[Anthony Holloway]

Are you talking Finesse IP Phone Agent (FIPPA)?

If so, the below enhancement defect requesting that these types of details
be documented (I mean should we even have to request that?) states that
they tested FIPPA via MRA and it worked.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi51697

Just know that you'll have to add your UCCX server addresses to the HTTP
Allow list on Expressway-C.

And this makes sense to me, since FIPPA is stateless and all needed
information is included in the URL to perform the actions like Login,
Logout, Reason Codes, Ready, Not Ready, etc.   The actual ringing of the
phone and answering etc., are just phone functions, which we know works
over MRA.  That's kind of the point.  ;)

What I am not sure of is whether the FIPPA push to phone works, if you're
even using that; wherein, upon a new call, UCCX attempts to push content to
the Agent's phone using the Phone API, but I would think, though I cannot
confirm, that this would fail, since the phone IP is actually like
192.168.1.1 or something, and UCCX wont know to contact Expressway-C about
it, nor would Expressway-C forward the API call on to the phone, etc.

Finesse itself, the web app on port 8445, would not be available over MRA,
as the document states, and would require a VPN or other networking
solution to be available to the Agent.  Brian Meade commented
 on a previous
conversation to a similar topic that a reverse proxy would help in this
scenario.

On Thu, Jan 23, 2020 at 2:07 PM Lelio Fulgenzi  wrote:

>
> Can anyone say whether or not a CCX phone agent (or finesse agent in the
> future) is supported over MRA?
>
> The MRA guides say:
>
> The Expressway does not support some Cisco Unified Contact Center Express
> (Unified CCX) features for contact center agents or other users who connect
> over MRA. Jabber for Mac and Jabber for Windows cannot provide deskphone
> control over MRA, because the Expressway pair does not traverse the CTI-QBE
> protocol. However, if these Jabber applications, or other CTI applications,
> can connect to Unified CM CTIManager (directly or through the VPN) they can
> provide deskphone control of MRA-connected clients.
>
> We're looking at a simple phone agent setup, no desktop agent/control, etc.
>
> Thoughts?
> ___
> 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

[cisco-voip] CCX phone agent over MRA?

[Lelio Fulgenzi]

Can anyone say whether or not a CCX phone agent (or finesse agent in the 
future) is supported over MRA?

The MRA guides say:

The Expressway does not support some Cisco Unified Contact Center Express 
(Unified CCX) features for contact center agents or other users who connect 
over MRA. Jabber for Mac and Jabber for Windows cannot provide deskphone 
control over MRA, because the Expressway pair does not traverse the CTI-QBE 
protocol. However, if these Jabber applications, or other CTI applications, can 
connect to Unified CM CTIManager (directly or through the VPN) they can provide 
deskphone control of MRA-connected clients.

We're looking at a simple phone agent setup, no desktop agent/control, etc.

Thoughts?
<>___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Lelio Fulgenzi]

I think we might add this to the "peripherals" section of our service pages.

"Consider whether your headset has a pickup button. If it does, you (and anyone 
else who picks it up) will be able to answer calls without unlocking your 
screen."

-Original Message-
From: Pawlowski, Adam  
Sent: Thursday, January 23, 2020 10:18 AM
To: 'Bill Talley' ; Lelio Fulgenzi 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: RE: [cisco-voip] Jabber and locked screens - it works! but should it?

The biggest issue with this that came up here during piloting with screen lock, 
is that a lock policy went into place during the pilot rollout. We'd been 
migrating test users with Plantronics headsets with the DA70, that has no 
buttons, and they found if they'd not been jiggling the computer mouse after a 
few minutes they can't answer their phone without logging back into the 
workstation. 

The DA80 has the buttons so you can answer it, but you can't see who's calling 
anymore. 

I'd always hoped that there'd be a tie in to a lock screen widget so you could 
see something but, alas. There's not as much of a coordination between the need 
for lock policy, user training, system idle, smartcard/key/windows hello etc 
and it represents a change in workflow that is still not accepted by most users 
when it comes to "telephone" because they've been able to pick up and talk into 
the blower for years without any extra steps.

Adam

> -Original Message-
> From: cisco-voip  On Behalf Of 
> Bill Talley
> Sent: Thursday, January 23, 2020 10:12 AM
> To: Lelio Fulgenzi 
> Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net)  v...@puck.nether.net>
> Subject: Re: [cisco-voip] Jabber and locked screens - it works! but should it?
> 
> Might be handy for calling emergency services or security, but other 
> than that, it’s probably not something I would want the cleaning crew 
> or mischievous co- workers being able to do.
> 
> Sent from an iPhone mobile device with very tiny touchscreen input keys.
> Please excude my typtos.
> 
> > On Jan 23, 2020, at 8:40 AM, Lelio Fulgenzi  wrote:
> >
> > 
> > OK. What do people think about Jabber working while a screen is 
> > locked? By
> this, I mean that if your headset has a "pickup" button, you can answer the 
> call.
> Now, I know the first thing you will say is, "what's different from 
> the phone being picked up", and really, there isn't, but there is. I 
> think people will assume that if my computer is locked, it should not 
> be allowed to work. OR at a minimum, allow it to be a configurable option.
> >
> > Then there's the possibility of using a handset that is Jabber 
> > compatible which
> could be used to dial numbers while the computer is locked.
> >
> > Thoughts?
> > 
> > ___
> > 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
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Pawlowski, Adam]

The biggest issue with this that came up here during piloting with screen lock, 
is that a lock policy went into place during the pilot rollout. We'd been 
migrating test users with Plantronics headsets with the DA70, that has no 
buttons, and they found if they'd not been jiggling the computer mouse after a 
few minutes they can't answer their phone without logging back into the 
workstation. 

The DA80 has the buttons so you can answer it, but you can't see who's calling 
anymore. 

I'd always hoped that there'd be a tie in to a lock screen widget so you could 
see something but, alas. There's not as much of a coordination between the need 
for lock policy, user training, system idle, smartcard/key/windows hello etc 
and it represents a change in workflow that is still not accepted by most users 
when it comes to "telephone" because they've been able to pick up and talk into 
the blower for years without any extra steps.

Adam

> -Original Message-
> From: cisco-voip  On Behalf Of Bill
> Talley
> Sent: Thursday, January 23, 2020 10:12 AM
> To: Lelio Fulgenzi 
> Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net)  v...@puck.nether.net>
> Subject: Re: [cisco-voip] Jabber and locked screens - it works! but should it?
> 
> Might be handy for calling emergency services or security, but other than 
> that,
> it’s probably not something I would want the cleaning crew or mischievous co-
> workers being able to do.
> 
> Sent from an iPhone mobile device with very tiny touchscreen input keys.
> Please excude my typtos.
> 
> > On Jan 23, 2020, at 8:40 AM, Lelio Fulgenzi  wrote:
> >
> > 
> > OK. What do people think about Jabber working while a screen is locked? By
> this, I mean that if your headset has a "pickup" button, you can answer the 
> call.
> Now, I know the first thing you will say is, "what's different from the phone
> being picked up", and really, there isn't, but there is. I think people will 
> assume
> that if my computer is locked, it should not be allowed to work. OR at a
> minimum, allow it to be a configurable option.
> >
> > Then there's the possibility of using a handset that is Jabber compatible 
> > which
> could be used to dial numbers while the computer is locked.
> >
> > Thoughts?
> > 
> > ___
> > 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
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Bill Talley]

Might be handy for calling emergency services or security, but other than that, 
it’s probably not something I would want the cleaning crew or mischievous 
co-workers being able to do. 

Sent from an iPhone mobile device with very tiny touchscreen input keys.  
Please excude my typtos.

> On Jan 23, 2020, at 8:40 AM, Lelio Fulgenzi  wrote:
> 
> 
> OK. What do people think about Jabber working while a screen is locked? By 
> this, I mean that if your headset has a "pickup" button, you can answer the 
> call. Now, I know the first thing you will say is, "what's different from the 
> phone being picked up", and really, there isn't, but there is. I think people 
> will assume that if my computer is locked, it should not be allowed to work. 
> OR at a minimum, allow it to be a configurable option.
> 
> Then there's the possibility of using a handset that is Jabber compatible 
> which could be used to dial numbers while the computer is locked.
> 
> Thoughts?
> 
> ___
> 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

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Anthony Holloway]

How about just give us the option to control the behavior?  You'll always
find someone playing devil's advocate and explaining a scenario to you in
which their opinion makes sense.  Might as well let both sides of the isle
have their cake and eat it too.

On Thu, Jan 23, 2020 at 8:39 AM Lelio Fulgenzi  wrote:

>
> OK. What do people think about Jabber working while a screen is locked? By
> this, I mean that if your headset has a "pickup" button, you can answer the
> call. Now, I know the first thing you will say is, "what's different from
> the phone being picked up", and really, there isn't, but there is. I think
> people will assume that if my computer is locked, it should not be allowed
> to work. OR at a minimum, allow it to be a configurable option.
>
> Then there's the possibility of using a handset that is Jabber compatible
> which could be used to dial numbers while the computer is locked.
>
> Thoughts?
> ___
> 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

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Lelio Fulgenzi]

AHA! They _did_ think about your last point! At least for Windows. Sort of.


https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/12_8/cjab_b_parameter-reference-guide-jabber-128.pdf

[cid:image001.png@01D5D1D5.9000FA00]

From: Mark H. Turpin 
Sent: Thursday, January 23, 2020 10:10 AM
To: Lelio Fulgenzi ; voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
Subject: Re: [cisco-voip] Jabber and locked screens - it works! but should it?

Lelio,

Great thinking, I had not considered this. Initial thoughts are I would not 
want accessories like a headset to be able to answer a call on my locked 
computer. But on the flip side, I also have a hard phone on my desk, and 
someone could pick up the handset with ease.

If they were to lock down Jabber, I would want an established call to remain 
operable with a locked screen, of course.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Thursday, January 23, 2020 8:39 AM
To: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Jabber and locked screens - it works! but should it?

*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***



OK. What do people think about Jabber working while a screen is locked? By 
this, I mean that if your headset has a "pickup" button, you can answer the 
call. Now, I know the first thing you will say is, "what's different from the 
phone being picked up", and really, there isn't, but there is. I think people 
will assume that if my computer is locked, it should not be allowed to work. OR 
at a minimum, allow it to be a configurable option.



Then there's the possibility of using a handset that is Jabber compatible which 
could be used to dial numbers while the computer is locked.



Thoughts?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber and locked screens - it works! but should it?

[Mark H. Turpin]

Lelio,

Great thinking, I had not considered this. Initial thoughts are I would not 
want accessories like a headset to be able to answer a call on my locked 
computer. But on the flip side, I also have a hard phone on my desk, and 
someone could pick up the handset with ease.

If they were to lock down Jabber, I would want an established call to remain 
operable with a locked screen, of course.


From: cisco-voip  on behalf of Lelio 
Fulgenzi 
Sent: Thursday, January 23, 2020 8:39 AM
To: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: [cisco-voip] Jabber and locked screens - it works! but should it?

*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***




OK. What do people think about Jabber working while a screen is locked? By 
this, I mean that if your headset has a “pickup” button, you can answer the 
call. Now, I know the first thing you will say is, “what’s different from the 
phone being picked up”, and really, there isn’t, but there is. I think people 
will assume that if my computer is locked, it should not be allowed to work. OR 
at a minimum, allow it to be a configurable option.



Then there’s the possibility of using a handset that is Jabber compatible which 
could be used to dial numbers while the computer is locked.



Thoughts?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Jabber and locked screens - it works! but should it?

[Lelio Fulgenzi]

OK. What do people think about Jabber working while a screen is locked? By 
this, I mean that if your headset has a "pickup" button, you can answer the 
call. Now, I know the first thing you will say is, "what's different from the 
phone being picked up", and really, there isn't, but there is. I think people 
will assume that if my computer is locked, it should not be allowed to work. OR 
at a minimum, allow it to be a configurable option.

Then there's the possibility of using a handset that is Jabber compatible which 
could be used to dial numbers while the computer is locked.

Thoughts?
<>___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip