[cisco-voip] Cisco Jabber and Calling Party Transformations

[Dana Tong]

Hi all,

Calling Party Transformation Patterns.
I have one in place to normalise inbound external callers. Jabber shows two 
numbers for an incoming call. The small one is normalised. The top number is 
not.
The connected party and recent calls list does not show the normalisation.

Any thoughts on how to best normalise the incoming calling party?

Cheers
Dana

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

Re: [cisco-voip] using the quick user/phone add - some artifacts

[Kent Roberts]

Opening a case… requesting things be fixed…….  Anyway where I was headed is…. 
I’ve been requesting a notepad section in CUCM since version 3.2, but I keep 
getting told thats not important…. (Almost made a couple of releases but got 
scrapped at last minute from what my AS team said)   I would think it would be 
a nice to have area, for tech notes, new DID imports, T1 or well now MPLS/Metro 
ethernet SIP circuit id’s and issues that might have been related.   Yah, it 
might be silly, but wouldn’t it be nice to have all that info in one spot with 
the rest of your CUCM configuration? I mean Lucent. (Pre-Avaya days) had 
that…. But I guess I am the only one seeing the good idea here…….  Anyone else? 
  I mean if this is a really silly idea, let me know, and I will drop it, but 
still think its a good idea…..  ?




> On Nov 27, 2019, at 1:25 PM, Pawlowski, Adam  wrote:
> 
> I haven't found a solution for that in the UCM  yet, I'm hoping it is fixed 
> better in 12.5 .
> 
> It may be one of those things that we have to get a case open for and then 
> get a defect going on, but, this takes up time.
> 
> The generic error is awful to deal with as well. & in the department name 
> breaking a template, something being too long that you've keyed in but no 
> explanation. I found the best one the other day so far. If you interact with 
> the dialog boxes that come up for a new phone/DN, and use the keyboard to 
> submit it, it double submits. The phone gives you an "Error" but then it is 
> added. When I did it with a DN, it actually inserted the DN twice (same 
> pattern and partition) so I have no idea what happened there.
> 
> Regarding the Universal templates, they have a lot of blank space and are 
> annoying to use that's for sure.  I've only seen it add the custom template 
> for Jabber for whatever reason but for the phones it will use the Universal 
> from the template.
> 
> More or less some day I'd like to get some better process going to review the 
> devices in the UCM and tweak and touch these things up. I have a lot of that 
> working in Ruby anyways for spot checks and work. Easy enough to grab the 
> device and make sure the displayname and asciidisplayname values are the same 
> and write it back. I have no time for cool things like this but the ultimate 
> goal is to allow the technicians to use the template without straying too far 
> or worrying about minutae, that we can pick up over night. We'd also look for 
> user name changes and re-write caller IDs and display names. This if course 
> means if the directory source says your name is Ronald then we are going to 
> put that there. Trivial enough with programming though to dip into another 
> field somewhere for a preferred name but I'm getting way off course now.
> 
> Adam
> 
> From: cisco-voip  > on behalf of Lelio Fulgenzi 
> mailto:le...@uoguelph.ca>>
> Sent: Monday, November 25, 2019 2:11 PM
> To: voyp list, cisco-voip (cisco-voip@puck.nether.net 
> )
> Subject: [cisco-voip] using the quick user/phone add - some artifacts
>  
>  
> So, tried out the quick user/phone add. I like it, although I had and am 
> still having some issues. (See notes below for first problem I had, with 
> solution)
>  
> The issue/concern I’m having now is that the process does the following:
>  
> Creates a custom phone button template with device name in the name of 
> template and uses that instead of the device type phone button template used 
> when creating manually.
> It uses the “Universal device template – model independent security profile” 
> instead of the device type security profile when creating manually.
> The process automatically enables mobility for the user and associates their 
> userID to the mobility ID.
> ASCII Display (Caller ID) is not filled in like the other field.
>  
> Has anyone found a way around any of these issues?
>  
> I checked the universal device template and there’s not options that I can 
> see to pick different phone button template.
>  
> I tried creating a copy of the default universal phone button template and 
> that is available in the drop down of the universal device template, but with 
> the same results.
>  
> This will mean a lot of going back to change things to match our current SOPs.
>  
>  
>  
>  
>  
>  
> Original Issue. Fixed.
>  
> For some historical archiving, I ran into the following problem: After 
> deleting a phone I created using the tool, I was not able to (re)create it 
> again. It gave me an ominous “error.add” pop-up.
>  
> Turns out, what I had done, was notice that the create process created a 
> custom phone button template, removed this and used the standard device phone 
> button template and then delete the phone after some testing. This left the 
> custom phone button template (with the userID in the name) in the system. 
> Subsequent (re)creates tried to create that same custom phone button template 
>

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Ryan Huff]

