[cisco-voip] Cisco ISE 3.1 Patch 5 breaks Phone 802.1x

[Riley, Sean]

Just in case anyone else runs into this one, or can avoid it until they have a 
fix.

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


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

[cisco-voip] CUCM/IM/CUC - Change DNS IP

[Riley, Sean via cisco-voip]

CUCM/IM v 11.5.SU9
CUC - v 12.5 SU4

I need to update our DNS server ip's to have a different secondary address. The 
research I have done leads me to believe I need to restart the server after 
making this change.  This seems excessive, but in line with Cisco Collab OS.

Has anyone on similar versions gone through this process and if so can you 
share your experience.

Thanks.

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

Re: [cisco-voip] Unity Connection - External Calls cut at 49 seconds

[Riley, Sean via cisco-voip]

There is a very slight blip in the call during the failover, but the calls do 
not drop.  Works as designed.

From: Kent Roberts 
Sent: Friday, February 4, 2022 12:28 PM
To: Riley, Sean 
Subject: Re: [cisco-voip] Unity Connection - External Calls cut at 49 seconds


When the HA even happens do you loose calls?   I run a 1006 so calls are 
never dropped.  Just wondered if the HA for cube shares the call state info 
should a failover happen.
On 2/4/22 7:05 AM, Riley, Sean via cisco-voip wrote:
Update on this.  We have a CUBE HA Pair at one of our sites.  We had a fail 
over event last Friday and the now Active CUBE was missing a configuration, (ip 
rtcp report interval 6).  Once I added this to the Active CUBE, the issue 
seems to be resolved.

This configuration works along with the following gateway configurations, as 
most of you probably already know.

gateway
 media-inactivity-criteria all
timer receive-rtcp 10
timer receive-rtp 86400

Thanks.

From: cisco-voip 
<mailto:cisco-voip-boun...@puck.nether.net> 
On Behalf Of Riley, Sean via cisco-voip
Sent: Thursday, February 3, 2022 11:14 AM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] Unity Connection - External Calls cut at 49 seconds

Unity v 12.5 SU4 with no changes recently and 300 second max message length.

Voice gateways are CUBEs running isr4300-universalk9.16.09.08.SPA.bin with no 
changes recently.  2 separate sites having same issue.  Internal calls to 
voicemail are fine.

We just had this reported yesterday and I can recreate the issue easily.

I am hoping someone has run across this or can point me in the right direction.

Thanks.

Sean.



___

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto: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] Unity Connection - External Calls cut at 49 seconds

[Riley, Sean via cisco-voip]

Update on this.  We have a CUBE HA Pair at one of our sites.  We had a fail 
over event last Friday and the now Active CUBE was missing a configuration, (ip 
rtcp report interval 6).  Once I added this to the Active CUBE, the issue 
seems to be resolved.

This configuration works along with the following gateway configurations, as 
most of you probably already know.

gateway
 media-inactivity-criteria all
timer receive-rtcp 10
timer receive-rtp 86400

Thanks.

From: cisco-voip  On Behalf Of Riley, Sean 
via cisco-voip
Sent: Thursday, February 3, 2022 11:14 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Unity Connection - External Calls cut at 49 seconds

Unity v 12.5 SU4 with no changes recently and 300 second max message length.

Voice gateways are CUBEs running isr4300-universalk9.16.09.08.SPA.bin with no 
changes recently.  2 separate sites having same issue.  Internal calls to 
voicemail are fine.

We just had this reported yesterday and I can recreate the issue easily.

I am hoping someone has run across this or can point me in the right direction.

Thanks.

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

[cisco-voip] Unity Connection - External Calls cut at 49 seconds

[Riley, Sean via cisco-voip]

Unity v 12.5 SU4 with no changes recently and 300 second max message length.

Voice gateways are CUBEs running isr4300-universalk9.16.09.08.SPA.bin with no 
changes recently.  2 separate sites having same issue.  Internal calls to 
voicemail are fine.

We just had this reported yesterday and I can recreate the issue easily.

I am hoping someone has run across this or can point me in the right direction.

Thanks.

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

Re: [cisco-voip] [External] Re: Small business E911 solution

[Riley, Sean]

We have each floor or each single floor location on separate voice subnet and 
plan to assign a separate ELIN to each floor/location.  We are small enough 
that this is currently manageable, but would be much more difficult for a large 
campus environment.

From: Lelio Fulgenzi 
Sent: Monday, December 13, 2021 5:58 PM
To: Riley, Sean ; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] [External] Re: Small business E911 solution

Mobile access aside, how are you going to handle physical infrastructure? Right 
now, our switches have been deployed using “shortest path” methodology. This 
means, one switch stack could service one quadrant of a building and three 
separate floors. It would take years to document the ports. And they’d be out 
of date before you pushed the save button. Let’s not forget people can attach a 
100ft patch cord and wire the other side of the building that the port doc says 
it services.

I guess we could start with building based location, which is better than 
nothing.

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Riley, Sean
Sent: Monday, December 13, 2021 5:37 PM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

We are going down the same road to find a solution to fit our environment, 
which seems similar to the original post.  We have physical phones in the 
office, sometimes in multiple offices with same DN and a home phone using MRA 
with the same DN.  Some Jabber softphone usage mixed in there as well in a 
VMware VDI environment.

Redsky want’s a separate ELIN for each MRA phone and Intrado says they can use 
CER or their gateway to track the MRA phones.  The VDI support is something 
they say they are working on, but no support at this time.

Sounds like we need to stand up CER at least with Intrado or plan to burn quite 
a few DID’s for ELIN use.

I do wish there was a better solution, but I have not come across one yet.  I 
will keep an eye on this thread.

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Palmer, Brian via cisco-voip
Sent: Friday, December 10, 2021 12:30 PM
To: Adam Pawlowski mailto:aj...@buffalo.edu>>; Matthew Huff 
mailto:mh...@ox.com>>; Johnson, Tim 
mailto:johns...@cmich.edu>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

Intrado is the only one that I know of that has the ability to deal with just 
about every single solution.  The only one they can’t handle yet is the 
softphone within citrix which nobody else I know can deal with.  That solution 
comes in a few months.

The ERS service from Intrado is the cheaper of the two solutions.  There really 
isn’t anyway to accomplish what you want without .  The risk you have is 
that if it doesn’t route or is mis-routed you could possibly then have legal 
issues.

