Re: [cisco-voip] strange shared line behavior on 88XX phones

[Daniel Pagan]

Hey Anthony – very valid points. I assumed the delayed 487 final response Erick 
mentioned was in reference to phones continuing to ring past the answer, and 
not stopping the ringer when the call is answered elsewhere.

Based on console logs, the 487 seems to be a prerequisite to disabling the 
local ringer, but if the issue is a delay in *starting* the ringer, then I 
agree this 487 certainly shouldn’t be applicable.

Dan

From: avhollo...@gmail.com [mailto:avhollo...@gmail.com] On Behalf Of Anthony 
Holloway
Sent: Wednesday, September 30, 2015 11:27 PM
To: Erick Wellnitz
Cc: Daniel Pagan; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Having the 487 delayed would not impact when the phone starts ringing though.  
In fact, the phones should start ringing at the sending of the 180 back to 
CUCM.  In Daniel's diagram that would be this one:

cucm <-- 180 <-- phoneA (one response per phone)

So, if anything, there should be a delay in the CUCM sending of the INVITE to 
the delayed ringing phone(s), or the delayed ringing phone(s) should delay 
their 180 back to CUCM.  If none of this is delayed on the wire, then I would 
think it's some internal firmware bug on the phone.  Have you tried an older or 
newer firmware?  Granted, you had the same firmware on the 8.6(2), but since 
we're grasping for ideas, why not give it a shot?

Also, have you looked in bug search tool yet?  I only found this one closely 
related bug, but as with all filed defects, you can never really be 100% sure.

https://tools.cisco.com/bugsearch/bug/CSCur10651

Good luck.  Also, you should be on 10.5(2)SU2a.  ;)  Just say'n.



On Wed, Sep 30, 2015 at 4:38 PM, Erick Wellnitz 
> wrote:
The 200 comes relatively quickly and the CM sends the ACK back quickly.  It's 
only the 487 that is delayed and not all the time.  The time frame in the 
console logs matches the CM traces so it doesn't look like any funny business 
on the network.

This one is a head scratcher for sure.

On Wed, Sep 30, 2015 at 3:08 PM, Daniel Pagan 
> wrote:
Interesting… Out of curiosity, there should first be a CANCEL to the IP phones 
where the call wasn’t answered. The phones should then 200 that CANCEL request, 
and then send the 487 final response to the original INVITE for the call. Do 
you see the 487 final response six seconds after the CANCEL/200 exchange? I ask 
only because this should help you determine where the delay is coming from - 
the phone or CUCM.

- Dan

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Erick Wellnitz
Sent: Wednesday, September 30, 2015 3:51 PM
To: Lelio Fulgenzi >
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Finally had the behavior repeat.

Found in the console logs and the CM traces that a couple of the phones are, 
for some reason, delaying their 487 - Request Cancelled response for up to 6 
seconds from when the call is answered.

Sent to TAC to see what they have to say.

On Wed, Sep 30, 2015 at 11:09 AM, Lelio Fulgenzi 
> wrote:
turns out it is written.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmsys/accm-712-cm/a03dn.html#wp1100362


Shared Line Restrictions

The following restrictions apply to shared lines:


•Do not configure shared-line appearances on the primary lines of the phones; 
for example, if two phones have a shared-line appearance, only one of the 
phones should have the primary line configured as shared (the other phone 
should have the secondary line configured as shared).




In version 10 it becomes a suggestion though. Interesting.



http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010001.html#CUCM_RF_S05975F9_00

Shared Line Suggestions
Do not configure shared line appearances on primary lines as certain feature 
interactions are impacted. Settings of the primary line are applicable to the 
shared line. For example: if two phones have a shared-line appearance, only one 
phone should have the primary line configured as shared to avoid unexplained 
post configuration behavior.

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519‐824‐4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


From: "Erick Wellnitz" >
To: "Lelio 

Re: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning

[NateCCIE]

I am hoping that you can upgrade from 10.6.1 su1 to 11.  Do you know of that 
will also be permitted?

Sent from my iPhone

