Re: [cisco-voip] RSVP for CAC

[Bernhard Albler]

Hi Dennis,
nails up the media, be careful with jabber bfcp sharing, this does not work for 
me with rsvp cac ( IOS should support BFCP over MTP in newer versions)
cheets
bernhard

--
Sent from a touchscreen device with impossibly small keys, please excuse any 
typos

> On 25 Sep 2014, at 04:20, Heim, Dennis  wrote:
> 
> Is anyone using RSVP for CAC? I know it uses a special MTP to make the RSVP 
> reservation. Does it actually nail up the call via this MTP or is it just 
> used to signaling?
>  
> Dennis Heim | Collaboration Solutions Architect
> World Wide Technology, Inc. | +1 314-212-1814
> 
> 
>  
>  
> ___
> 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] RSVP for CAC

[Heim, Dennis]

Is anyone using RSVP for CAC? I know it uses a special MTP to make the RSVP 
reservation. Does it actually nail up the call via this MTP or is it just used 
to signaling?

Dennis Heim | Collaboration Solutions Architect
World Wide Technology, Inc. | +1 314-212-1814
[cid:image001.png@01CFD845.84E7F1D0]
[cid:image002.png@01CFD845.84E7F1D0][cid:image003.png@01CFD845.84E7F1D0][cid:image004.png@01CFD845.84E7F1D0]


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

[cisco-voip] Local admin required for CUACA 10.5?

[Eric Pedersen]

I'm starting to test out attendant console advanced 10.5 and the client 
installer installs CUACA.exe to run as administrator. Are local admin 
privileges required now? We ran CUEAC 9 fine without local admin.

Also the admin guide has said for multiple versions that UAC needs to be 
disabled on computers running the client, although we've ran it fine with UAC 
enabled. Does anyone know what the reason is for this requirement?

Thanks,
Eric

The contents of this message may contain confidential and/or privileged 
subject matter. If this message has been received in error, please contact 
the sender and delete all copies. Like other forms of communication, 
e-mail communications may be vulnerable to interception by unauthorized 
parties. If you do not wish us to communicate with you by e-mail, please 
notify us at your earliest convenience. In the absence of such 
notification, your consent is assumed. Should you choose to allow us to 
communicate by e-mail, we will not take any additional security measures 
(such as encryption) unless specifically requested. 

If you no longer wish to receive commercial messages, you can unsubscribe 
by accessing this link:  http://www.bennettjones.com/unsubscribe

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

Re: [cisco-voip] Received Call Logs for CCX Agents showing CTI Port

[Tanner Ezell]

Anthony, you are correct. The CLID is an IPPA push to the agent handset
(which I might add could easily include an 'Answer' soft key..).

Regarding modifying the calling number. As Anthony mentions, this is
certainly possible as CER and other JTAPI based applications perform this
function. In fact, the UCCX does it as well as part of the Call Redirect
Step, though it modifies the original called number instead of the calling
number.

So the question, why does CER do this but UCCX doesn't?

With CER, the call is answered by CER and routed through a CTI Route Point
the PSAP.

With UCCX, the CTI Port initiates a controlled transfer (or consult
transfer) to the agent extension by the CTI Port. This is necessary to
ensure you don't deliver a call to an agent that doesn't answer within the
timer window.

The answer is in the difference, a CTI Route Point is required to modify
route information through the Cisco JTAPI RouteSession enhancement of the
selectRoute method. The selectRoute method from at least version 8 of CUCM
and possibly earlier has had the ability to modify the calling number, this
is certainly nothing new.

This explains how, but not why. The why is simple in my opinion, this would
require a dramatic change to the configuration and architecting (both JTAPI
wise and deployment wise) of the solution, as well as put additional load
on the CTI Manager service.

All that being said, I don't believe there is a reason this feature
couldn't make it in to the UCCX product from a technical perspective but I
wouldn't expect to see this feature implemented soon.