The biggest issues we had was softphones in virtual environment(citrix), 
non-did extensions, users that move around and need to dynamically change 
location on the fly etc.

Most of the vendors like redsky are just the front end as it seems like Intrado 
literally has a monopoly on the backend E911 service.




Brian Palmer
904-905-8263

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Adam Pawlowski
Sent: Thursday, December 9, 2021 4:23 PM
To: Matthew Huff mailto:mh...@ox.com>>; Johnson, Tim 
mailto:johns...@cmich.edu>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

If the devices are “remote” then I believe it is limited to the unique DID 
formed between the extension on the device and the e164mask with CER.  V911 
solutions all seem to use call routing and can’t differentiate which thing 
originated the call in any way other than the calling number.  That’s where I 
am stuck being MRA only with Jabber. We’re also looking at 9Line, as they offer 
V911 and a UCM-direct approach for locations, but I believe in both cases it 
will still require some sort of unique DN, it just offers perhaps a better 
experience than the off-premise portal in CER for the customer to update their 
location as appropriate.

Best,

Adam

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Matthew Huff
Sent: Thursday, December 9, 2021 2:25 PM
To: Johnson, Tim mailto:johns...@cmich.edu>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

We have a SIP pro

Re: [cisco-voip] [External] Re: Small business E911 solution

[Riley, Sean]

We are going down the same road to find a solution to fit our environment, 
which seems similar to the original post.  We have physical phones in the 
office, sometimes in multiple offices with same DN and a home phone using MRA 
with the same DN.  Some Jabber softphone usage mixed in there as well in a 
VMware VDI environment.

Redsky want’s a separate ELIN for each MRA phone and Intrado says they can use 
CER or their gateway to track the MRA phones.  The VDI support is something 
they say they are working on, but no support at this time.

Sounds like we need to stand up CER at least with Intrado or plan to burn quite 
a few DID’s for ELIN use.

I do wish there was a better solution, but I have not come across one yet.  I 
will keep an eye on this thread.

From: cisco-voip  On Behalf Of Palmer, 
Brian via cisco-voip
Sent: Friday, December 10, 2021 12:30 PM
To: Adam Pawlowski ; Matthew Huff ; Johnson, 
Tim 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

Intrado is the only one that I know of that has the ability to deal with just 
about every single solution.  The only one they can’t handle yet is the 
softphone within citrix which nobody else I know can deal with.  That solution 
comes in a few months.

The ERS service from Intrado is the cheaper of the two solutions.  There really 
isn’t anyway to accomplish what you want without .  The risk you have is 
that if it doesn’t route or is mis-routed you could possibly then have legal 
issues.

The biggest issues we had was softphones in virtual environment(citrix), 
non-did extensions, users that move around and need to dynamically change 
location on the fly etc.

Most of the vendors like redsky are just the front end as it seems like Intrado 
literally has a monopoly on the backend E911 service.




Brian Palmer
904-905-8263

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Adam Pawlowski
Sent: Thursday, December 9, 2021 4:23 PM
To: Matthew Huff mailto:mh...@ox.com>>; Johnson, Tim 
mailto:johns...@cmich.edu>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

If the devices are “remote” then I believe it is limited to the unique DID 
formed between the extension on the device and the e164mask with CER.  V911 
solutions all seem to use call routing and can’t differentiate which thing 
originated the call in any way other than the calling number.  That’s where I 
am stuck being MRA only with Jabber. We’re also looking at 9Line, as they offer 
V911 and a UCM-direct approach for locations, but I believe in both cases it 
will still require some sort of unique DN, it just offers perhaps a better 
experience than the off-premise portal in CER for the customer to update their 
location as appropriate.

Best,

Adam

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Matthew Huff
Sent: Thursday, December 9, 2021 2:25 PM
To: Johnson, Tim mailto:johns...@cmich.edu>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Re: Small business E911 solution

We have a SIP provider. The issue is that the user requires the same Prime DN 
no matter their location. We have a user, for example, at our NY office, he has 
a two different home offices in Massachusetts and one in Idaho. Our SIP 
provider in order to route E911 requires each phone to an unique DID, which our 
users will not accept.

What is the easiest solution with on-premise CUCM that allows me to satisfy 
E911 regulations, especially the ones that go into effect in January, without 
having to have everyone have an unique prime-dn at each location. Is Cisco 
Emergency Responder the only choice?

Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mh...@ox.com | 
www.ox.com
...

From: Johnson, Tim mailto:johns...@cmich.edu>>
Sent: Thursday, December 9, 2021 2:20 PM
To: Matthew Huff mailto:mh...@ox.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [External] Re: [cisco-voip] Small business E911 solution

Maybe Intrado? Not sure their minimum requirements but I know we started with 
them when they were West, with only a couple hundred DIDs.

On Dec 9, 2021 2:16 PM, Matthew Huff mailto:mh...@ox.com>> wrote:
No, hosted solution isn’t an option as we have a 

[cisco-voip] Jabber Persistent Chat - Migrate to MS SQL

[Riley, Sean]

We are currently running PostgreSQL for our on-prem Jabber persistent chat 
database.  We would like to migrate this to MS SQL, but there does not seem to 
be much documentation available to assist with this.  Cisco seems to leave it 
up to SQL admins to figure this out.  Since I am light on SQL admin experience, 
has anyone gone through this migration?  If so, would you have any helpful docs 
I could reference or care to share any insight?

CUCM/IM v 11.5 su9
Jabber v 12.9 and 14.x

Thanks.

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

Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

[Riley, Sean]

I received the same answer from tac as others.  They have a but ID, but the 
workaround to disable telemetry is incorrect as we have had this disabled in 
the xml for a couple of years now.  We will be upgrading with the install 
switch to disable webex going forward.  Hopefully this puts a stop to this cert 
warning.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvg82067

From support:
One of the workarounds that I mentioned was to disable the Webex service, do 
you think you can try that?

Uninstall Jabber, clear the cache and install it with the following command:
msiexec.exe CiscoJabberSetup.msi CLEAR=1 EXCLUDED_SERVICES=Webex



From: cisco-voip  On Behalf Of Riley, Sean
Sent: Tuesday, November 30, 2021 12:17 PM
To: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

We did not start to see the cert warnings until 11/15/21.  Not sure if that 
helps correlate with a certificate expiring, etc.