> On Sep 30, 2015, at 8:49 PM, Abhiram Kramadhati (akramadh) 
>  wrote:
> 
> CSCuw49432 filed to include 10.6(1) in supported upgrade path
> 
> Working to get the CAD upgrade part addressed as well, will keep you
> updated. 
> 
> Cheers,
> Abhiram Kramadhati
> 
> 
>> On 29/09/15 6:48 am, "Erick Bergquist"  wrote:
>> 
>> The 10.6(1) SU1 compatibility matrix also does not list 10.6(1) as a
>> valid upgrade path for 10.6(1) SU1.
>> 
>> http://docwiki.cisco.com/wiki/Unified_CCX_Software_Compatibility_Matrix_fo
>> r_10.6(1)SU1
>> 
>> 
>> On Thu, Sep 24, 2015 at 6:50 PM, Abhiram Kramadhati (akramadh)
>>  wrote:
>>> Thank you Justin, I will get this corrected. Appreciate your heads-up
>>> here.
>>> 
>>> Regards,
>>> Abhiram Kramadhati
>>> Technical Solutions Manager, CBABU
>>> CCIE Collaboration # 40065
>>> 
>>> From: Justin Steinberg 
>>> Date: Friday, 25 September 2015 2:41 am
>>> To: Cisco VOIP 
>>> Subject: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning
>>> 
>>> The current UCCX compatibility matrix lists CAD 10.6.1.95 for both UCCX
>>> 10.6(1) and 10.6(1)SU1, implying there is no CAD upgrade forced after
>>> the
>>> SU1 upgrade.
>>> 
>>> This isn't the case.   Upgrading 10.6(1) to 10.6(1)su1 does force a CAD
>>> upgrade.
>>> 
>>> Hopefully this helps someone else.
>>> 
>>> Justin
>>> 
>>> ___
>>> 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] Unity Connection 11 /ssosp/relay - Access Denied 403

[Matthew Loraditch]

Anyone seen this one? I love sso but the various issues in getting it online 
the first time drive me insane..

I'm also now seeing IM in a constant redirect loop after I enabled that 
server...

Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

Facebook | 
Twitter | 
LinkedIn 
| G+

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

Re: [cisco-voip] Unity Connection 11 /ssosp/relay - Access Denied 403

[Thomas LeMay]

Hi, Matthew,

 

We have SSO configured on our unity connection 10.5.2 cluster but it is
behaving oddly.  We have to access serviceability to use the sso but we need
to sign in with a user name and password for the administration web page.
Did you have this issue?

 

Tom

 

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of
Matthew Loraditch
Sent: Thursday, October 01, 2015 12:30 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Unity Connection 11 /ssosp/relay - Access Denied 403

 

Anyone seen this one? I love sso but the various issues in getting it online
the first time drive me insane..

 

I'm also now seeing IM in a constant redirect loop after I enabled that
server.

 

Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

  Facebook |
 Twitter |

LinkedIn |   G+

 

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

Re: [cisco-voip] Unity Connection 11 /ssosp/relay - Access Denied 403

[Matthew Loraditch]

I have had that issue on 10.5.2 servers. Sometimes disabling secure os 
enforcement during the enablement helps. We have very few people who use the 
admin pages so I've never bothered to engage TAC due to time constraints as 
user facing pages have never had an issue.

Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
[Email_Sig_Template_H_shortcopy_UPDATED]
Facebook | 
Twitter | 
LinkedIn 
| G+

From: Thomas LeMay [mailto:thomasle...@comcast.net]
Sent: Thursday, October 1, 2015 2:17 PM
To: Matthew Loraditch ; 
cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Unity Connection 11 /ssosp/relay - Access Denied 403

Hi, Matthew,

We have SSO configured on our unity connection 10.5.2 cluster but it is 
behaving oddly.  We have to access serviceability to use the sso but we need to 
sign in with a user name and password for the administration web page.  Did you 
have this issue?

Tom

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Loraditch
Sent: Thursday, October 01, 2015 12:30 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Unity Connection 11 /ssosp/relay - Access Denied 403

Anyone seen this one? I love sso but the various issues in getting it online 
the first time drive me insane..

I'm also now seeing IM in a constant redirect loop after I enabled that 
server...

Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebook | 
Twitter | 
LinkedIn 
| G+

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

Re: [cisco-voip] Phantom tomcat-trust cert

[Brian Meade]

You can try to download the tomcat.pem from the publisher and manually
install it on the presence server as a tomcat-trust.  Since the Common Name
is the same, it should replace the existing tomcat-trust.

On Wed, Sep 30, 2015 at 10:19 PM, James Andrewartha <
jandrewar...@ccgs.wa.edu.au> wrote:

> On 30/09/15 22:29, Brian Meade wrote:
> > So if you stop the certificate change notification service on the
> > publisher and that presence server then delete the tomcat-trust on the
> > presence server, you see it propagate that old tomcat-trust again to the
> > presence server after the services are started again?
>
> Correct, with the exception that there's no certificate change
> notification service on the presence server, only an expiry monitor.
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Upgrade of CUCM with UCCX HA enabled

[Anthony Holloway]

RE: Hunt Groups

Just make sure you're following the restrictions of such a design:

"Agent extensions cannot be added to hunt lists or hunt groups. If an agent
has only one line, then the agent phone cannot be part of a hunt list or
hunt group. In the case of multiple lines, none of the lines on the first
four lines monitored by the UCCX must be part of the hunt group."

