Re: [cisco-voip] 8800 Series firmware upgrade 12.0(1) text color

[Bill Talley]

Found this bug/feature enhancement.   I'll be opening a case and
associating it to the feature request.

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

Phone text illegible on different backgrounds.
CSCvg62384
Description
Changing font colors or toggle font boxes for DNs would allow users to
personalize the phone aloowing them to mix between backgrounds and font
colurs.

Symptom:
On 88xx phones with 12.0.1.SR1, the white DN box was removed to allow the
background to be visible.
Now, with some background images, the DN numbers illegible because the
colors are similar.

Conditions:
88xx phones on version 12.0.1.SR1

Workaround:
Change the background image to one that allows the DNs to be distinguished.

Further Problem Description:
Enhancement request to allow more personalized changes on the phones.
Option 1:
The color should be selectable in the settings menu
Font Color:
Auto- Default
Black
White
Other?
This would allow Users to select any of the existing or custom Images on
the phone.

Option 2:
Toggle Font Boxes
Make this a selectable option in the phone

Option 3:
The Font has opposing color outline
White Font has black outline
Black font has White Outline

On Fri, Dec 15, 2017 at 10:38 AM, Haas, Neal  wrote:

> We are creating lighter backgrounds to resolve the not active line color.
> Also I just noticed no Text on the top of the screen!
>
>
>
> Thank You,
>
>
>
> Neal Haas
>
> NSE, Communications
>
> *Please report Troubles to the Help Desk. 559-600-5900 <(559)%20600-5900>*
>
> Telephone (559) 600-5890
>
>
>
> *From:* Bill Talley [mailto:btal...@gmail.com]
> *Sent:* Thursday, December 14, 2017 7:51 AM
>
> *To:* JASON BURWELL 
> *Cc:* Haas, Neal ; NateCCIE ;
> cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] 8800 Series firmware upgrade 12.0(1) text
> color
>
>
>
> Thanks for your feedback Jason.  I'll try a more solid background and will
> report back to the group with results.
>
>
>
> On Thu, Dec 14, 2017 at 9:47 AM, JASON BURWELL <
> jason.burw...@foundersfcu.com> wrote:
>
> Yes, dark wallpapers bring out plain white text for us. It’s been like
> this since upgrading off of I think FW11.5x or whatever version created an
> entire white block for each label which pretty much killed the wallpapers.
> We are using wallpaper that is mostly solid but a watermark of the company
> logo does appear under the text and it looks fine. None of our wallpapers
> use gradients though. Maybe that’s the issue, it having a problem
> interpreting and deciding what color text to use? This is on 8851 and 8865.
>
>
>
> Jason
>
>
>
> *From:* Bill Talley [mailto:btal...@gmail.com]
> *Sent:* Thursday, December 14, 2017 10:22 AM
>
>
> *To:* JASON BURWELL 
> *Cc:* Haas, Neal ; NateCCIE ;
> cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] 8800 Series firmware upgrade 12.0(1) text
> color
>
>
>
> So your dark backgrounds on 12.0.1SR1 have white text?   Are they solid
> backgrounds or gradients?  We had white text over the same background on
> firmware 11.7.1.17 but after upgrading to 12.0.1SR1 the text changed to
> gray.   Downgrading to 11.7.1.17 reverted text to white.  Using solely
> 8845s and CCM 11.5.1.SU3 on our end.
>
> Sent from a mobile device with very tiny touchscreen input keys. Please
> excude my typtos.
>
>
> On Dec 14, 2017, at 9:06 AM, JASON BURWELL 
> wrote:
>
> Not sure, I saw your picture and I have not had that issue anywhere on the
> 12x train. We have light and dark wallpapers. The Text for Speed
> Dials/Features changes automatically between Black and White color text
> depending on the wallpaper chosen so the text always clear and visible. I
> do recall an issue with text being seen back in 11.5 or 11.7 somewhere.
> I’ve been through a lot of ES releases prior to 12 so hard to remember.
>
>
>
>
>
> Jason
>
>
>
> *From:* Bill Talley [mailto:btal...@gmail.com ]
> *Sent:* Thursday, December 14, 2017 9:07 AM
> *To:* JASON BURWELL 
> *Cc:* Haas, Neal ; NateCCIE ;
> cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] 8800 Series firmware upgrade 12.0(1) text
> color
>
>
>
> Issue with display text still exists on SR1.  That’s what we were using.
>
> Sent from a mobile device with very tiny touchscreen input keys. Please
> excude my typtos.
>
>
> On Dec 14, 2017, at 7:24 AM, JASON BURWELL 
> wrote:
>
> I recommend loading the latest available firmware for the 8800 phones.
> Right now 12-0-1SR1-1 is available. In some cases I have had to request the
> latest ES form TAC. The 11.7x firmware has been some of the buggiest phone
> firmware I have seen for Cisco phones in the last 15 years. 12x seems to be
> much better than 11.7 but I am still getting issues with 