Honestly, and this is just my preference based on my years of experience in 
post-sales engineering and my desire to not be on support calls at 
stupid-thirty AM...

For a typical Cisco UC on UCS "business edition" hypervisor setup, I would 
change the hypervisor's vSwitch load balancing mechanism to "Route based on 
originating port ID" and put the vNIC failover to active/standby (assuming just 
the two typical vmnic0/1), then on the switch, unbundle the ports from the 
channel group and make the ports individual trunk / access ports (would depend 
on how you are handling 802.1Q tags).

Active/Standby is usually a sufficient NIC failover strategy for most 
customers, in most scenarios. Unless teamed NICs on the chassis are a material 
requirement in your scenario for some reason, I'd consider un-teaming the NICs 
and just let them be active/standby.

I've not experienced where the convergence time for failover between the NICs 
is so significant that it disrupts UC communications in a meaningful way, that 
can't also be tolerated and assessed to a brief "blip". Could it cause "in 
progress" calls to fail? Probably. Could it cause calls terminated on CUCM 
(MTP) to fail? Possibly. Could it cause disruptions to Finesse agents (if UCCX 
is in play)? Possibly. However, the convergence is very quick and is usually 
tolerated in the same way that a "brief moment of packet loss" is tolerated.

Again, evaluate whether nic teaming is a material requirement in your 
environment, but if it is not, I'd consider un-teaming and just going to 
active/standby.

Thanks,

Ryan


From: Jonathan Charles 
Sent: Wednesday, November 27, 2019 7:48 PM
To: Ryan Huff 
Cc: cisco-voip@puck.nether.net 
Subject: Re: [cisco-voip] Preservation Mode, long time for call setups...

Would you recommend changing it to Originating Port ID?


Jonathan

On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
I would expect the same behavior from PAgP with ESXi.

-Ryan

On Nov 27, 2019, at 19:19, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:


They are channel group ON... (so, no LACP) on the switch...


Jonathan

On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
AFAIK, VMware has always required a distributed vSwitch for LACP, but the 
earliest reference I can find tonight is 5.1, though I believe it’s referenced 
the same way in the documentation of every version since then.

https://kb.vmware.com/s/article/2034277

Sent from my iPhone

On Nov 27, 2019, at 19:11, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Route based on IP hash should be fine for 802.3ad, but technically, VMWare 
only supports it with a distributed vSwitch (would need an EA or Enterprise 
license for the hypervisor, not the “free” license) and not a standard vSwitch.
I’ve seen it work with a standard vSwitch, for long periods of time even, and 
then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), 
then all hell breaks loose and you can’t get teaming to work again.

If those c220s are business editions and/or have the “free” license (non 
enterprise), then that’s likely a problem. You’d likely see evidence of this in 
the switch syslog (Mac flaps, possibly err-disable... etc).

What is the reason for suspecting you need to change the NIC teaming to 
active/passive?

Phones going into SRST mode (may be displayed as preservation mode on phones) 
is an indication the phone’s IP lost network connectivity to all the call 
control servers listed in the phone’s configuration (xml) file.

The delayed call setup could be due to the call traversing an 
unexpected/unoptimized network path, due to disruption in it’s connection to 
its preferred call control server.

Thanks,

Ryan

On Nov 27, 2019, at 18:17, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:


Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected to 
the same 4-stack 3850 (port channel, mode on)

Customer is reporting Preservation Mode kicking in on the LAN and some calls 
taking a long time to setup.

Currently, VMware is set to Route based on IP Hash with PAgP channel groups.

I think we need to change it to  Route Based on Originating Virtual Port 
instead, but I cannot prove it before hand...

What could be causing the Preservation Mode on the LAN?


Jonathan


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Anthony Holloway]

Yeah, it's unfortunate that in the BE6K installation documentation it's
telling you to use LACP when BE's don't come with (and likely never use)
the higher license for ESXi.

I even opened a documentation defect to help correct the example given in
the install guide:

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

Install Guide:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/BE6000/InstallationGuide/12_5/be6k_b_installation-guide-M5-1251/be6k_b_installation-guide-1251_appendix_0110.html


As far as the load balancing goes, IP hash is supported on standard
vswitches however.  You do need to make sure your switch(es) are configured
the same way though.