From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Monday, November 29, 2021 6:18 PM
To: gba...@commandsolutions.com.au<mailto:gba...@commandsolutions.com.au>
Cc: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>; 
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert


They better come up with a better workaround to re-installing all our clients.

If Jabber has a built in procedure, then they really need to make sure it works.

Why are we all of a sudden seeing these cert issues?

This downloading of fixes really needs to be curbed.
Sent from my iPhone

On Nov 29, 2021, at 4:53 PM, Gary_Bates_Command_Solutions 
mailto:gba...@commandsolutions.com.au>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Hi there

We experienced this issue with our on-prem Jabber updates,

Fix we applied was as follows:


  1.  Do a “clean install” of Jabber (must delete cache files and uninstall old 
version)
  2.  Wen installing new version,  use this installation file with the switch 
at the end  as below


msiexec.exe /i CiscoJabberSetup.msi CLEAR=1 EXCLUDED_SERVICES=WEBEX 
UPN_DISCOVERY_ENABLED=false

Our desktop team added a script to clear the cache folders on desktops with 
previous installations as follows:

## Deleting all “.\Cisco” folders found on local profiles
Write-Log "-> Deleting all `“.\Cisco`” folders found on local 
profiles"
$users = Get-ChildItem -Path "C:\Users"
$users | ForEach-Object {
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Local\Cisco"
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Roaming\Cisco"


  1.  In the service profile for Jabber, add the 
“ServiceDiscoveryExcludedServices --> WEBEX”

This will ensure once Jabber is installed and configured, it will no longer try 
to connect to WEBEX each time the user logins.


HTH

Gary

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Tuesday, 30 November 2021 8:24 AM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

I will likely be opening a case for this. We had a few. Our workstations are 
not configured to not get root very updates I’ve been told.

We’ve only had a few cases.

Not sure this hasn’t made it to an advisory or bug or something.

Sent from my iPhone


On Nov 29, 2021, at 1:04 PM, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Did anyone come up with a solution to this, other than to tell the users to 
Accept the Cert?

We are completely on prem with no webex services.  Clients are v 12.9.6.  I was 
able to reproduce the issue once using a test user account, but have not been 
able to reproduce since, even after a Jabber reset.  Most of my team is running 
Jabber v 14.x and we have not seen the cert warning.

Does a user declining the cert add it to the Untrusted Certificates store in 
Windows?  Maybe that takes priority over a cert in the trusted store?

I have done the following, but we still have sporadic reports of the 
certificate warning from Jabber:


  1.  Ensured the new IdenTrust Commercial Root CA 1 was in CUCM and services 
restarted on CUCM and IM
  2.  Added the HydrantID Server CA O1 to the computers tru

Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

[Riley, Sean]

We did not start to see the cert warnings until 11/15/21.  Not sure if that 
helps correlate with a certificate expiring, etc.

From: Lelio Fulgenzi 
Sent: Monday, November 29, 2021 6:18 PM
To: gba...@commandsolutions.com.au
Cc: Riley, Sean ; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert


They better come up with a better workaround to re-installing all our clients.

If Jabber has a built in procedure, then they really need to make sure it works.

Why are we all of a sudden seeing these cert issues?

This downloading of fixes really needs to be curbed.
Sent from my iPhone


On Nov 29, 2021, at 4:53 PM, Gary_Bates_Command_Solutions 
mailto:gba...@commandsolutions.com.au>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Hi there

We experienced this issue with our on-prem Jabber updates,

Fix we applied was as follows:


  1.  Do a “clean install” of Jabber (must delete cache files and uninstall old 
version)
  2.  Wen installing new version,  use this installation file with the switch 
at the end  as below


msiexec.exe /i CiscoJabberSetup.msi CLEAR=1 EXCLUDED_SERVICES=WEBEX 
UPN_DISCOVERY_ENABLED=false

Our desktop team added a script to clear the cache folders on desktops with 
previous installations as follows:

## Deleting all “.\Cisco” folders found on local profiles
Write-Log "-> Deleting all `“.\Cisco`” folders found on local 
profiles"
$users = Get-ChildItem -Path "C:\Users"
$users | ForEach-Object {
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Local\Cisco"
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Roaming\Cisco"


  1.  In the service profile for Jabber, add the 
“ServiceDiscoveryExcludedServices --> WEBEX”

This will ensure once Jabber is installed and configured, it will no longer try 
to connect to WEBEX each time the user logins.


HTH

Gary

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Tuesday, 30 November 2021 8:24 AM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

I will likely be opening a case for this. We had a few. Our workstations are 
not configured to not get root very updates I’ve been told.

We’ve only had a few cases.

Not sure this hasn’t made it to an advisory or bug or something.

Sent from my iPhone



On Nov 29, 2021, at 1:04 PM, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Did anyone come up with a solution to this, other than to tell the users to 
Accept the Cert?

We are completely on prem with no webex services.  Clients are v 12.9.6.  I was 
able to reproduce the issue once using a test user account, but have not been 
able to reproduce since, even after a Jabber reset.  Most of my team is running 
Jabber v 14.x and we have not seen the cert warning.

Does a user declining the cert add it to the Untrusted Certificates store in 
Windows?  Maybe that takes priority over a cert in the trusted store?

I have done the following, but we still have sporadic reports of the 
certificate warning from Jabber:


  1.  Ensured the new IdenTrust Commercial Root CA 1 was in CUCM and services 
restarted on CUCM and IM
  2.  Added the HydrantID Server CA O1 to the computers trusted store via GPO.

Thanks.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Friday, November 12, 2021 3:17 PM
To: Lelio Fulgenzi mailto:le...@uoguelph.ca>>; Gary Parker 
mailto:g.j.par...@lboro.ac.uk>>; Brian V 
mailto:bvanb...@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

Darn it. We've started seeing the alerts for some reason.

Can we just tell people to accept? Argh.


-Original Message-
From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Friday, November 12, 2021 8:45 AM
To: Gary Parker mailto:g.j.par...@lboro.ac.uk>>; Brian 
V mailto:bvanb...@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

(a) do this
(b) don't d

Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

[Riley, Sean]

I will open a TAC case as well.  Maybe enough of those will get us an answer 
that does not require reinstalling.  I do wish I could easily reproduce, but I 
am not able to at this time.

Sean.

From: Gary_Bates_Command_Solutions 
Sent: Monday, November 29, 2021 7:08 PM
To: 'Lelio Fulgenzi' 
Cc: Riley, Sean ; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

Hi Lelio

I was told by a Cisco rep its all to do with Cisco’s arrogant sales strategy, 
trying to get all on-prem users to switchover to either Hybrid Jabber / Hybrid 
Webex or full cloud connection with Webex.

Unfortunately, it wasn’t communicated honestly and up front, my customer is 
very annoyed with Cisco and is slowly migrating towards MS Teams calling

I don’t see any “fixes” now, only the way we could solve it is following the 
procedure below

Gary

From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Tuesday, 30 November 2021 10:18 AM
To: gba...@commandsolutions.com.au<mailto:gba...@commandsolutions.com.au>
Cc: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>; 
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert


They better come up with a better workaround to re-installing all our clients.

If Jabber has a built in procedure, then they really need to make sure it works.

Why are we all of a sudden seeing these cert issues?

This downloading of fixes really needs to be curbed.
Sent from my iPhone

On Nov 29, 2021, at 4:53 PM, Gary_Bates_Command_Solutions 
mailto:gba...@commandsolutions.com.au>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Hi there

We experienced this issue with our on-prem Jabber updates,

Fix we applied was as follows:


  1.  Do a “clean install” of Jabber (must delete cache files and uninstall old 
version)
  2.  Wen installing new version,  use this installation file with the switch 
at the end  as below


msiexec.exe /i CiscoJabberSetup.msi CLEAR=1 EXCLUDED_SERVICES=WEBEX 
UPN_DISCOVERY_ENABLED=false

Our desktop team added a script to clear the cache folders on desktops with 
previous installations as follows:

## Deleting all “.\Cisco” folders found on local profiles
Write-Log "-> Deleting all `“.\Cisco`” folders found on local 
profiles"
$users = Get-ChildItem -Path "C:\Users"
$users | ForEach-Object {
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Local\Cisco"
Remove-Folder -Path "C:\Users\$($_.Name)\AppData\Roaming\Cisco"


  1.  In the service profile for Jabber, add the 
“ServiceDiscoveryExcludedServices --> WEBEX”

This will ensure once Jabber is installed and configured, it will no longer try 
to connect to WEBEX each time the user logins.


HTH

Gary

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Tuesday, 30 November 2021 8:24 AM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

I will likely be opening a case for this. We had a few. Our workstations are 
not configured to not get root very updates I’ve been told.

We’ve only had a few cases.

Not sure this hasn’t made it to an advisory or bug or something.

Sent from my iPhone


On Nov 29, 2021, at 1:04 PM, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca<mailto:ith...@uoguelph.ca>

Did anyone come up with a solution to this, other than to tell the users to 
Accept the Cert?

We are completely on prem with no webex services.  Clients are v 12.9.6.  I was 
able to reproduce the issue once using a test user account, but have not been 
able to reproduce since, even after a Jabber reset.  Most of my team is running 
Jabber v 14.x and we have not seen the cert warning.

Does a user declining the cert add it to the Untrusted Certificates store in 
Windows?  Maybe that takes priority over a cert in the trusted store?

I have done the following, but we still have sporadic reports of the 
certificate warning from Jabber:


  1.  Ensured the new IdenTrust Commercial Root CA 1 was in CUCM and services 
restarted on CUCM and IM
  2.  Added the HydrantID Server CA O1 to the computers trusted store via GPO.

Thanks.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>

Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

[Riley, Sean]

Did anyone come up with a solution to this, other than to tell the users to 
Accept the Cert?

We are completely on prem with no webex services.  Clients are v 12.9.6.  I was 
able to reproduce the issue once using a test user account, but have not been 
able to reproduce since, even after a Jabber reset.  Most of my team is running 
Jabber v 14.x and we have not seen the cert warning.

Does a user declining the cert add it to the Untrusted Certificates store in 
Windows?  Maybe that takes priority over a cert in the trusted store?

I have done the following, but we still have sporadic reports of the 
certificate warning from Jabber:


1.   Ensured the new IdenTrust Commercial Root CA 1 was in CUCM and 
services restarted on CUCM and IM

2.   Added the HydrantID Server CA O1 to the computers trusted store via 
GPO.

Thanks.


From: cisco-voip  On Behalf Of Lelio 
Fulgenzi
Sent: Friday, November 12, 2021 3:17 PM
To: Lelio Fulgenzi ; Gary Parker ; 
Brian V 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

Darn it. We've started seeing the alerts for some reason.

Can we just tell people to accept? Argh.


-Original Message-
From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Friday, November 12, 2021 8:45 AM
To: Gary Parker mailto:g.j.par...@lboro.ac.uk>>; Brian 
V mailto:bvanb...@gmail.com>>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

(a) do this
(b) don't do this

Is my favourite part!

I remember when I first started, I had opened a case, then another, and got two 
very conflicting opinions from the TAC

(a) TAC suggests using the T train for voice gateways
(b) The TAC suggests staying away from T train for voice gateways

Or something like that.

When you're first starting out and have a crush on Cisco, it's very had to work 
through that.


-Original Message-
From: Gary Parker mailto:g.j.par...@lboro.ac.uk>>
Sent: Friday, November 12, 2021 5:24 AM
To: Brian V mailto:bvanb...@gmail.com>>
Cc: Lelio Fulgenzi mailto:le...@uoguelph.ca>>; NateCCIE 
mailto:natec...@gmail.com>>; Johnson, Tim 
mailto:johns...@cmich.edu>>; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] [External] Jabber Users Prompted To Accept Webex Cert

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca


Yeah, I had a suspicion at one point that this might be to do with the 
telemetry (which we’re sending), but the only reference I can find to the 
servers used for this is in the "Feature Configuration for Cisco Jabber 12.8” 
doc where it states that clients connect to "metrics-a.wbx2.com” (also 
mentioning that you must install a GoDaddy root cert).

We’ve been sending telemetry for some time and have not had this problem 
before, and the cert the client is erroring on is idbroker.webex.com (with the 
IdenTrust root).

Fwiw, metrics-a.wbx2.com is a cname for ha-a-main.wbx2.com, which in turn is a 
cname for achm-main-ha-a-nlb-1d0e22049c746ef1.elb.us-east-2.amazonaws.com

metrics-a.wbx2.com *does* have a GoDaddy root cert, and a wildcard server cert.

What a mess!

That bug also says:

"b) Disable the telemetry call to Webex in the jabber-config xml”

…but then goes on to say:

"This error/popup is not related to Telemetry. Even if you disable Telemetry on 
Jabber certificate pop up will continue to show.”

¯\_(ツ)_/¯

Gary

> On 11 Nov 2021, at 22:57, Brian V 
> mailto:bvanb...@gmail.com>> wrote:
>
> Part of the workaround referenced in the Bug doesn't make sense. They 
> reference adding some GoDaddy certs, but when you look at the URL they 
> reference (*.wbx2.com) that is signed by Hydrant not Go Daddy.

___
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

[cisco-voip] Jabber Windows - "how do you want to open this file" for every image

[Riley, Sean]

We are running Cisco Jabber v 12.9.6 and 14.0.1.  While this has been an issue 
for several prior versions, it has finally become annoying enough for me to see 
if others have this issue and if they have found a fix.

On some computers:

Every time you open a screenshot attachment from a Jabber chat (ad hoc or a 
room), you have to select the program you want to open the file with.  Even 
after selecting "Always use this app to open .png files", I am still prompted.

On some computers:

Screenshots open without the prompt to select the application.

The computers are running the same version of Jabber 12.9.6.  I have checked 
the default file types on the computers for png files and they are both set to 
the same application.


Windows 10 (all versions)

IM v11.5 s su 9 with persistent chat.


Thanks.

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

Re: [cisco-voip] Ported to SIP carrier - some calls still coming in old carrier

[Riley, Sean]

Loosing carrier made a change on their side (changed DID’s to ported out 
status) and so far no more calls hitting the old gateways.

Thanks again for your help.

Sean

From: cisco-voip  On Behalf Of Riley, Sean
Sent: Thursday, July 8, 2021 4:13 PM
To: NateCCIE ; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Ported to SIP carrier - some calls still coming in 
old carrier

Nate, thanks for the suggestion.  I will reach out to the old carrier.

From: NateCCIE mailto:natec...@gmail.com>>
Sent: Thursday, July 8, 2021 12:49 PM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>; 
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: RE: [cisco-voip] Ported to SIP carrier - some calls still coming in 
old carrier

A lot of the time the loosing carrier doesn’t remove internal translations, so 
other customers of the losing carrier still come into the old PRI.  You’ll need 
to ask them to clean it up, I don’t think I have been patient enough to see it 
be cleaned up by itself.

-Nate

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Riley, Sean
Sent: Thursday, July 8, 2021 10:34 AM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] Ported to SIP carrier - some calls still coming in old 
carrier