Re: [cisco-voip] IP Phones + MGCP FXS + Shared Lines

[Carlo via cisco-voip]

I have done it on 10.5. The only problem that has every happened was sometimes 
the calls would just ring the fxs port. I had to remove the line from the fxs 
port and re add it. I had several sites that had it. I also used it to flash a 
light so they would know the phone was ringing on a shop phone. 

Carlo

Sent from my iPhone

> On Dec 15, 2017, at 10:49 PM, Anthony Holloway 
>  wrote:
> 
> Does anyone have current information on whether or not MGCP FXS ports can be 
> on shared lines with Cisco IP Phones?
> 
> No anecdotal or empirical evidence please.  I'm looking for documented facts, 
> preferably the kind that doesn't require re-reading it like 10 times to come 
> up with your own interpretation.
> 
> Check out what the two Cisco Employees are saying in this thread from 2010 
> (Spoiler - It's not supported)
> 
> https://supportforums.cisco.com/t5/ip-telephony/shared-line-between-ip-phones-and-fxs-port-with-sccp-setup/td-p/1045431
> 
> Are you a Cisco employee who likes to stick your neck out for internet 
> strangers, and also believe this to be unsupported?  Please contact me.  Or 
> not.  I'm not crying.
> ___
> 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] UC server performance and UCCX agent in reserve

[Ryan Huff]

I cannot speak to Cisco’s implementation (if any Cisco CUCM devs are on here, 
feel free to chime in) however it’s been my experience as a programmer (long 
before I fell in love with UC) that tomcat, as a whole, is a rather leaky web 
server solution.

When I last studied and researched this topic heavily, it seemed to be many 
community’s opinion this was largely due to buffer (memory) management (or lack 
of efficient management thereof).

Personally, I’d love to see Cisco decouple phone services from tomcat and 
package a more kick-ass web server with CUCM specifically for phone services, 
like Apache. I’ve suggested dual web server processes for a long time (for more 
reasons than just phone services) but I’m just a voice in a sea of millions.

There is the old “trick” of tossing 2GB extra of RAM at each CUCM VM guest 
machine (if you can spare it). Generally speaking, it doesn’t solve the 
problem, but usually makes it less frequent.

At the very least, I would think in the modern mesh database versions of CUCM, 
phone services should be able to run on the subscribers. All that would likely 
take more re-architecting than I’m guessing Cisco is willing to invest in at 
this point.

To Charles’s point; predictive, scheduled tomcat restarts is the only way I’ve 
ever come to efficiently and effectively manage this when you have a cluster 
where tomcat is used heavily.

-Ryan

On Dec 16, 2017, at 11:59 AM, Matt Jacobson 
> wrote:

On the subject of tomcat performance and AXL requests, what is the recommended 
setup for TMS - CUCM integratio
​n?? I have seen AXL requests from TMS to overwhelm tomcat causing admin 
interface to be unresponsive or crash until tomcat is restarted.​

The TMS documentation is not specific about whether you add only one CUCM node 
or all nodes.
​I plan to test this when I get a chance, but if you add all nodes, does TMS 
load balance these requests or just spam all the nodes in the same manner?​

In the CUCM release notes it says this:

AXL Requests to Unified CM Nodes