On Wed, Sep 24, 2014 at 12:02 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Thanks for the reference there Daniel, I had not seen that, though I had
> skimmed the 10.0 Release Notes when they came out.
>
> From the Release Notes:
>
> When the CLID screen pops up on the phone screen, the Answer key is hidden
>> below the CLID screen. You see two soft keys: Update and Exit. Press Exit
>> to see the Answer key.
>
>
> This sounds like the IPPA cData push via /CGI/Execute, and if my
> experiences with end users tells me anything, it's that you don't take over
> their phone display, because they become lost in a hurry.
>
> If CER can manipulate the Calling Number, why can't UCCX?  They're both
> CTI based applications.  Where's Tanner?  Tanner?
>
> On Wed, Sep 24, 2014 at 10:14 AM, Daniel Pagan  wrote:
>
>>  You might be referring to the CLI statement “utils uccx icd clid
>> enable”. It requires a restart of the UCCX Engine.
>>
>>
>>
>>
>> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_0/release/guide/UCCX_BK_RA1A036D_00_release-notes_release10.pdf
>>
>>
>>
>> - Dan
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>> Behalf Of *Matthew Loraditch
>> *Sent:* Wednesday, September 24, 2014 11:03 AM
>> *To:* cisco-voip@puck.nether.net
>> *Subject:* [cisco-voip] Received Call Logs for CCX Agents showing CTI
>> Port
>>
>>
>>
>> Instead of the actual CID info that shows up once the call is answered?
>>
>>
>>
>> I feel like I’ve encountered this before but can’t remember where or what
>> the heck setting to change.
>>
>>
>>
>>
>>
>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA
>>
>> 1965 Greenspring Drive
>> Timonium, MD 21093
>>
>> direct voice. 443.541.1518
>> fax.  410.252.9284
>>
>> Twitter   |  Facebook
>>   | Website
>>   |  Email Support
>> 
>>
>> Support Phone. 410.252.8830
>>
>>
>>
>>
>>
>> ___
>> 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] CUCM Apache logs

[Brian Meade]

It's in the localhost_access_log.txt file which is pulled down when you
download the access logs.  You can also watch in real-time:
file tail activelog tomcat/logs/localhost_access_log.txt

Or upload to an SFTP server:
file get activelog tomcat/logs/localhost_access_log.txt

Here's me going to the phone search page:
[24/Sep/2014:12:27:44 -0700] 10.100.75.10 10.100.75.10 admin - 443 GET
/ccmadmin/phoneFindList.do HTTP/1.1 200 84351 450

Hitting Find:
[24/Sep/2014:12:27:51 -0700] 10.100.75.10 10.100.75.10 admin - 443 POST
/ccmadmin/phoneFindList.do HTTP/1.1 200 167926 772

Selecting a device to edit:
[24/Sep/2014:12:27:54 -0700] 10.100.75.10 10.100.75.10 admin - 443 GET
/ccmadmin/gendeviceEdit.do HTTP/1.1 200 255460 1110

It won't show the parameters passed though such as the key which would show
the actual device ID.

Brian





On Wed, Sep 24, 2014 at 1:38 PM, Nilson Costa  wrote:

> Thank you for the answer Brian, but those logs (in CUCM 9 at least)
> doesn´t have the information I need.
>
> What I need is the session ID that every page generate, for example:
>
>  - On my company CUCM when I access the phone page (device >> Phone ) I
> have this adrress
> https://192.168.13.2:8443/ccmadmin/phoneFindList.do
> which is the session ID I accessed.
>
> When I access a phone the session Id is
>
> https://192.168.13.2:8443/ccmadmin/gendeviceEdit.do?key=92d69d4a-4a3a-0075-a666-ab2c84ad2523
> This is the information I need.
>
> Also I need to try to relate this information to the user that accessed
> that page. the audit logs provided by CUCM are not enough for that. They
> don´t have this session ID
>
> don´t know If I made me clear but if not let me know and I try to explain
> better
>
> 2014-09-24 14:29 GMT-03:00 Brian Meade :
>
> CUCM runs Tomcat, not Apache.  You can gather all the Tomcat-related logs
>> using RTMT->Trace&Log Central->Collect Files.
>>
>> On Wed, Sep 24, 2014 at 12:40 PM, Nilson Costa 
>> wrote:
>>
>>> Hello,
>>>
>>> I have a doubt, how can I collect the Apache logs on CUCM or the web
>>> session ID for each access user make an access on the system?
>>>
>>> Regards
>>>
>>> --
>>> Nilson Lino da Costa Junior
>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> --
> Nilson Lino da Costa Junior
>
> ___
> 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] Received Call Logs for CCX Agents showing CTI Port

