The phones actually start ringing as expected. It's the behavior after the call is answered that is the problem.
This was a 5 cluster project that started prior to the release of SU2 and SU2a so going back and upgrading again wasn't an option. On Sep 30, 2015 9:27 PM, "Anthony Holloway" <[email protected]> wrote: > 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&B&C (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 <[email protected]> > 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 <[email protected]> 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:[email protected]] *On >>> Behalf Of *Erick Wellnitz >>> *Sent:* Wednesday, September 30, 2015 3:51 PM >>> *To:* Lelio Fulgenzi <[email protected]> >>> *Cc:* [email protected] >>> *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 <[email protected]> >>> 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: >>> >>> <snip> >>> •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). >>> <snip> >>> >>> >>> >>> 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 <519%E2%80%90824%E2%80%904120%20Ext%2056354> >>> [email protected] >>> www.uoguelph.ca/ccs >>> Room 037, Animal Science and Nutrition Building >>> Guelph, Ontario, N1G 2W1 >>> >>> >>> ------------------------------ >>> >>> *From: *"Erick Wellnitz" <[email protected]> >>> *To: *"Lelio Fulgenzi" <[email protected]> >>> *Cc: *[email protected] >>> *Sent: *Wednesday, September 30, 2015 12:20:51 PM >>> *Subject: *Re: [cisco-voip] strange shared line behavior on 88XX phones >>> >>> >>> >>> It is on a fair number of them. They didn't have the issue on 8.6.2 >>> with the same firmware. >>> >>> >>> >>> We're waiting on the next occurrence to gather traces. >>> >>> >>> >>> On Wed, Sep 30, 2015 at 10:04 AM, Lelio Fulgenzi <[email protected]> >>> wrote: >>> >>> >>> >>> I recall there being an (un)written rule where shared lines should not >>> be the primary line. It could cause issues. >>> >>> >>> >>> Are the shared lines the first DN on the phone? >>> >>> >>> >>> Lelio >>> >>> >>> >>> --- >>> Lelio Fulgenzi, B.A. >>> Senior Analyst, Network Infrastructure >>> Computing and Communications Services (CCS) >>> University of Guelph >>> >>> >>> >>> 519‐824‐4120 Ext 56354 <519%E2%80%90824%E2%80%904120%20Ext%2056354> >>> [email protected] >>> www.uoguelph.ca/ccs >>> Room 037, Animal Science and Nutrition Building >>> Guelph, Ontario, N1G 2W1 >>> >>> >>> ------------------------------ >>> >>> *From: *"Erick Wellnitz" <[email protected]> >>> *To: *[email protected] >>> *Sent: *Wednesday, September 30, 2015 12:00:20 PM >>> *Subject: *[cisco-voip] strange shared line behavior on 88XX phones >>> >>> >>> >>> anyone seen issues with the 88xx phones on firmware 10.3(1) and CUCM >>> 10.5.2 SU1 where the line starts ringing on some phones right away and some >>> start ringing up to 15 seconds later. Some also experience ringing after >>> the call is answered up to 15 seconds after answered. >>> >>> >>> >>> 88xx phones are the only ones exhibiting this behavior. Another >>> consideration is that this shared line is on 17 devices. >>> >>> >>> >>> Thanks for any insight! >>> >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >>> >> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