If you run Cisco TelePresence Management Suite (TMS) for scheduling, then the 
node that you add it to sends multiple AXL queries to fetch endpoint 
information. Because of the load that TMS generates, we recommend that you do 
not configure other applications that use AXL (such as Cisco Emergency 
Responder or Cisco Unified Attendant Console) to send AXL requests to these 
nodes.


On Sat, Dec 16, 2017 at 10:50 Charles Goldsmith 
> wrote:
For us, we are restarting tomcat on the pub about once a week.  Our 
administrative interface is used pretty heavily with MACD stuff.  I've found 
that if we use one of the low utilization subs, we aren't having the issues.

We can't restart tomcat that easily due to EM usage, and yes, we have a 
dedicated pub.

On Sat, Dec 16, 2017 at 12:42 AM, Anthony Holloway 
> wrote:
Out of curiosity, how long had Tomcat been running before you restarted it?

This isn't at you Terry, but in general.

Companies will spend a lot of money getting systems in place, but then 
completely forget that technology has a life cycle; leading towards a better 
experience.  And no, I don't just mean upgrade to the latest shiny version.  I 
mean, efficiency, features, user experience, stability, scale, shorter MTTR.

Without being able to quantify it, I have seen more than a comfortable amount 
of environments without: a pre-production environment, proper analytics, proper 
change control, a good monitoring solution (emails from RTMT don't count), 
resource usage monitoring, a good backup strategy, vmtools up to date, and 
anything other than just MACD work being performed.

It's like there's this sole effort on "projects," and the old saying: "if isn't 
broke, don't fix it," wins again. We lose the chance to truly understand our 
systems, and therefore the chance to optimize them.

/rant

Disclaimer: Today was a long cutover, and I'm tired

PS Ryan amazes me too.


On Thu, Dec 14, 2017 at 10:32 PM Terry Oakley 
> wrote:

Thank you again Ryan.   I think I found the issue.   One of the tests showed a 
problem with AXL services.  Restarted Tomcat and we appear to be much better.





From: Terry Oakley
Sent: Thursday, December 14, 2017 5:29:31 PM
To: Ryan Huff

Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UC server performance and UCCX agent in reserve

Thanks Ryan.. .I will have a look tonight..


PS i don't know how you find all the time to respond to all of us but I am very 
thankful that you do.  


From: Ryan Huff >
Sent: Thursday, December 14, 2017 5:26:53 PM
To: Terry Oakley
Cc: 

Re: [cisco-voip] UC server performance and UCCX agent in reserve

[NateCCIE]

And that is why SAS is going to take over.  Systems management is easier to 
justify at larger scales. 

Sent from my iPhone

> On Dec 15, 2017, at 11:42 PM, Anthony Holloway 
>  wrote:
> 
> Out of curiosity, how long had Tomcat been running before you restarted it?
> 
> This isn't at you Terry, but in general.
> 
> Companies will spend a lot of money getting systems in place, but then 
> completely forget that technology has a life cycle; leading towards a better 
> experience.  And no, I don't just mean upgrade to the latest shiny version.  
> I mean, efficiency, features, user experience, stability, scale, shorter MTTR.
> 
> Without being able to quantify it, I have seen more than a comfortable amount 
> of environments without: a pre-production environment, proper analytics, 
> proper change control, a good monitoring solution (emails from RTMT don't 
> count), resource usage monitoring, a good backup strategy, vmtools up to 
> date, and anything other than just MACD work being performed.
> 
> It's like there's this sole effort on "projects," and the old saying: "if 
> isn't broke, don't fix it," wins again. We lose the chance to truly 
> understand our systems, and therefore the chance to optimize them.
> 
> /rant
> 
> Disclaimer: Today was a long cutover, and I'm tired
> 
> PS Ryan amazes me too.
> 
>> On Thu, Dec 14, 2017 at 10:32 PM Terry Oakley  wrote:
>> Thank you again Ryan.   I think I found the issue.   One of the tests showed 
>> a problem with AXL services.  Restarted Tomcat and we appear to be much 
>> better.
>> 
>>  
>> From: Terry Oakley
>> Sent: Thursday, December 14, 2017 5:29:31 PM
>> To: Ryan Huff
>> 
>> Cc: cisco-voip@puck.nether.net
>> Subject: Re: [cisco-voip] UC server performance and UCCX agent in reserve
>> Thanks Ryan.. .I will have a look tonight.. 
>> 
>> PS i don't know how you find all the time to respond to all of us but I am 
>> very thankful that you do.  
>> From: Ryan Huff 
>> Sent: Thursday, December 14, 2017 5:26:53 PM
>> To: Terry Oakley
>> Cc: cisco-voip@puck.nether.net
>> Subject: Re: [cisco-voip] UC server performance and UCCX agent in reserve
>>  
>> Just based on that description alone, I’d say it might be possible you have 
>> some LAN congestion? 
>> Everything you’re talking about here is riding http/https.
>> 
>> - Any recent QoS policy changes?
>> 
>> - Is other non-UC web traffic slower than normal from those PCs?
>> 
>> - Run utils diagnose test on the CLI of each server and see if you find any 
>> goodies ...
>> 
>> -Ryan
>> 
>> On Dec 14, 2017, at 7:18 PM, Terry Oakley  wrote:
>> 
>>> For the past week and a bit I have noticed a decline in UC (Call Manager) 
>>> response time when editing/adding a device.   The message 'loading' stays 
>>> on for 5 to 10 seconds or even longer.   Page refresh is also really slow.  
>>>  In looking at RTMT the CPU/Memory/disk space are all around 50% or less 
>>> with no apparent spikes.   Any suggestions on where this lag could be?
>>> 
>>> On another but may be related , a couple of our agents (but not all) both 
>>> have had their phones restart while in use, and today both had their agent 
>>> go into Reserved state for a couple of minutes before finally connecting 
>>> and allowing them service. Again any suggestions on where one would 
>>> look would be appreciated.
>>> 
>>> UC 11.5 SU3
>>> UCCX 11.5
>>> IMP 11.5 SU3
>>> O365
>>> Unity Connection 11.5
>>> 
>>> Terry
>>> 
>>> ___
>>> 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 mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] IP Phones + MGCP FXS + Shared Lines