A little nugget from vmware vpshere 6.5 docs:

"ESXi hosts support only 802.3ad link aggregation in Static mode . You can
only use a static Etherchannel with vSphere Standard Switches. LACP is not
supported. To use LACP, you must have a vSphere Distributed Switch 5.1 and
later or Cicso Nexus 1000V. If you enable IP hash load balancing without
802.3ad link aggregation and the reverse, you might experience networking
disruptions."

Source:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-523FDFBD-EAEC-44A5-9451-F63EB792F156.html



On Wed, Nov 27, 2019 at 6:57 PM Kent Roberts  wrote:

> Check Cisco’s docs..  Some of those modes are only supported/not supported
> on different setups, and configurations.   I haven’t looked lately, but
> last I knew the free version of VMware wasn’t supported.  (Maybe they have
> changed and I am out of date).
>
> However….
>
> Whenever you have issues, check the SRND and make sure your base design is
> supported.
>
> Good Luck!
>
>
> On Nov 27, 2019, at 5:48 PM, Jonathan Charles  wrote:
>
> Would you recommend changing it to Originating Port ID?
>
>
> Jonathan
>
> On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff  wrote:
>
>> I would expect the same behavior from PAgP with ESXi.
>>
>> -Ryan
>>
>> On Nov 27, 2019, at 19:19, Jonathan Charles  wrote:
>>
>> 
>> They are channel group ON... (so, no LACP) on the switch...
>>
>>
>> Jonathan
>>
>> On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff  wrote:
>>
>>> AFAIK, VMware has always required a distributed vSwitch for LACP, but
>>> the earliest reference I can find tonight is 5.1, though I believe it’s
>>> referenced the same way in the documentation of every version since then.
>>>
>>> https://kb.vmware.com/s/article/2034277
>>> 
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 27, 2019, at 19:11, Ryan Huff  wrote:
>>>
>>> Route based on IP hash should be fine for 802.3ad, but technically,
>>> VMWare only supports it with a distributed vSwitch (would need an EA or
>>> Enterprise license for the hypervisor, not the “free” license) and not a
>>> standard vSwitch.
>>> I’ve seen it work with a standard vSwitch, for long periods of time
>>> even, and then the CAM table on a switch gets rebuilt (switch reload, power
>>> loss ...etc), then all hell breaks loose and you can’t get teaming to work
>>> again.
>>>
>>> If those c220s are business editions and/or have the “free” license (non
>>> enterprise), then that’s likely a problem. You’d likely see evidence of
>>> this in the switch syslog (Mac flaps, possibly err-disable... etc).
>>>
>>> What is the reason for suspecting you need to change the NIC teaming to
>>> active/passive?
>>>
>>> Phones going into SRST mode (may be displayed as preservation mode on
>>> phones) is an indication the phone’s IP lost network connectivity to all
>>> the call control servers listed in the phone’s configuration (xml) file.
>>>
>>> The delayed call setup could be due to the call traversing an
>>> unexpected/unoptimized network path, due to disruption in it’s connection
>>> to its preferred call control server.
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>> On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:
>>>
>>>
>>> 
>>>
>>> Customer has a two C220-M4S's with CUCM 11.5... both C-series are
>>> connected to the same 4-stack 3850 (port channel, mode on)
>>>
>>>
>>> Customer is reporting Preservation Mode kicking in on the LAN and some
>>> calls taking a long time to setup.
>>>
>>>
>>> Currently, VMware is set to Route based on IP Hash with PAgP channel
>>> groups.
>>>
>>>
>>> I think we need to change it to  Route Based on Originating Virtual Port
>>> instead, but I cannot prove it before hand...
>>>
>>>
>>> What could be causing the Preservation Mode on the LAN?
>>>
>>>
>>>
>>> Jonathan
>>>
>>>
>>>
>>> ___
>>>
>>> cisco-voip mailing list
>>>
>>> cisco-voip@puck.nether.net
>>>
>>>
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Kent Roberts]

Check Cisco’s docs..  Some of those modes are only supported/not supported on 
different setups, and configurations.   I haven’t looked lately, but last I 
knew the free version of VMware wasn’t supported.  (Maybe they have changed and 
I am out of date). 

However….

Whenever you have issues, check the SRND and make sure your base design is 
supported.

Good Luck!


