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

2015-09-30 Thread Erick Wellnitz
The random nature of the issue would make captures a difficult endeavor. On Wed, Sep 30, 2015 at 11:09 AM, Brian Meade wrote: > I'd try to get simultaneous captures from 2 phones with the delay between > them to see if CUCM is sending the SIP Invite delayed. You could also >

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

2015-09-30 Thread Erick Wellnitz
I wonder what they consider "unexplained post configuration behavior". This particular line has been set up this way for a number of years without issue so it has something to do with the 10.5 system. On Wed, Sep 30, 2015 at 11:09 AM, Lelio Fulgenzi wrote: > turns out it is

Re: [cisco-voip] access to service subscription when publisher down...

2015-09-30 Thread Ryan Ratliff (rratliff)
What is the value of your Enterprise Service? The default services that start with “Application:Cisco” are the ones that the phone interprets and will always be an https connection to the server the phone is registered to. The 7940/60 phones don’t support the Device->Device Settings->Phone

Re: [cisco-voip] 3650 PoE Issue

2015-09-30 Thread Casper, Steven
Module Available Used Remaining (Watts) (Watts)(Watts) -- - - 1 1550.0 141.0 1409.0 2 1550.096.9 1453.1 3 1550.0165.5 1384.5 4

Re: [cisco-voip] CUCM Self Provisioning...

2015-09-30 Thread Jonathan Charles
OK, cool... but as soon as I did that, I get a host not found on the new phones when they try to load the idle page... weird thing is I checked the URL that the phones picked up, and they open an XML page fine from that vLAN... Jonathan On Wed, Sep 30, 2015 at 1:27 PM, Brian Meade

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

2015-09-30 Thread Daniel Pagan
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

Re: [cisco-voip] 3650 PoE Issue

2015-09-30 Thread Ryan Huff
You may also try increasing the poe advertisement length on the port ( power inline delay shutdown 20 initial 300 ).  Sent from my T-Mobile 4G LTE Device Original message From: "Casper, Steven" Date:09/30/2015 5:18 PM (GMT-05:00) To: 'Ryan Huff'

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

2015-09-30 Thread Daniel Pagan
Also, if you’re not sure of which 200 final response belongs to the INVITE vs CANCEL, check out the CSeq header of the 200 message body. Typical call flow should be: ::Call is placed to phone:: cucm --> INVITE --> phoneA cucm --> INVITE --> phoneB cucm --> INVITE --> phoneC cucm <-- 100 <--

[cisco-voip] 3650 PoE Issue

2015-09-30 Thread Casper, Steven
Having an issue related to PoE negotiation between 3650 switches that we are beginning to deploy and older cisco phones such as 7960s and 7940s . I think these are using the pre PoE standard. Symptoms are when the stack reloads the switchports connected to Cisco 7960 telephones come up in a

Re: [cisco-voip] 3650 PoE Issue

2015-09-30 Thread Joe Martini
Sounds very similar to https://tools.cisco.com/bugsearch/bug/CSCui2/ , however you should have the fix already. Good idea to open a TAC case to look into this. Joe On Sep 30, 2015, at 8:33 AM, Casper, Steven wrote:

Re: [cisco-voip] CUCM Self Provisioning...

2015-09-30 Thread Brian Meade
You need to make sure you have 2 universal device templates. One for the users that have been provisioned and one for new phones set under the Auto-registration section. On Wed, Sep 30, 2015 at 5:07 PM, Jonathan Charles wrote: > OK, cool... but as soon as I did that, I get a

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

2015-09-30 Thread Erick Wellnitz
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

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

2015-09-30 Thread James Andrewartha
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

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

2015-09-30 Thread Abhiram Kramadhati (akramadh)
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

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

2015-09-30 Thread Brian Meade
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? On Wed, Sep 30, 2015 at 12:26 AM,

Re: [cisco-voip] 3650 PoE Issue

2015-09-30 Thread Ryan Huff
How much available power do you have left on the POE backplane once all phones are up and working? From: scas...@mtb.com To: cisco-voip@puck.nether.net Date: Wed, 30 Sep 2015 12:33:51 + Subject: [cisco-voip] 3650 PoE Issue Having an issue related to PoE negotiation between 3650

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

2015-09-30 Thread Erick Wellnitz
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 wrote: > > I recall there being an (un)written rule where shared lines should

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

2015-09-30 Thread Lelio Fulgenzi
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)

Re: [cisco-voip] access to service subscription when publisher down...

2015-09-30 Thread Lelio Fulgenzi
Thanks Brian. Right now, it's set to "both". The 7942/62 have the same Services URL programmed on the phone config page as the 7940/60, but this is overridden by the enterprise service url subscription. I know/assume this is the case, because when I go to the phones web server to look things

[cisco-voip] access to service subscription when publisher down...

2015-09-30 Thread Lelio Fulgenzi
For the 7940/60 phones, I was able to point to a particular server for a service list in the event the publisher is down so they can still use this one service. In the XML file, I then pointed back to the publisher for the list of subscribed services. The 7942/62s don't work this way, since

Re: [cisco-voip] access to service subscription when publisher down...

2015-09-30 Thread Brian Meade
Lelio, It depends on what you have selected for Services Provisioning. If you have it selected to Internal under Enterprise Parameters, it communicates with the registered subscriber for things like Directories and such. If you set it to External Services Provisioning, it uses the Services URL.

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

2015-09-30 Thread Lelio Fulgenzi
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;

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

2015-09-30 Thread Brian Meade
I'd try to get simultaneous captures from 2 phones with the delay between them to see if CUCM is sending the SIP Invite delayed. You could also check the CallManager traces to see if all the Invites go out the same time but that doesn't mean they didn't get queued up on the OS side if TCP. You