[Anthony Holloway]

Thanks for the reference there Daniel, I had not seen that, though I had
skimmed the 10.0 Release Notes when they came out.

>From the Release Notes:

When the CLID screen pops up on the phone screen, the Answer key is hidden
> below the CLID screen. You see two soft keys: Update and Exit. Press Exit
> to see the Answer key.


This sounds like the IPPA cData push via /CGI/Execute, and if my
experiences with end users tells me anything, it's that you don't take over
their phone display, because they become lost in a hurry.

If CER can manipulate the Calling Number, why can't UCCX?  They're both CTI
based applications.  Where's Tanner?  Tanner?

On Wed, Sep 24, 2014 at 10:14 AM, Daniel Pagan  wrote:

>  You might be referring to the CLI statement “utils uccx icd clid
> enable”. It requires a restart of the UCCX Engine.
>
>
>
>
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_0/release/guide/UCCX_BK_RA1A036D_00_release-notes_release10.pdf
>
>
>
> - Dan
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Matthew Loraditch
> *Sent:* Wednesday, September 24, 2014 11:03 AM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] Received Call Logs for CCX Agents showing CTI Port
>
>
>
> Instead of the actual CID info that shows up once the call is answered?
>
>
>
> I feel like I’ve encountered this before but can’t remember where or what
> the heck setting to change.
>
>
>
>
>
> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA
>
> 1965 Greenspring Drive
> Timonium, MD 21093
>
> direct voice. 443.541.1518
> fax.  410.252.9284
>
> Twitter   |  Facebook
>   | Website
>   |  Email Support
> 
>
> Support Phone. 410.252.8830
>
>
>
>
>
> ___
> 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] Delete Log Files

[Martin Schmuker]

Thanks guys! You all helped me a lot!

From: Daniel Pagan [mailto:dpa...@fidelus.com]
Sent: Wednesday, September 24, 2014 5:23 PM
To: Jason Aarons (AM); Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: RE: [cisco-voip] Delete Log Files

There’s also this option ☺

If it’s specifically call routing information you need to remove, and there’s 
no need for retention of call routing information, Jason’s approach is the 
definitely easiest and makes the most sense. If removing call routing 
information is required, I would add to Jason’s recommendation that you also 
adjust the retention time for CDR records via Serviceability down from it’s 
default 30 days or simply disable it entirely via Service Parameters (CDR 
Enabled Flag).

From: Jason Aarons (AM) [mailto:jason.aar...@dimensiondata.com]
Sent: Wednesday, September 24, 2014 10:18 AM
To: Daniel Pagan; Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: RE: [cisco-voip] Delete Log Files

I would turn off all tracing and just turn it on when you get need it.  Are you 
really reading SDL traces files every week?


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, September 24, 2014 9:24 AM
To: Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files


If you absolutely can’t have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the “delete log files from the server” option is 
enabled.

This would provide you with two things:


1.   Log files collected off CUCM will be deleted permanently. This won’t 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.



2.   The log files you archive to a separate disk and, more importantly, 
the length of time they’re stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I’d also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM –  older version of CUCM 
don’t automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there’s that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it’s probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can’t really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it’s not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron’d ‘find’ command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d "within 1 day" -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
mailto:m...@bilobit.com>> wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

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

Re: [cisco-voip] CUCM Apache logs

[Nilson Costa]

Thank you for the answer Brian, but those logs (in CUCM 9 at least) doesn´t
have the information I need.

What I need is the session ID that every page generate, for example:

 - On my company CUCM when I access the phone page (device >> Phone ) I
have this adrress
https://192.168.13.2:8443/ccmadmin/phoneFindList.do
which is the session ID I accessed.

When I access a phone the session Id is
https://192.168.13.2:8443/ccmadmin/gendeviceEdit.do?key=92d69d4a-4a3a-0075-a666-ab2c84ad2523
This is the information I need.

Also I need to try to relate this information to the user that accessed
that page. the audit logs provided by CUCM are not enough for that. They
don´t have this session ID

don´t know If I made me clear but if not let me know and I try to explain
better

2014-09-24 14:29 GMT-03:00 Brian Meade :