> On Nov 27, 2019, at 5:48 PM, Jonathan Charles  wrote:
> 
> Would you recommend changing it to Originating Port ID?
> 
> 
> Jonathan
> 
> On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff  > wrote:
> I would expect the same behavior from PAgP with ESXi.
> 
> -Ryan
> 
>> On Nov 27, 2019, at 19:19, Jonathan Charles > > wrote:
>> 
>> 
>> They are channel group ON... (so, no LACP) on the switch... 
>> 
>> 
>> Jonathan
>> 
>> On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff > > wrote:
>> AFAIK, VMware has always required a distributed vSwitch for LACP, but the 
>> earliest reference I can find tonight is 5.1, though I believe it’s 
>> referenced the same way in the documentation of every version since then.
>> 
>> https://kb.vmware.com/s/article/2034277 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Nov 27, 2019, at 19:11, Ryan Huff >> > wrote:
>>> 
>>> Route based on IP hash should be fine for 802.3ad, but technically, VMWare 
>>> only supports it with a distributed vSwitch (would need an EA or Enterprise 
>>> license for the hypervisor, not the “free” license) and not a standard 
>>> vSwitch.
>>> I’ve seen it work with a standard vSwitch, for long periods of time even, 
>>> and then the CAM table on a switch gets rebuilt (switch reload, power loss 
>>> ...etc), then all hell breaks loose and you can’t get teaming to work again.
>>> 
>>> If those c220s are business editions and/or have the “free” license (non 
>>> enterprise), then that’s likely a problem. You’d likely see evidence of 
>>> this in the switch syslog (Mac flaps, possibly err-disable... etc).
>>> 
>>> What is the reason for suspecting you need to change the NIC teaming to 
>>> active/passive?
>>> 
>>> Phones going into SRST mode (may be displayed as preservation mode on 
>>> phones) is an indication the phone’s IP lost network connectivity to all 
>>> the call control servers listed in the phone’s configuration (xml) file.
>>> 
>>> The delayed call setup could be due to the call traversing an 
>>> unexpected/unoptimized network path, due to disruption in it’s connection 
>>> to its preferred call control server.
>>> 
>>> Thanks,
>>> 
>>> Ryan
>>> 
 On Nov 27, 2019, at 18:17, Jonathan Charles >>> > wrote:
 
 
 Customer has a two C220-M4S's with CUCM 11.5... both C-series are 
 connected to the same 4-stack 3850 (port channel, mode on)
 
 Customer is reporting Preservation Mode kicking in on the LAN and some 
 calls taking a long time to setup.
 
 Currently, VMware is set to Route based on IP Hash with PAgP channel 
 groups.
 
 I think we need to change it to  Route Based on Originating Virtual Port 
 instead, but I cannot prove it before hand...
 
 What could be causing the Preservation Mode on the LAN?
 
 
 Jonathan
 
 
 ___
 cisco-voip mailing list
 cisco-voip@puck.nether.net 
 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
  
 
> ___
> 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] Preservation Mode, long time for call setups...

[Jonathan Charles]

Would you recommend changing it to Originating Port ID?


Jonathan

On Wed, Nov 27, 2019 at 6:25 PM Ryan Huff  wrote:

> I would expect the same behavior from PAgP with ESXi.
>
> -Ryan
>
> On Nov 27, 2019, at 19:19, Jonathan Charles  wrote:
>
> 
> They are channel group ON... (so, no LACP) on the switch...
>
>
> Jonathan
>
> On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff  wrote:
>
>> AFAIK, VMware has always required a distributed vSwitch for LACP, but the
>> earliest reference I can find tonight is 5.1, though I believe it’s
>> referenced the same way in the documentation of every version since then.
>>
>> https://kb.vmware.com/s/article/2034277
>> 
>>
>> Sent from my iPhone
>>
>> On Nov 27, 2019, at 19:11, Ryan Huff  wrote:
>>
>> Route based on IP hash should be fine for 802.3ad, but technically,
>> VMWare only supports it with a distributed vSwitch (would need an EA or
>> Enterprise license for the hypervisor, not the “free” license) and not a
>> standard vSwitch.
>> I’ve seen it work with a standard vSwitch, for long periods of time even,
>> and then the CAM table on a switch gets rebuilt (switch reload, power loss
>> ...etc), then all hell breaks loose and you can’t get teaming to work again.
>>
>> If those c220s are business editions and/or have the “free” license (non
>> enterprise), then that’s likely a problem. You’d likely see evidence of
>> this in the switch syslog (Mac flaps, possibly err-disable... etc).
>>
>> What is the reason for suspecting you need to change the NIC teaming to
>> active/passive?
>>
>> Phones going into SRST mode (may be displayed as preservation mode on
>> phones) is an indication the phone’s IP lost network connectivity to all
>> the call control servers listed in the phone’s configuration (xml) file.
>>
>> The delayed call setup could be due to the call traversing an
>> unexpected/unoptimized network path, due to disruption in it’s connection
>> to its preferred call control server.
>>
>> Thanks,
>>
>> Ryan
>>
>> On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:
>>
>>
>> 
>>
>> Customer has a two C220-M4S's with CUCM 11.5... both C-series are
>> connected to the same 4-stack 3850 (port channel, mode on)
>>
>>
>> Customer is reporting Preservation Mode kicking in on the LAN and some
>> calls taking a long time to setup.
>>
>>
>> Currently, VMware is set to Route based on IP Hash with PAgP channel
>> groups.
>>
>>
>> I think we need to change it to  Route Based on Originating Virtual Port
>> instead, but I cannot prove it before hand...
>>
>>
>> What could be causing the Preservation Mode on the LAN?
>>
>>
>>
>> Jonathan
>>
>>
>>
>> ___
>>
>> cisco-voip mailing list
>>
>> cisco-voip@puck.nether.net
>>
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
>> 
>>
>>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Ryan Huff]