[Lelio Fulgenzi]

Looks like the thread points you to sccp controlled fxs ports. I'm sure you 
have your reasons for wanting MGCP. Curious what those are.

Could you get away with ATAs?

Sent from my iPhone

On Dec 16, 2017, at 1:50 AM, Anthony Holloway 
> wrote:

Does anyone have current information on whether or not MGCP FXS ports can be on 
shared lines with Cisco IP Phones?

No anecdotal or empirical evidence please.  I'm looking for documented facts, 
preferably the kind that doesn't require re-reading it like 10 times to come up 
with your own interpretation.

Check out what the two Cisco Employees are saying in this thread from 2010 
(Spoiler - It's not supported)

https://supportforums.cisco.com/t5/ip-telephony/shared-line-between-ip-phones-and-fxs-port-with-sccp-setup/td-p/1045431

Are you a Cisco employee who likes to stick your neck out for internet 
strangers, and also believe this to be unsupported?  Please contact me.  Or 
not.  I'm not crying.
___
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] UC server performance and UCCX agent in reserve

[Matt Jacobson]

On the subject of tomcat performance and AXL requests, what is the
recommended setup for TMS - CUCM integratio
​n?? I have seen AXL requests from TMS to overwhelm tomcat causing admin
interface to be unresponsive or crash until tomcat is restarted.​

The TMS documentation is not specific about whether you add only one CUCM
node or all nodes.
​I plan to test this when I get a chance, but if you add all nodes, does
TMS load balance these requests or just spam all the nodes in the same
manner?​

In the CUCM release notes it says this:

AXL Requests to Unified CM Nodes

If you run Cisco TelePresence Management Suite (TMS) for scheduling, then
the node that you add it to sends multiple AXL queries to fetch endpoint
information. Because of the load that TMS generates, we recommend that you
do not configure other applications that use AXL (such as Cisco Emergency
Responder or Cisco Unified Attendant Console) to send AXL requests to these
nodes.


On Sat, Dec 16, 2017 at 10:50 Charles Goldsmith 
wrote:

