[cisco-voip] are we still using custom jabber xml files in CUCM v11.5 and JAbber v12?

Thu Jun 14 17:42:12 EDT 2018

I guess any solution is going to be good for some, and bad for others.  For
example, making a user choose "Cloud Login" is not good in my opinion,
because I believe users will not understand that language.

This reminds me of installing QM and during the setup it asks you to enter
the CTI Server IP Address.  What server is that?  CUCM obviously, right?
Nope, it's the QM server.  So yeah, language can be tricky.

On Thu, Jun 14, 2018 at 5:22 PM Ryan Huff <ryanhuff at outlook.com> wrote:

> The spirit of Jabber login‘s as I understand it, is for the client to be
> able to login in one shot with out the user having to figure out what side
> of the network they’re on, what type of service to use ... etc.
>
> And that mostly works except for when it comes to the Webex connect
> authentication mechanism. I would not be having this dialogue right now, if
> the authentication attempt would simply move on to SRV record checking if
> it fails the Webexconnect login, but it doesn’t. If it finds that domain
> configured with Webexconnect, and it fails authentication, you’re dead in
> the water.
>
> Sent from my iPhone
>
> On Jun 14, 2018, at 17:18, Ryan Huff <ryanhuff at outlook.com> wrote:
>
> Not at all. I’m saying the control needs to be more simple and friendly to
> use.
>
> Why can’t there be a control right on the front of the login screen
> underneath the advanced settings link, “Cloud Login Yes | No”?
>
> Sent from my iPhone
>
> On Jun 14, 2018, at 17:13, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
> Are you arguing that the Jabber client shouldn't check for cloud services
> (webex messaenger) at all?
>
> What is your distinction between a technique which solves a problem, and a
> solution?
>
> On Thu, Jun 14, 2018 at 5:04 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> While I will agree that each “solution” can be made to work with a little
>> creativity, my supposition is more basic. Why should I have to?
>>
>> All of these techniques are not solutions, they are ways to navigate the
>> boat around an anchor that shouldn’t even be there.
>>
>> Sent from my iPhone
>>
>> On Jun 14, 2018, at 16:20, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>> *RE: Re-installing the client*
>> How did you get the client on their in the first place?  How do you
>> handle upgrades?  If either of these methods used the MSI, then using
>> the CLEAR=1 switch shouldn't be a big deal.
>>
>> *RE: Funky URLs*
>> End Users are happy to click on URLs.  In fact, it happens all the time
>> when you sign up for new services (to activate new accounts), or when you
>> request password resets.  And who's to say it has to look funky?  Just use
>> a click here style link in the email.
>>
>> *RE: Calling Webex Support*
>> Funny enough, in the Cisco Live US 2018 Troubleshooting Jabber like a TAC
>> Engineer session, the TAC Engineer giving the preso (Amazing guy!) said
>> something to the effect of: TAC will work with the Webex team to help you
>> get that corrected.  Assuming of course it needs a correction, and you're
>> not trying to run both services on the same domain.  I have not verified
>> the validity of this statement however.
>>
>> Now, I agree that it presents a challenge, and so I'm not denying that.
>>
>> On Thu, Jun 14, 2018 at 3:52 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>>> Sorry to Hijack this but ......
>>>
>>> I’d settle for not having a forced Webexconnect authorization attempt
>>> without a good solution to turn it off.
>>>
>>> If you think the command line installer switches to exclude a WebEx
>>> service discovery is an acceptable solution, I’d argue that you’re wrong.
>>> What if I want to go cloud someday? Just reinstall all the clients (since
>>> this method modified the bootstrap)?
>>>
>>> If you think the mobile provisioning URL is a solution, it’s not. It’s a
>>> horrible solution. Convince my users to click on a funky looking url on
>>> their devices when I spend my existence espousing to users, not to click on
>>> funny looking links?
>>>
>>> If you would think calling WebEx support to turn it off is acceptable
>>> ... please, by all means, try it and let me know your thoughts.
>>>
>>> I’ve been after this feature for awhile now, just wrote a new idea
>>> request too ...
>>>
>>> https://communities.cisco.com/ideas/2827
>>>
>>> Sent from my iPhone
>>>
>>> On Jun 14, 2018, at 15:30, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>>>
>>> Well, that’s promising!
>>>
>>>
>>>
>>> I hope whatever comes along will work with v11.5su4. I mean, if it
>>> requires and additional suX, I can live with that, too.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---
>>>
>>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>>
>>> Computing and Communications Services | University of Guelph
>>>
>>> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
>>> N1G 2W1
>>>
>>> 519-824-4120 Ext. 56354 <(519)%20824-4120> | lelio at uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>>
>>>
>>>
>>> <image001.png>
>>>
>>>
>>>
>>> *From:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
>>> *Sent:* Thursday, June 14, 2018 3:12 PM
>>> *To:* Lelio Fulgenzi <lelio at uoguelph.ca>; voyp list, cisco-voip (
>>> cisco-voip at puck.nether.net) <cisco-voip at puck.nether.net>
>>> *Subject:* Re: [cisco-voip] are we still using custom jabber xml files
>>> in CUCM v11.5 and JAbber v12?
>>>
>>>
>>>
>>> Hmm the most Ill say is you may be happy this fall wink wink
>>>
>>>
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>
>>>
>>>
>>> *Matthew Loraditch***
>>>
>>> *Sr. Network Engineer*
>>>
>>> p: *443.541.1518* <443.541.1518>
>>>
>>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>>
>>>  |
>>>
>>> e: *MLoraditch at heliontechnologies.com*
>>> <MLoraditch at heliontechnologies.com>
>>>
>>> <image002.png>
>>>
>>> <image003.png> <https://facebook.com/heliontech>
>>>
>>> <image004.png> <https://twitter.com/heliontech>
>>>
>>> <image005.png> <https://www.linkedin.com/company/helion-technologies>
>>>
>>> <image006.png>
>>> <https://heliontechnologies.com/events/14th-annual-automotive-cx-summit-hosted-thought-leadership-summits/>
>>>
>>> ------------------------------
>>>
>>> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of
>>> Lelio Fulgenzi <lelio at uoguelph.ca>
>>> *Sent:* Thursday, June 14, 2018 2:59:19 PM
>>> *To:* voyp list, cisco-voip (cisco-voip at puck.nether.net)
>>> *Subject:* [cisco-voip] are we still using custom jabber xml files in
>>> CUCM v11.5 and JAbber v12?
>>>
>>>
>>>
>>>
>>>
>>> I realized that in CUCM v9 and Jabber v11, we needed to use custom
>>> jabber xml files if we wanted to turn on a feature for some people but not
>>> others. That gets tricky with multiple features and providing some but not
>>> others. Definitely not scalable.
>>>
>>>
>>>
>>> Has this changed in CUCM v11.5 and Jabber v12? I’m really hoping that
>>> the device configuration page will include most of the feature information.
>>>
>>>
>>>
>>> We see new COP files distributed for phones as they are improved upon,
>>> it would be neat to see the same thing for Jabber.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---
>>>
>>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>>
>>> Computing and Communications Services | University of Guelph
>>>
>>> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
>>> N1G 2W1
>>>
>>> 519-824-4120 Ext. 56354 <(519)%20824-4120> | lelio at uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>>
>>>
>>>
>>> <image001.png>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
> 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/20180614/e922c9f9/attachment.html>