I would expect the same behavior from PAgP with ESXi.

-Ryan

On Nov 27, 2019, at 19:19, Jonathan Charles  wrote:


They are channel group ON... (so, no LACP) on the switch...


Jonathan

On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
AFAIK, VMware has always required a distributed vSwitch for LACP, but the 
earliest reference I can find tonight is 5.1, though I believe it’s referenced 
the same way in the documentation of every version since then.

https://kb.vmware.com/s/article/2034277

Sent from my iPhone

On Nov 27, 2019, at 19:11, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Route based on IP hash should be fine for 802.3ad, but technically, VMWare 
only supports it with a distributed vSwitch (would need an EA or Enterprise 
license for the hypervisor, not the “free” license) and not a standard vSwitch.
I’ve seen it work with a standard vSwitch, for long periods of time even, and 
then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), 
then all hell breaks loose and you can’t get teaming to work again.

If those c220s are business editions and/or have the “free” license (non 
enterprise), then that’s likely a problem. You’d likely see evidence of this in 
the switch syslog (Mac flaps, possibly err-disable... etc).

What is the reason for suspecting you need to change the NIC teaming to 
active/passive?

Phones going into SRST mode (may be displayed as preservation mode on phones) 
is an indication the phone’s IP lost network connectivity to all the call 
control servers listed in the phone’s configuration (xml) file.

The delayed call setup could be due to the call traversing an 
unexpected/unoptimized network path, due to disruption in it’s connection to 
its preferred call control server.

Thanks,

Ryan

On Nov 27, 2019, at 18:17, Jonathan Charles 
mailto:jonv...@gmail.com>> wrote:


Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected to 
the same 4-stack 3850 (port channel, mode on)

Customer is reporting Preservation Mode kicking in on the LAN and some calls 
taking a long time to setup.

Currently, VMware is set to Route based on IP Hash with PAgP channel groups.

I think we need to change it to  Route Based on Originating Virtual Port 
instead, but I cannot prove it before hand...

What could be causing the Preservation Mode on the LAN?


Jonathan


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Ryan Huff]

Well, at the very least, I would say that’s an unsupported configuration (using 
LACP on ESXi with a standard switch); that alone should be enough justification 
to change that. As for “proof”, you’d see it in the switch’s syslog.

However, the matter at hand (preservation mode), is due to a loss of 
connectivity, which could absolutely be due to the unsupported vSwitch 
configuration.

-Ryan

On Nov 27, 2019, at 19:18, Jonathan Charles  wrote:


I remembered another UCS set to IP Hash and having all kinds of connectivity 
issues... this is a standard switch, not a distributed and just the basic 
license.

On Wed, Nov 27, 2019 at 6:11 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Route based on IP hash should be fine for 802.3ad, but technically, VMWare only 
supports it with a distributed vSwitch (would need an EA or Enterprise license 
for the hypervisor, not the “free” license) and not a standard vSwitch.
I’ve seen it work with a standard vSwitch, for long periods of time even, and 
then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), 
then all hell breaks loose and you can’t get teaming to work again.

If those c220s are business editions and/or have the “free” license (non 
enterprise), then that’s likely a problem. You’d likely see evidence of this in 
the switch syslog (Mac flaps, possibly err-disable... etc).