We ported about 700 DID’s yesterday, from our PRI carrier to a new SIP carrier. 
Everything is working great, except I still see some calls coming into the old 
H323 gateways connected to the old carrier.  If I make a test call from my cell 
phone to the called number seen on the old gateway, the call routes through our 
new SIP gateway as expected.  Observing over the past 2 days it does seem that 
some of the calls are from the same “calling ID” and number.

Could it just take time for the port to propagate to other carriers and this 
will eventually work itself out over the coming days?  Or could there be 
something else causing calls from specific callers to still route through our 
old PRI carrier?

Thanks for any advice or knowledge you can share on this.

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

Re: [cisco-voip] Ported to SIP carrier - some calls still coming in old carrier

[Riley, Sean]

Nate, thanks for the suggestion.  I will reach out to the old carrier.

From: NateCCIE 
Sent: Thursday, July 8, 2021 12:49 PM
To: Riley, Sean ; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Ported to SIP carrier - some calls still coming in 
old carrier

A lot of the time the loosing carrier doesn’t remove internal translations, so 
other customers of the losing carrier still come into the old PRI.  You’ll need 
to ask them to clean it up, I don’t think I have been patient enough to see it 
be cleaned up by itself.

-Nate

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Riley, Sean
Sent: Thursday, July 8, 2021 10:34 AM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] Ported to SIP carrier - some calls still coming in old 
carrier