> CUCM runs Tomcat, not Apache.  You can gather all the Tomcat-related logs
> using RTMT->Trace&Log Central->Collect Files.
>
> On Wed, Sep 24, 2014 at 12:40 PM, Nilson Costa 
> wrote:
>
>> Hello,
>>
>> I have a doubt, how can I collect the Apache logs on CUCM or the web
>> session ID for each access user make an access on the system?
>>
>> Regards
>>
>> --
>> Nilson Lino da Costa Junior
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>


-- 
Nilson Lino da Costa Junior
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Active Advisor for UC?

[Stephen Welsh]

Hi,
I suggest you have a look at PhoneView from UnifiedFX 
(http://www.unifiedfx.com), one of it’s key features is an Endpoint Assessment 
report that was written in collaboration with Akhil Behl (author of Securing 
Cisco IP Telephony networks - 
http://www.amazon.com/Securing-Telephony-Networks-Networking-Technology/dp/1587142953)

You can get a free copy of the free ITL Scanner, it does more than just check 
for bad ITL files:

http://www.unifiedfx.com/itl-scanner/

Also we recorded a series of webinars on Endpoint Security and Compliance with 
Akhil, you can view them here:

http://www.youtube.com/playlist?list=PLxsqZcpVKWYNTz77yhLTS7WW7w-7MB3kg

Kind Regards

Stephen Welsh, CCIE #12345
CTO
UnifiedFX


On 24 Sep 2014, at 15:58, Candese Perez 
mailto:trig...@gmail.com>> wrote:


Does anyone know of a product that will scan a UC environment (CUCM, UCCX, UC) 
for vulnerabilities, patches, EoX info etc. I am looking for something 
comparable to the Active Advisor product.

TIA

Candese
___
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] CUCM Apache logs

[Brian Meade]

CUCM runs Tomcat, not Apache.  You can gather all the Tomcat-related logs
using RTMT->Trace&Log Central->Collect Files.

On Wed, Sep 24, 2014 at 12:40 PM, Nilson Costa  wrote:

> Hello,
>
> I have a doubt, how can I collect the Apache logs on CUCM or the web
> session ID for each access user make an access on the system?
>
> Regards
>
> --
> Nilson Lino da Costa Junior
>
> ___
> 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] CUWL 10.x licenses

[Eric Pedersen]

That's crazy. ELM was such a good step to get a handle on licensing and now 
Cisco makes upgrades require manual intervention on their part?!? I could 
understand 8 to 9 since the licensing model changed but I figured 9 to 10 would 
be straightforward.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: 24 September 2014 6:41 AM
To: Brian Meade; Steve Rubin
Cc: cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUWL 10.x licenses

I’m going on 4 weeks average, never right the first time.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Tuesday, September 23, 2014 3:12 PM
To: Steve Rubin
Cc: cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUWL 10.x licenses


Yea,  I've heard they've been really swamped lately since licensing has to get 
a PM involved for every single one.  Lead times are 2-3 weeks on average right 
now.

On Tue, Sep 23, 2014 at 1:24 PM, Steve Rubin 
mailto:s...@layer42.net>> wrote:
From: Eric Pedersen 
mailto:peders...@bennettjones.com>>
Date: Monday, September 22, 2014 at 2:12 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>, 
cisco-voip mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] CUWL 10.x licenses

Interesting that Cisco switched to a manual process. I opened an SR and the guy 
from Licensing said I should contact "The Product Manager" whatever that means. 
Good thing I get 60 days to sort this out ☺


Start early.  My 9.x->10.x license case was 3 weeks old before it was dealt 
with.  Also double check your license counts when you get it back, mine was 
short.


--
Steve Rubin  
s...@layer42.net
Layer42 Networks   
http://www.layer42.net/


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



itevomcid

The contents of this message may contain confidential and/or privileged 
subject matter. If this message has been received in error, please contact 
the sender and delete all copies. Like other forms of communication, 
e-mail communications may be vulnerable to interception by unauthorized 
parties. If you do not wish us to communicate with you by e-mail, please 
notify us at your earliest convenience. In the absence of such 
notification, your consent is assumed. Should you choose to allow us to 
communicate by e-mail, we will not take any additional security measures 
(such as encryption) unless specifically requested. 