What is the reason for suspecting you need to change the NIC teaming to 
active/passive?

Phones going into SRST mode (may be displayed as preservation mode on phones) 
is an indication the phone’s IP lost network connectivity to all the call 
control servers listed in the phone’s configuration (xml) file.

The delayed call setup could be due to the call traversing an 
unexpected/unoptimized network path, due to disruption in it’s connection to 
its preferred call control server.

Thanks,

Ryan

> On Nov 27, 2019, at 18:17, Jonathan Charles 
> mailto:jonv...@gmail.com>> wrote:
>
> 
> Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected 
> to the same 4-stack 3850 (port channel, mode on)
>
> Customer is reporting Preservation Mode kicking in on the LAN and some calls 
> taking a long time to setup.
>
> Currently, VMware is set to Route based on IP Hash with PAgP channel groups.
>
> I think we need to change it to  Route Based on Originating Virtual Port 
> instead, but I cannot prove it before hand...
>
> What could be causing the Preservation Mode on the LAN?
>
>
> Jonathan
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Jonathan Charles]

They are channel group ON... (so, no LACP) on the switch...


Jonathan

On Wed, Nov 27, 2019 at 6:16 PM Ryan Huff  wrote:

> AFAIK, VMware has always required a distributed vSwitch for LACP, but the
> earliest reference I can find tonight is 5.1, though I believe it’s
> referenced the same way in the documentation of every version since then.
>
> https://kb.vmware.com/s/article/2034277
>
> Sent from my iPhone
>
> On Nov 27, 2019, at 19:11, Ryan Huff  wrote:
>
> Route based on IP hash should be fine for 802.3ad, but technically,
> VMWare only supports it with a distributed vSwitch (would need an EA or
> Enterprise license for the hypervisor, not the “free” license) and not a
> standard vSwitch.
> I’ve seen it work with a standard vSwitch, for long periods of time even,
> and then the CAM table on a switch gets rebuilt (switch reload, power loss
> ...etc), then all hell breaks loose and you can’t get teaming to work again.
>
> If those c220s are business editions and/or have the “free” license (non
> enterprise), then that’s likely a problem. You’d likely see evidence of
> this in the switch syslog (Mac flaps, possibly err-disable... etc).
>
> What is the reason for suspecting you need to change the NIC teaming to
> active/passive?
>
> Phones going into SRST mode (may be displayed as preservation mode on
> phones) is an indication the phone’s IP lost network connectivity to all
> the call control servers listed in the phone’s configuration (xml) file.
>
> The delayed call setup could be due to the call traversing an
> unexpected/unoptimized network path, due to disruption in it’s connection
> to its preferred call control server.
>
> Thanks,
>
> Ryan
>
> On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:
>
>
> 
>
> Customer has a two C220-M4S's with CUCM 11.5... both C-series are
> connected to the same 4-stack 3850 (port channel, mode on)
>
>
> Customer is reporting Preservation Mode kicking in on the LAN and some
> calls taking a long time to setup.
>
>
> Currently, VMware is set to Route based on IP Hash with PAgP channel
> groups.
>
>
> I think we need to change it to  Route Based on Originating Virtual Port
> instead, but I cannot prove it before hand...
>
>
> What could be causing the Preservation Mode on the LAN?
>
>
>
> Jonathan
>
>
>
> ___
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Jonathan Charles]

I remembered another UCS set to IP Hash and having all kinds of
connectivity issues... this is a standard switch, not a distributed and
just the basic license.

On Wed, Nov 27, 2019 at 6:11 PM Ryan Huff  wrote:

> Route based on IP hash should be fine for 802.3ad, but technically, VMWare
> only supports it with a distributed vSwitch (would need an EA or Enterprise
> license for the hypervisor, not the “free” license) and not a standard
> vSwitch.
> I’ve seen it work with a standard vSwitch, for long periods of time even,
> and then the CAM table on a switch gets rebuilt (switch reload, power loss
> ...etc), then all hell breaks loose and you can’t get teaming to work again.
>
> If those c220s are business editions and/or have the “free” license (non
> enterprise), then that’s likely a problem. You’d likely see evidence of
> this in the switch syslog (Mac flaps, possibly err-disable... etc).
>
> What is the reason for suspecting you need to change the NIC teaming to
> active/passive?
>
> Phones going into SRST mode (may be displayed as preservation mode on
> phones) is an indication the phone’s IP lost network connectivity to all
> the call control servers listed in the phone’s configuration (xml) file.
>
> The delayed call setup could be due to the call traversing an
> unexpected/unoptimized network path, due to disruption in it’s connection
> to its preferred call control server.
>
> Thanks,
>
> Ryan
>
> > On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:
> >
> > 
> > Customer has a two C220-M4S's with CUCM 11.5... both C-series are
> connected to the same 4-stack 3850 (port channel, mode on)
> >
> > Customer is reporting Preservation Mode kicking in on the LAN and some
> calls taking a long time to setup.
> >
> > Currently, VMware is set to Route based on IP Hash with PAgP channel
> groups.
> >
> > I think we need to change it to  Route Based on Originating Virtual Port
> instead, but I cannot prove it before hand...
> >
> > What could be causing the Preservation Mode on the LAN?
> >
> >
> > Jonathan
> >
> >
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Ryan Huff]