> For us, we are restarting tomcat on the pub about once a week.  Our
> administrative interface is used pretty heavily with MACD stuff.  I've
> found that if we use one of the low utilization subs, we aren't having the
> issues.
>
> We can't restart tomcat that easily due to EM usage, and yes, we have a
> dedicated pub.
>
> On Sat, Dec 16, 2017 at 12:42 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Out of curiosity, how long had Tomcat been running before you restarted
>> it?
>>
>> This isn't at you Terry, but in general.
>>
>> Companies will spend a lot of money getting systems in place, but then
>> completely forget that technology has a life cycle; leading towards a
>> better experience.  And no, I don't just mean upgrade to the latest shiny
>> version.  I mean, efficiency, features, user experience, stability, scale,
>> shorter MTTR.
>>
>> Without being able to quantify it, I have seen more than a comfortable
>> amount of environments *without*: a pre-production environment, proper
>> analytics, proper change control, a good monitoring solution (emails from
>> RTMT don't count), resource usage monitoring, a good backup strategy,
>> vmtools up to date, and anything other than just MACD work being performed.
>>
>> It's like there's this sole effort on "projects," and the old saying: "if
>> isn't broke, don't fix it," wins again. We lose the chance to truly
>> understand our systems, and therefore the chance to optimize them.
>>
>> /rant
>>
>> *Disclaimer: Today was a long cutover, and I'm tired*
>>
>> PS Ryan amazes me too.
>>
>>
>> On Thu, Dec 14, 2017 at 10:32 PM Terry Oakley 
>> wrote:
>>
>>> Thank you again Ryan.   I think I found the issue.   One of the tests
>>> showed a problem with AXL services.  Restarted Tomcat and we appear to be
>>> much better.
>>>
>>>
>>>
>>> --
>>> *From:* Terry Oakley
>>> *Sent:* Thursday, December 14, 2017 5:29:31 PM
>>> *To:* Ryan Huff
>>>
>>> *Cc:* cisco-voip@puck.nether.net
>>> *Subject:* Re: [cisco-voip] UC server performance and UCCX agent in
>>> reserve
>>>
>>> Thanks Ryan.. .I will have a look tonight..
>>>
>>>
>>> PS i don't know how you find all the time to respond to all of us but I
>>> am very thankful that you do.  
>>> --
>>> *From:* Ryan Huff 
>>> *Sent:* Thursday, December 14, 2017 5:26:53 PM
>>> *To:* Terry Oakley
>>> *Cc:* cisco-voip@puck.nether.net
>>> *Subject:* Re: [cisco-voip] UC server performance and UCCX agent in
>>> reserve
>>>
>>> Just based on that description alone, I’d say it might be possible you
>>> have some LAN congestion?
>>> Everything you’re talking about here is riding http/https.
>>>
>>> - Any recent QoS policy changes?
>>>
>>> - Is other non-UC web traffic slower than normal from those PCs?
>>>
>>> - Run *utils diagnose test* on the CLI of each server and see if you
>>> find any goodies ...
>>>
>>> -Ryan
>>>
>>> On Dec 14, 2017, at 7:18 PM, Terry Oakley 
>>> wrote:
>>>
>>> For the past week and a bit I have noticed a decline in UC (Call
>>> Manager) response time when editing/adding a device.   The message
>>> 'loading' stays on for 5 to 10 seconds or even longer.   Page refresh is
>>> also really slow.   In looking at RTMT the CPU/Memory/disk space are all
>>> around 50% or less with no apparent spikes.   Any suggestions on where this
>>> lag could be?
>>>
>>>
>>> On another but may be related , a couple of our agents (but not all)
>>> both have had their phones restart while in use, and today both had their
>>> agent go into Reserved state for a couple of minutes before finally
>>> connecting and allowing them service. Again any suggestions on where
>>> one would look would be appreciated.
>>>
>>>
>>> UC 11.5 SU3
>>>
>>> UCCX 11.5
>>>
>>> IMP 11.5 SU3
>>>
>>> O365
>>>
>>> Unity Connection 11.5
>>>
>>>
>>> Terry
>>>
>>>
>>>