We ported about 700 DID’s yesterday, from our PRI carrier to a new SIP carrier. 
Everything is working great, except I still see some calls coming into the old 
H323 gateways connected to the old carrier.  If I make a test call from my cell 
phone to the called number seen on the old gateway, the call routes through our 
new SIP gateway as expected.  Observing over the past 2 days it does seem that 
some of the calls are from the same “calling ID” and number.

Could it just take time for the port to propagate to other carriers and this 
will eventually work itself out over the coming days?  Or could there be 
something else causing calls from specific callers to still route through our 
old PRI carrier?

Thanks for any advice or knowledge you can share on this.

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

Re: [cisco-voip] Ported to SIP carrier - some calls still coming in old carrier

[Riley, Sean]

Thanks for the toll free suggestion Loren.  I have identified a couple of toll 
free numbers we have, and they are routing into the old PRI.  I had not even 
thought about those.

However, there are still some calls hitting it that are not toll free routing.  
Seems others have suggested internal translations inside the old carrier as 
well.  I will be reaching out to them to see if that is the cause.

Sean.

From: Loren Hillukka 
Sent: Thursday, July 8, 2021 12:48 PM
To: Riley, Sean 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Ported to SIP carrier - some calls still coming in 
old carrier

I’ve seen this with toll free numbers that deliver a local DID in, so you don’t 
know what the toll free being dialed is.
If you don’t have local records you will need to go to your toll free carrier 
(might not be the same one that owned the PRI) and request reports of all TFNs 
owned and what they point at or what they deliver to you when dialed.
Loren


On Jul 8, 2021, at 11:36 AM, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

We ported about 700 DID’s yesterday, from our PRI carrier to a new SIP carrier. 
Everything is working great, except I still see some calls coming into the old 
H323 gateways connected to the old carrier.  If I make a test call from my cell 
phone to the called number seen on the old gateway, the call routes through our 
new SIP gateway as expected.  Observing over the past 2 days it does seem that 
some of the calls are from the same “calling ID” and number.

Could it just take time for the port to propagate to other carriers and this 
will eventually work itself out over the coming days?  Or could there be 
something else causing calls from specific callers to still route through our 
old PRI carrier?

Thanks for any advice or knowledge you can share on this.