AFAIK, VMware has always required a distributed vSwitch for LACP, but the 
earliest reference I can find tonight is 5.1, though I believe it’s referenced 
the same way in the documentation of every version since then.

https://kb.vmware.com/s/article/2034277

Sent from my iPhone

On Nov 27, 2019, at 19:11, Ryan Huff  wrote:

Route based on IP hash should be fine for 802.3ad, but technically, VMWare 
only supports it with a distributed vSwitch (would need an EA or Enterprise 
license for the hypervisor, not the “free” license) and not a standard vSwitch.
I’ve seen it work with a standard vSwitch, for long periods of time even, and 
then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), 
then all hell breaks loose and you can’t get teaming to work again.

If those c220s are business editions and/or have the “free” license (non 
enterprise), then that’s likely a problem. You’d likely see evidence of this in 
the switch syslog (Mac flaps, possibly err-disable... etc).

What is the reason for suspecting you need to change the NIC teaming to 
active/passive?

Phones going into SRST mode (may be displayed as preservation mode on phones) 
is an indication the phone’s IP lost network connectivity to all the call 
control servers listed in the phone’s configuration (xml) file.

The delayed call setup could be due to the call traversing an 
unexpected/unoptimized network path, due to disruption in it’s connection to 
its preferred call control server.

Thanks,

Ryan

On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:


Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected to 
the same 4-stack 3850 (port channel, mode on)

Customer is reporting Preservation Mode kicking in on the LAN and some calls 
taking a long time to setup.

Currently, VMware is set to Route based on IP Hash with PAgP channel groups.

I think we need to change it to  Route Based on Originating Virtual Port 
instead, but I cannot prove it before hand...

What could be causing the Preservation Mode on the LAN?


Jonathan


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Preservation Mode, long time for call setups...

[Ryan Huff]

Route based on IP hash should be fine for 802.3ad, but technically, VMWare only 
supports it with a distributed vSwitch (would need an EA or Enterprise license 
for the hypervisor, not the “free” license) and not a standard vSwitch.
I’ve seen it work with a standard vSwitch, for long periods of time even, and 
then the CAM table on a switch gets rebuilt (switch reload, power loss ...etc), 
then all hell breaks loose and you can’t get teaming to work again.

If those c220s are business editions and/or have the “free” license (non 
enterprise), then that’s likely a problem. You’d likely see evidence of this in 
the switch syslog (Mac flaps, possibly err-disable... etc).

What is the reason for suspecting you need to change the NIC teaming to 
active/passive?

Phones going into SRST mode (may be displayed as preservation mode on phones) 
is an indication the phone’s IP lost network connectivity to all the call 
control servers listed in the phone’s configuration (xml) file.

The delayed call setup could be due to the call traversing an 
unexpected/unoptimized network path, due to disruption in it’s connection to 
its preferred call control server.

Thanks,

Ryan

> On Nov 27, 2019, at 18:17, Jonathan Charles  wrote:
> 
> 
> Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected 
> to the same 4-stack 3850 (port channel, mode on)
> 
> Customer is reporting Preservation Mode kicking in on the LAN and some calls 
> taking a long time to setup.
> 
> Currently, VMware is set to Route based on IP Hash with PAgP channel groups.
> 
> I think we need to change it to  Route Based on Originating Virtual Port 
> instead, but I cannot prove it before hand...
> 
> What could be causing the Preservation Mode on the LAN?
> 
> 
> Jonathan
> 
> 
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cb14bf9fd1c424ebc097e08d7738fe904%7C84df9e7fe9f640afb435%7C1%7C0%7C637104934237145806&sdata=HcJICAAFuKb4WDeyLDo7qgvHfV24V7ecL5VjbkegSvU%3D&reserved=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Preservation Mode, long time for call setups...