If you no longer wish to receive commercial messages, you can unsubscribe 
by accessing this link:  http://www.bennettjones.com/unsubscribe

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

[cisco-voip] CUCM Apache logs

[Nilson Costa]

Hello,

I have a doubt, how can I collect the Apache logs on CUCM or the web
session ID for each access user make an access on the system?

Regards

-- 
Nilson Lino da Costa Junior
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Active Advisor for UC?

[Candese Perez]

Does anyone know of a product that will scan a UC environment (CUCM, UCCX,
UC) for vulnerabilities, patches, EoX info etc. I am looking for something
comparable to the Active Advisor product.

TIA

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

Re: [cisco-voip] Delete Log Files

[Wes Sisk (wsisk)]

+1 on what Daniel said.

Scheduled trace collection with delete is the only way I can currently think of 
to do this out of the box. Some files, like install logs have long term value, 
not sure what your retention options are for those?

* It is possible to automate an ssh/CLI login and file manipulation, but the 
CLI find/delete doesn’t allow identification by data AFAIK
* We have long requested CSCsi21579allow scheduling commands  but still 
waiting. Maybe hit up your account team on this one.
* Setting a reduced number of files or file size will not guarantee < 7 days. 
That is always dependent on system utilization, traces configured, and the 
amount of tracing generated by the features used.
* RTMT serviceability API’s, which do file retrieval and delete, are now 
public: 
https://developer.cisco.com/site/collaboration/management/uc-manager-serviceability/develop-and-test/documentation/latest-version/
 . Retrieval includes delete option for RTMT. I don’t see it in the API, 
checking into that.

-Wes

On Sep 24, 2014, at 9:24 AM, Daniel Pagan 
mailto:dpa...@fidelus.com>> wrote:

If you absolutely can’t have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the “delete log files from the server” option is 
enabled.

This would provide you with two things:

1.   Log files collected off CUCM will be deleted permanently. This won’t 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.

2.   The log files you archive to a separate disk and, more importantly, 
the length of time they’re stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I’d also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM –  older version of CUCM 
don’t automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there’s that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it’s probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can’t really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it’s not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron’d ‘find’ command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d "within 1 day" -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
mailto:m...@bilobit.com>> wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

Thanks,  Martin
___
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] Delete Log Files

[Daniel Pagan]

There’s also this option ☺

If it’s specifically call routing information you need to remove, and there’s 
no need for retention of call routing information, Jason’s approach is the 
definitely easiest and makes the most sense. If removing call routing 
information is required, I would add to Jason’s recommendation that you also 
adjust the retention time for CDR records via Serviceability down from it’s 
default 30 days or simply disable it entirely via Service Parameters (CDR 
Enabled Flag).

From: Jason Aarons (AM) [mailto:jason.aar...@dimensiondata.com]
Sent: Wednesday, September 24, 2014 10:18 AM
To: Daniel Pagan; Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: RE: [cisco-voip] Delete Log Files

I would turn off all tracing and just turn it on when you get need it.  Are you 
really reading SDL traces files every week?


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, September 24, 2014 9:24 AM
To: Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files


If you absolutely can’t have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the “delete log files from the server” option is 
enabled.

This would provide you with two things:


1.   Log files collected off CUCM will be deleted permanently. This won’t 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.



2.   The log files you archive to a separate disk and, more importantly, 
the length of time they’re stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I’d also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM –  older version of CUCM 
don’t automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there’s that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it’s probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can’t really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it’s not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron’d ‘find’ command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d "within 1 day" -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
mailto:m...@bilobit.com>> wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

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



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

Re: [cisco-voip] Received Call Logs for CCX Agents showing CTI Port

[Daniel Pagan]

You might be referring to the CLI statement "utils uccx icd clid enable". It 
requires a restart of the UCCX Engine.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_0/release/guide/UCCX_BK_RA1A036D_00_release-notes_release10.pdf

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Loraditch
Sent: Wednesday, September 24, 2014 11:03 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Received Call Logs for CCX Agents showing CTI Port

Instead of the actual CID info that shows up once the call is answered?

I feel like I've encountered this before but can't remember where or what the 
heck setting to change.


Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA
1965 Greenspring Drive
Timonium, MD 21093