Source:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_6/release/docs/UCCX_BK_UC733F42_00_uccx-release-notes-106/UCCX_BK_UC733F42_00_uccc-release-notes-106_chapter_00.html

That limitation would of course eliminate your ability to build a hunt
group with Jabber Softphones, or any model IP phone which only has a single
line appearance.

On Thu, Oct 1, 2015 at 8:12 AM, Justin Steinberg 
wrote:

> You drop calls in queue and on the IVR when you restart the engine.  It
> takes about a minute usually on restart and calls can get busy signals
> during that time.
>
> In some cases, I create backup UCM hunt groups and route the calls around
> CCX entirely.  They lose reporting and IVR but calls get to agents.
>
> Justin
> On Oct 1, 2015 3:06 AM, "Nathan Reeves"  wrote:
>
>> Currently running UCCX 9.0.1 with Warm Standby HA enabled.  Scheduling an
>> upgrade in the CUCM version from 9.1.2SU1 to 9.1.2SU4 and trying to
>> determine if we can minimise downtime on the UCCX component.
>>
>> When the switch version is completed you understanably end up with JTAPI
>> versions out of sync which requires a resync and engine restart.
>>
>> Anyone know the best / suggested approach to completing an upgrade like
>> this and minimising downtime on the UCCX Services?  Is it just a
>> requirement that there's an outage window?
>>
>> Thanks
>>
>> Nathan
>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning

[Abhiram Kramadhati (akramadh)]

Hi Nate, 

Yes, it is supported. It has not been updated on the guide, the document
defect has been filed to address that: CSCuw51381

There seem to be a couple of places that haven¹t been updated after SU1
was released :)

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CBABU
CCIE Collaboration # 40065



On 02/10/15 12:48 am, "NateCCIE"  wrote:

>I am hoping that you can upgrade from 10.6.1 su1 to 11.  Do you know of
>that will also be permitted?
>
>Sent from my iPhone
>
>> On Sep 30, 2015, at 8:49 PM, Abhiram Kramadhati (akramadh)
>> wrote:
>> 
>> CSCuw49432 filed to include 10.6(1) in supported upgrade path
>> 
>> Working to get the CAD upgrade part addressed as well, will keep you
>> updated. 
>> 
>> Cheers,
>> Abhiram Kramadhati
>> 
>> 
>>> On 29/09/15 6:48 am, "Erick Bergquist"  wrote:
>>> 
>>> The 10.6(1) SU1 compatibility matrix also does not list 10.6(1) as a
>>> valid upgrade path for 10.6(1) SU1.
>>> 
>>> 
>>>http://docwiki.cisco.com/wiki/Unified_CCX_Software_Compatibility_Matrix_
>>>fo
>>> r_10.6(1)SU1
>>> 
>>> 
>>> On Thu, Sep 24, 2015 at 6:50 PM, Abhiram Kramadhati (akramadh)
>>>  wrote:
 Thank you Justin, I will get this corrected. Appreciate your heads-up
 here.
 
 Regards,
 Abhiram Kramadhati
 Technical Solutions Manager, CBABU
 CCIE Collaboration # 40065
 
 From: Justin Steinberg 
 Date: Friday, 25 September 2015 2:41 am
 To: Cisco VOIP 
 Subject: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning
 
 The current UCCX compatibility matrix lists CAD 10.6.1.95 for both
UCCX
 10.6(1) and 10.6(1)SU1, implying there is no CAD upgrade forced after
 the
 SU1 upgrade.
 
 This isn't the case.   Upgrading 10.6(1) to 10.6(1)su1 does force a
CAD
 upgrade.
 
 Hopefully this helps someone else.
 
 Justin
 
 ___
 cisco-voip mailing list
 cisco-voip@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-voip
>> 
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip

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

Re: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning

[Abhiram Kramadhati (akramadh)]

Closing the loop on this.

The CAD version for 10.6(1) is 10.6.1.95
The CAD version for 10.6(1)SU1 is 10.6.1.1057

The compatibility matrix for 10.6(1)SU1 has wrongly mentioned it as 10.6.1.95 
and CSCuw51442 has been filed to correct this.

As a side note, it would be best to plan for a client side upgrade for any 
server upgrade done. Please let me know if there are any questions, thank you.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CBABU
CCIE Collaboration # 40065

From: Justin Steinberg >
Date: Friday, 25 September 2015 2:41 am
To: Cisco VOIP >
Subject: [cisco-voip] UCCX 10.6(1) SU1 CAD Upgrade Warning

The current UCCX compatibility matrix lists CAD 10.6.1.95 for both UCCX 10.6(1) 
and 10.6(1)SU1, implying there is no CAD upgrade forced after the SU1 upgrade.

This isn't the case.   Upgrading 10.6(1) to 10.6(1)su1 does force a CAD upgrade.

Hopefully this helps someone else.

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