Sean.
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] Ported to SIP carrier - some calls still coming in old carrier

[Riley, Sean]

We ported about 700 DID's yesterday, from our PRI carrier to a new SIP carrier. 
Everything is working great, except I still see some calls coming into the old 
H323 gateways connected to the old carrier.  If I make a test call from my cell 
phone to the called number seen on the old gateway, the call routes through our 
new SIP gateway as expected.  Observing over the past 2 days it does seem that 
some of the calls are from the same "calling ID" and number.

Could it just take time for the port to propagate to other carriers and this 
will eventually work itself out over the coming days?  Or could there be 
something else causing calls from specific callers to still route through our 
old PRI carrier?

Thanks for any advice or knowledge you can share on this.

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

[cisco-voip] CUBE Monitoring SIP Provider

[Riley, Sean]

We are transitioning from traditional PSTN PRI's to SIP using CUBE.  With the 
PRI's I could monitor the logs on the router for when the PRI went down, so it 
would trigger an alert to splunk which we could alert off of.  I am having a 
hard time finding something similar in CUBE for when the SIP provider is down 
or not allowing calls to progress.

Any guidance on what others are doing to monitor their SIP provider service via 
CUBE would be much appreciated.

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

[cisco-voip] Unity SMTP Domain Change

[Riley, Sean]

We are migrating to a new Unity Connection cluster, from an existing Unity 
Connection cluster.  My question is around changing the SMTP Domain on the new 
UCxN to match the existing UCxN cluster.  The reason behind this is that we 
have some automation for other external services written around the 
"username@unityA.domain.local" and we have an Exchange email address policy to 
build an smtp alias for "username@unityA.domain.local" to mask the Unity smtp 
domain.

Once we migrate users to the new UCxN they will now be 
"username@unityB.domain.local".  My thought was I could keep from making  
changes to the external services and avoid creating another Exchange email 
alias by changing the SMTP domain on the new UCxN cluster to 
UnityA.domain.local.

Thoughts on this or am I creating more work than just keeping the SMTP domain 
as FQDN of the publisher and updating my external services referencing the old 
domain?

Current UCxN v 11.5
New UCxN v 12.5

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

Re: [cisco-voip] CUCM call set up issue after migration

[Riley, Sean]

Yes, I like easy.  I wanted to reboot the node earlier, but was told that 
should not be necessary.  Should have trusted my gut.  Now onto the other 
issues left over from this migration.

Jabber line presence is extremely delayed.  Have an IM cluster reboot 
scheduled for tonight.

From: Anthony Holloway 
Sent: Wednesday, January 13, 2021 12:24 AM
To: Riley, Sean 
Cc: Kent Roberts ; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Nice! That was easy.  This email chain goes into my folder called: When Someone 
Says Only Windows Servers Need Reboots.

On Tue, Jan 12, 2021 at 7:40 PM Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:
So far it seems the reboot resolved this problem.  Thanks for all the replies 
with guidance and help.

From: Kent Roberts mailto:k...@fredf.org>>
Sent: Tuesday, January 12, 2021 4:42 PM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Ah split brains. Gotta love it.   Did you restart the ones that did not move?   
 I have seen this when things go stupid. The sync usually isn’t the problem 
it’s the real-time communication between the nodes that’s all messed up. 
Usually can fix with a node reboot or restarting the cucm and cti services.   
Course their maybe more to it but if things are in sync  should not be hard to 
fix

Kent

On Jan 12, 2021, at 14:06, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

This past weekend we migrated 2 CUCM servers to a new datacenter.  This 
involved changing the IP address on these 2 CUCM nodes.  These 2 nodes consist 
of the Publisher and 1 Subscriber.  We have another Sub at a remote datacenter 
that was not touched this past weekend.

Node configuration:

DC A
CM1: Pub which was re-ip’d
CM2: Sub which was re-ip’d

DC B:
CM3: Sub at remote site that was not changed

Phones are at many sites, but issue is independent of the phone type, phone 
location or subnet.  Also, Expressway phones have the same issue.

The issue is any phone that is registered to CM3 cannot call phones registered 
to CM1 or CM2 and vice versa.  The phones do not see the call coming in.  If 
SNR is configured, the call will ring to the remote destination. Phones 
registered to CM3 can make outbound PSTN calls without issue, but not receive 
inbound from PSTN (probably because the gateway is handing off to CM1 or CM2).  
While the gateways are not unique to the issue, they are running H323.

If the phones are both registered to CM3, they can call each other, but not 
phones registered to CM1 or CM2.

I have had my network team verify there is not anything they can see in the 
network causing this behavior. Database replication checks out OK and I can 
ping from/to each node.

Anyone able to point me in the right direction to figure this out?

Thanks.
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] CUCM call set up issue after migration

[Riley, Sean]

So far it seems the reboot resolved this problem.  Thanks for all the replies 
with guidance and help.

From: Kent Roberts 
Sent: Tuesday, January 12, 2021 4:42 PM
To: Riley, Sean 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Ah split brains. Gotta love it.   Did you restart the ones that did not move?   
 I have seen this when things go stupid. The sync usually isn’t the problem 
it’s the real-time communication between the nodes that’s all messed up. 
Usually can fix with a node reboot or restarting the cucm and cti services.   
Course their maybe more to it but if things are in sync  should not be hard to 
fix

Kent


On Jan 12, 2021, at 14:06, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

This past weekend we migrated 2 CUCM servers to a new datacenter.  This 
involved changing the IP address on these 2 CUCM nodes.  These 2 nodes consist 
of the Publisher and 1 Subscriber.  We have another Sub at a remote datacenter 
that was not touched this past weekend.

Node configuration:

DC A
CM1: Pub which was re-ip’d
CM2: Sub which was re-ip’d

DC B:
CM3: Sub at remote site that was not changed

Phones are at many sites, but issue is independent of the phone type, phone 
location or subnet.  Also, Expressway phones have the same issue.

The issue is any phone that is registered to CM3 cannot call phones registered 
to CM1 or CM2 and vice versa.  The phones do not see the call coming in.  If 
SNR is configured, the call will ring to the remote destination. Phones 
registered to CM3 can make outbound PSTN calls without issue, but not receive 
inbound from PSTN (probably because the gateway is handing off to CM1 or CM2).  
While the gateways are not unique to the issue, they are running H323.