[Jonathan Charles]

Customer has a two C220-M4S's with CUCM 11.5... both C-series are connected
to the same 4-stack 3850 (port channel, mode on)

Customer is reporting Preservation Mode kicking in on the LAN and some
calls taking a long time to setup.

Currently, VMware is set to Route based on IP Hash with PAgP channel groups.

I think we need to change it to  Route Based on Originating Virtual Port
instead, but I cannot prove it before hand...

What could be causing the Preservation Mode on the LAN?


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

Re: [cisco-voip] using the quick user/phone add - some artifacts

[Pawlowski, Adam]

I haven't found a solution for that in the UCM  yet, I'm hoping it is fixed 
better in 12.5 .


It may be one of those things that we have to get a case open for and then get 
a defect going on, but, this takes up time.


The generic error is awful to deal with as well. & in the department name 
breaking a template, something being too long that you've keyed in but no 
explanation. I found the best one the other day so far. If you interact with 
the dialog boxes that come up for a new phone/DN, and use the keyboard to 
submit it, it double submits. The phone gives you an "Error" but then it is 
added. When I did it with a DN, it actually inserted the DN twice (same pattern 
and partition) so I have no idea what happened there.


Regarding the Universal templates, they have a lot of blank space and are 
annoying to use that's for sure.  I've only seen it add the custom template for 
Jabber for whatever reason but for the phones it will use the Universal from 
the template.


More or less some day I'd like to get some better process going to review the 
devices in the UCM and tweak and touch these things up. I have a lot of that 
working in Ruby anyways for spot checks and work. Easy enough to grab the 
device and make sure the displayname and asciidisplayname values are the same 
and write it back. I have no time for cool things like this but the ultimate 
goal is to allow the technicians to use the template without straying too far 
or worrying about minutae, that we can pick up over night. We'd also look for 
user name changes and re-write caller IDs and display names. This if course 
means if the directory source says your name is Ronald then we are going to put 
that there. Trivial enough with programming though to dip into another field 
somewhere for a preferred name but I'm getting way off course now.


Adam



From: cisco-voip  on behalf of Lelio 
Fulgenzi 
Sent: Monday, November 25, 2019 2:11 PM
To: voyp list, cisco-voip (cisco-voip@puck.nether.net)
Subject: [cisco-voip] using the quick user/phone add - some artifacts


So, tried out the quick user/phone add. I like it, although I had and am still 
having some issues. (See notes below for first problem I had, with solution)

The issue/concern I’m having now is that the process does the following:


  *   Creates a custom phone button template with device name in the name of 
template and uses that instead of the device type phone button template used 
when creating manually.
  *   It uses the “Universal device template – model independent security 
profile” instead of the device type security profile when creating manually.
  *   The process automatically enables mobility for the user and associates 
their userID to the mobility ID.
  *   ASCII Display (Caller ID) is not filled in like the other field.

Has anyone found a way around any of these issues?

I checked the universal device template and there’s not options that I can see 
to pick different phone button template.

I tried creating a copy of the default universal phone button template and that 
is available in the drop down of the universal device template, but with the 
same results.

This will mean a lot of going back to change things to match our current SOPs.






Original Issue. Fixed.

For some historical archiving, I ran into the following problem: After deleting 
a phone I created using the tool, I was not able to (re)create it again. It 
gave me an ominous “error.add” pop-up.

Turns out, what I had done, was notice that the create process created a custom 
phone button template, removed this and used the standard device phone button 
template and then delete the phone after some testing. This left the custom 
phone button template (with the userID in the name) in the system. Subsequent 
(re)creates tried to create that same custom phone button template and was 
failing. “error.add” was referring to the fact it couldn’t create the template 
since it already existed.

---
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 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

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

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

[Erick Bergquist]

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 
>  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  
>>> 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" 
>>> > >  
>>> > > 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 MRA
>>> > > > fails to second server CCM2 fine and the phone information 
>>> > > screen
>>> > > > shows CCM1 as Active Server and the Stand-by Server field is 
>>> > > empty.
>>> > > > The web page of phone shows all 3 servers still with CCM2 as 
>>> > > Active.
>>> > > > When we make CCM2 unreachable the phone just spins and never 
>>> > > goes to
>>> > > > the third server over MRA.  Phones on-premise use the third 
>>> > > server
>>> > > > fine.
>>> > > >
>>> > > > I can not find an