direct voice. 443.541.1518
fax.  410.252.9284

Twitter  |  
Facebook  | 
Website  |  Email 
Support
Support Phone. 410.252.8830




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

[cisco-voip] Received Call Logs for CCX Agents showing CTI Port

[Matthew Loraditch]

Instead of the actual CID info that shows up once the call is answered?

I feel like I've encountered this before but can't remember where or what the 
heck setting to change.


Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA
1965 Greenspring Drive
Timonium, MD 21093

direct voice. 443.541.1518
fax.  410.252.9284

Twitter  |  
Facebook  | 
Website  |  Email 
Support
Support Phone. 410.252.8830


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

Re: [cisco-voip] Delete Log Files

[Jason Aarons (AM)]

I would turn off all tracing and just turn it on when you get need it.  Are you 
really reading SDL traces files every week?


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, September 24, 2014 9:24 AM
To: Martin Schmuker; Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files


If you absolutely can’t have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the “delete log files from the server” option is 
enabled.

This would provide you with two things:


1.   Log files collected off CUCM will be deleted permanently. This won’t 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.



2.   The log files you archive to a separate disk and, more importantly, 
the length of time they’re stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I’d also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM –  older version of CUCM 
don’t automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there’s that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it’s probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can’t really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it’s not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron’d ‘find’ command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d "within 1 day" -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
mailto:m...@bilobit.com>> wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

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



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

[cisco-voip] ISDN 5ESS NFAS

[Heim, Dennis]

Has anyone done NFAS with ISDN 5ESS Switch?

I have seen  some Cisco docs like this 
(http://www.2mul.com/c/en/us/td/docs/ios/voice/isdn/configuration/guide/15_1/vi_15_1_book.pdf).
 That seems to say it is supported..

Switch Type: Lucent 5ESS
NFAS Type: Custom; does not support NFAS

Switch Type: Lucent 5ESS
NFAS Type: NI-2 NFAS


But found this old DOC from that 2005 
(http://www.cisco.com/c/en/us/support/docs/dial-access/integrated-services-digital-networks-isdn-channel-associated-signaling-cas/9584-quadt1-nfas.html#req)
 that says its not.


Dennis Heim | Collaboration Solutions Architect
World Wide Technology, Inc. | +1 314-212-1814
[cid:image001.png@01CFD7D9.F51801A0]
[cid:image002.png@01CFD7D9.F51801A0][cid:image003.png@01CFD7D9.F51801A0][cid:image004.png@01CFD7D9.F51801A0]


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

Re: [cisco-voip] Delete Log Files

[Daniel Pagan]

If you absolutely can't have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the "delete log files from the server" option is 
enabled.

This would provide you with two things:


1.   Log files collected off CUCM will be deleted permanently. This won't 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.



2.   The log files you archive to a separate disk and, more importantly, 
the length of time they're stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I'd also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM -  older version of CUCM 
don't automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there's that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it's probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can't really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it's not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron'd 'find' command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d "within 1 day" -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
mailto:m...@bilobit.com>> wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

Thanks,  Martin
___
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] CUWL 10.x licenses

[Jason Aarons (AM)]

I’m going on 4 weeks average, never right the first time.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Tuesday, September 23, 2014 3:12 PM
To: Steve Rubin
Cc: cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUWL 10.x licenses


Yea,  I've heard they've been really swamped lately since licensing has to get 
a PM involved for every single one.  Lead times are 2-3 weeks on average right 
now.

On Tue, Sep 23, 2014 at 1:24 PM, Steve Rubin 
mailto:s...@layer42.net>> wrote:
From: Eric Pedersen 
mailto:peders...@bennettjones.com>>
Date: Monday, September 22, 2014 at 2:12 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>, 
cisco-voip mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] CUWL 10.x licenses

Interesting that Cisco switched to a manual process. I opened an SR and the guy 
from Licensing said I should contact "The Product Manager" whatever that means. 
Good thing I get 60 days to sort this out ☺


Start early.  My 9.x->10.x license case was 3 weeks old before it was dealt 
with.  Also double check your license counts when you get it back, mine was 
short.


--
Steve Rubin  
s...@layer42.net
Layer42 Networks   
http://www.layer42.net/


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



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