If the phones are both registered to CM3, they can call each other, but not 
phones registered to CM1 or CM2.

I have had my network team verify there is not anything they can see in the 
network causing this behavior. Database replication checks out OK and I can 
ping from/to each node.

Anyone able to point me in the right direction to figure this out?

Thanks.
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] CUCM call set up issue after migration

[Riley, Sean]

Thanks for the quick reply.  I have a change request to restart the node that 
did not move tonight.  I will follow up to let you know if this helped.

From: Kent Roberts 
Sent: Tuesday, January 12, 2021 4:42 PM
To: Riley, Sean 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Ah split brains. Gotta love it.   Did you restart the ones that did not move?   
 I have seen this when things go stupid. The sync usually isn’t the problem 
it’s the real-time communication between the nodes that’s all messed up. 
Usually can fix with a node reboot or restarting the cucm and cti services.   
Course their maybe more to it but if things are in sync  should not be hard to 
fix

Kent


On Jan 12, 2021, at 14:06, Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:

This past weekend we migrated 2 CUCM servers to a new datacenter.  This 
involved changing the IP address on these 2 CUCM nodes.  These 2 nodes consist 
of the Publisher and 1 Subscriber.  We have another Sub at a remote datacenter 
that was not touched this past weekend.

Node configuration:

DC A
CM1: Pub which was re-ip’d
CM2: Sub which was re-ip’d

DC B:
CM3: Sub at remote site that was not changed

Phones are at many sites, but issue is independent of the phone type, phone 
location or subnet.  Also, Expressway phones have the same issue.

The issue is any phone that is registered to CM3 cannot call phones registered 
to CM1 or CM2 and vice versa.  The phones do not see the call coming in.  If 
SNR is configured, the call will ring to the remote destination. Phones 
registered to CM3 can make outbound PSTN calls without issue, but not receive 
inbound from PSTN (probably because the gateway is handing off to CM1 or CM2).  
While the gateways are not unique to the issue, they are running H323.

If the phones are both registered to CM3, they can call each other, but not 
phones registered to CM1 or CM2.

I have had my network team verify there is not anything they can see in the 
network causing this behavior. Database replication checks out OK and I can 
ping from/to each node.

Anyone able to point me in the right direction to figure this out?

Thanks.
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] CUCM call set up issue after migration

[Riley, Sean]

This past weekend we migrated 2 CUCM servers to a new datacenter.  This 
involved changing the IP address on these 2 CUCM nodes.  These 2 nodes consist 
of the Publisher and 1 Subscriber.  We have another Sub at a remote datacenter 
that was not touched this past weekend.

Node configuration:

DC A
CM1: Pub which was re-ip'd
CM2: Sub which was re-ip'd

DC B:
CM3: Sub at remote site that was not changed

Phones are at many sites, but issue is independent of the phone type, phone 
location or subnet.  Also, Expressway phones have the same issue.

The issue is any phone that is registered to CM3 cannot call phones registered 
to CM1 or CM2 and vice versa.  The phones do not see the call coming in.  If 
SNR is configured, the call will ring to the remote destination. Phones 
registered to CM3 can make outbound PSTN calls without issue, but not receive 
inbound from PSTN (probably because the gateway is handing off to CM1 or CM2).  
While the gateways are not unique to the issue, they are running H323.

If the phones are both registered to CM3, they can call each other, but not 
phones registered to CM1 or CM2.

I have had my network team verify there is not anything they can see in the 
network causing this behavior. Database replication checks out OK and I can 
ping from/to each node.

Anyone able to point me in the right direction to figure this out?

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

[cisco-voip] Implementing 802.1x for IP Phones - issue with UCM timeout

[Riley, Sean]

We are working on implementing 802.1x with our 8851 ip phones.  We have 
installed the LSC cert and enabled 802.1x on a few phones for testing.  We are 
using Cisco ISE and the switch is configured for host mode multi domain.  
Everything seemed to be working fine, until we noticed the phones were 
resetting about every 48 minutes.  Looking at the logs on the phone it seems it 
is being reset due to a timeout with CUCM.

ReasonForOutOfService=10 followed by a ReasonForOutOfService=23

My Cisco ISE admin didn't see anything on that side that he thinks is causing 
the timeout, and we only seem to see this issue after registering the phone 
with 802.1x enabled.

Any thoughts before I start collecting traces and wireshark captures.

CUCM v 11.5(1) SU6
IP phones are on latest firmware 12.7 or 12.8

Thanks.

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

[cisco-voip] 7900 Factory Reset w/out connecting to the network

[Riley, Sean]

We are finally refreshing our 7970's.  We wanted to factory reset the old 
phones before sending out for scrap.  Is there a way to factory reset without 
having to connect to the network?

Thanks.

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

Re: [cisco-voip] Renewing Expressway E Cert

[Riley, Sean]

I really do appreciate your responses.  Especially since I could have RTFM.

From: Anthony Holloway 
Sent: Thursday, April 23, 2020 2:16 AM
To: Riley, Sean 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Renewing Expressway E Cert

WARNING: External Email

I think I could have written a piece of that better

"...which is at a random/unpredictable time, where it will not for port 80 
traffic to port 443 for a very specific GET Request to a very specific URL."

I think that's better.  Anyway, I read it in the documentation, so if what I 
wrote is confusing, just read the docs.  1:00am email replies.  sheesh!

On Thu, Apr 23, 2020 at 1:13 AM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
First and foremost, the document describes how port 80 is used pretty well.  It 
goes on to say that its no less secure than port 443, because the same 
underlying program/process answers to both, thus is susceptible to the same 
attacks.

People think it's less secure because it's clear text communication, but that's 
not pertinent to how people attack a host.  It is however, how you intercept 
communications, and then use that information to your advantage.

However, the document also describes how port 80 is auto redirecting all 
traffic to 443 by default, until the renewal process starts, which is at a 
random/unpredictable time, and is only changed to redirect port 80 traffic to 
443 for a very specific GET Request to a very specific URL.  In which case, the 
port 80 traffic is then redirected to another separate web server instance 
which is spun up just in this moment to handle the comms with let's encrypt, 
and as soon as it's done, the web server instance is turned off, and all port 
80 traffic is again redirected to 443.

So, the security of the system is actually pretty tight.  Is it 100%? probably 
not.  But then again, what truly is 100% secure?

On Wed, Apr 22, 2020 at 3:42 PM Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:
Thanks for the reply and cliffs notes about the setup.  My security team has 
concerns with having port 80 open to facility the Let’s Encrypt process.  
Documentation states something about allowing the built in protections without 
giving much info on what those protections are.

I would love to be able to set it and forget it.

From: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Sent: Friday, April 17, 2020 4:23 PM
To: Riley, Sean 
mailto:sri...@robinsonbradshaw.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Renewing Expressway E Cert

WARNING: External Email

This might be an unpopular opinion, but I think using the free certs provided 
by let's encrypt, coupled with it being automatic from now on, it's just an 
unbeatable combination.

Here are my cliff notes:

Reference Document:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_certificate-creation-use-deployment-guide/exwy_b_certificate-creation-use-deployment-guide_chapter_0100.html

High Level Steps:

  1.  Expressway 12.5.7 to avoid ACMEv1 vs ACMEv2 registration issues 
(https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr82346)
  2.  For your Unified CM registrations domains don’t use parent domain only 
(E.g., company.com<http://company.com>), switch to CollabEdgeDNS format instead 
(E.g., collab-edge.company.com<http://collab-edge.company.com>), because you’ll 
need that in the next step
  3.  DNS A records for the Expressway-E FQDN and the CM registration domains
  4.  Upload the root and intermediates for Let’s Encrypt (needed on both 
Expressway-E and Expressway-C) (certs are linked in documentation)
  5.  Enable the ACME client on Expressway-E and supply any email address you 
want to link to this registration (This creates your account with Let’s Encrypt)
  6.  Generate a new CSR (Server Certificate Only, Domain Cert Was Not Needed)
  7.  Click button to Submit CSR to ACME
  8.  Click button to Deploy New Certificate on Expressway-E (documentation 
states this is non-service impacting)
  9.  Setup the automatic scheduler so you never have to deal with this again
  10. Sit back, relax and enjoy free shit



On Fri, Apr 17, 2020 at 1:43 PM Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:
We had our Cisco partner setup our Expressways a couple of years ago.  It is a 
cluster with 2 E’s and 2 C’s currently at v 12.5.7 using for MRA.  I have been 
managing them, installing updates, troubleshooting etc.  The public Edge cert 
is up for renewal.  Can anyone provide advice on renewing this cert?  I am 
planning on just renewing with the same cert provider, but was interested in if 
there is anything to watch out for.  Example, will there be a service 
interruption when replacing the cert?  Or just install

Re: [cisco-voip] Renewing Expressway E Cert

[Riley, Sean]

Thanks for the reply and cliffs notes about the setup.  My security team has 
concerns with having port 80 open to facility the Let’s Encrypt process.  
Documentation states something about allowing the built in protections without 
giving much info on what those protections are.

I would love to be able to set it and forget it.

From: Anthony Holloway 
Sent: Friday, April 17, 2020 4:23 PM
To: Riley, Sean 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Renewing Expressway E Cert

WARNING: External Email

This might be an unpopular opinion, but I think using the free certs provided 
by let's encrypt, coupled with it being automatic from now on, it's just an 
unbeatable combination.

Here are my cliff notes:

Reference Document:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_certificate-creation-use-deployment-guide/exwy_b_certificate-creation-use-deployment-guide_chapter_0100.html

High Level Steps:

  1.  Expressway 12.5.7 to avoid ACMEv1 vs ACMEv2 registration issues 
(https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr82346)
  2.  For your Unified CM registrations domains don’t use parent domain only 
(E.g., company.com<http://company.com>), switch to CollabEdgeDNS format instead 
(E.g., collab-edge.company.com<http://collab-edge.company.com>), because you’ll 
need that in the next step
  3.  DNS A records for the Expressway-E FQDN and the CM registration domains
  4.  Upload the root and intermediates for Let’s Encrypt (needed on both 
Expressway-E and Expressway-C) (certs are linked in documentation)
  5.  Enable the ACME client on Expressway-E and supply any email address you 
want to link to this registration (This creates your account with Let’s Encrypt)
  6.  Generate a new CSR (Server Certificate Only, Domain Cert Was Not Needed)
  7.  Click button to Submit CSR to ACME
  8.  Click button to Deploy New Certificate on Expressway-E (documentation 
states this is non-service impacting)
  9.  Setup the automatic scheduler so you never have to deal with this again
  10. Sit back, relax and enjoy free shit



On Fri, Apr 17, 2020 at 1:43 PM Riley, Sean 
mailto:sri...@robinsonbradshaw.com>> wrote:
We had our Cisco partner setup our Expressways a couple of years ago.  It is a 
cluster with 2 E’s and 2 C’s currently at v 12.5.7 using for MRA.  I have been 
managing them, installing updates, troubleshooting etc.  The public Edge cert 
is up for renewal.  Can anyone provide advice on renewing this cert?  I am 
planning on just renewing with the same cert provider, but was interested in if 
there is anything to watch out for.  Example, will there be a service 
interruption when replacing the cert?  Or just install the new cert/pk and rest 
easy?

Thanks in advance.

Sean.
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] Renewing Expressway E Cert

[Riley, Sean]

We had our Cisco partner setup our Expressways a couple of years ago.  It is a 
cluster with 2 E's and 2 C's currently at v 12.5.7 using for MRA.  I have been 
managing them, installing updates, troubleshooting etc.  The public Edge cert 
is up for renewal.  Can anyone provide advice on renewing this cert?  I am 
planning on just renewing with the same cert provider, but was interested in if 
there is anything to watch out for.  Example, will there be a service 
interruption when replacing the cert?  Or just install the new cert/pk and rest 
easy?

Thanks in advance.

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

[cisco-voip] IPMA plugin installation

[Riley, Sean]

We have been running IPMA for 13 years and while it is a pain to manage, our 
users love it and currently won't allow us to get rid of it.  My question is 
around installing the plugin for our users using Microsoft SCCM.  We have 
"repackaged" this install as an MSI for years, but my apps team would like to 
just run the exe silently.  They are having trouble getting this to work.

Has anyone out there using IPMA created a successful install using the native 
exe file provided by cisco via the applications - plugins download for IPMA?  
Our users are locked down from installing software on their computers, so it 
needs to be run via SCCM install.

Thanks.

Sean Riley

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