From: Godswill Oletu (oletu@inbox.lv)
Date: Wed Jan 02 2008 - 17:08:14 ARST
Hi Guys,
Before we take this topic to the archives, can someone explain what the
traditional method of applying CSS is?
Or are you referring to applying the CSS at the device level as the
traditional method & applying it both at the device
& line level for a more granular effect as the other method?
In one of Tarun's replies he stated and I quote in part...
"....You could apply more restrictive policy on the device level with the
line level having less restrictive policy and vise versa."
The vice versa part is not resonating well with me; because my understanding
is that the line & device level CSS are combine together
to form an expanded list of partitions that the DN can reach and as such one
cannot restrict access to a partition on the Line level if that same access
have been granted by the CSS at the device level.
However, one can be more restrictive at the device level CSS and anything
added at the line level CSS will be prepended to the top of the partitions
contained in the device level CSS to form this expanded list of partitions
that the DN will be able to reach.
Thanks.
Godswill Oletu
CCIE #16464 (R&S)
----- Original Message -----
From: "Mark Snow" <msnow@ipexpert.com>
To: "Radioactive Frog" <pbhatkoti@gmail.com>
Cc: "Avner Izhar" <aizhar@ccbootcamp.com>; "Cisco certification"
<ccielab@groupstudy.com>
Sent: Wednesday, January 02, 2008 12:32 PM
Subject: Re: Voice: CCM partition and css approach
> Hey Frog,
>
> As Avner accurately mentioned - it is very important to know both
> methods - since you never know what requirements you may be given.
> Traditional is a bit easier to use - and might be a better candidate for
> using in the lab if not given any other requirements that force you to
> use the Line/Device
> However seeing that the line/device approach is much more powerful - you
> should also know this concept well in case you need to use it.
>
> Keep in mind that you have the CCM SRND on your candidate desktop in the
> lab - so know it well.
> If you only studied the Line/Device approach marginally, but had a
> requirement to use it in the lab - you have it all available to you to
> refresh from in the CCM SRND on pages 344-351.
>
> An example of a requirement would be one like that described in the CCM
> SRND:
> "When using the Extension Mobility feature, the line/device approach
> provides a natural way to implement the dialing restrictions of a phone
> as a function of the logged-in status of the phone."
> In other words - you keep your calling restrictions - but your CoR is now
> applied so that when logged into a phone at a remote site (across the
> wan) your call goes out your new local gateway - instead of across the
> wan back to your 'home' site and out that gateway.
> In real life this is very important mainly for Emergency Services calls -
> where PSAPs aren't even remotely close to being connected to each other -
> and and your ANI / ALI information would return the wrong site address if
> not going out the proper gateway. Not to mention significantly reducing
> wan bandwidth usage.
>
>
> Do also bear in mind that there are caveats and considerations that need
> to be taken into account and they are described in the SRND in the pages
> given - namely that:
>
> "When the Forward All calling search space is left as <None>, the results
> are difficult to predict and depend on the Cisco CallManager release.
> Therefore, Cisco recommends the following best practices when configuring
> call-forward calling search spaces ... Always provision the call-forward
> calling search spaces with a value other than <None>. This practice
> avoids confusion and facilitates troubleshooting because it enables the
> network administrator to know exactly which calling search space is being
> used for forwarded calls."
> AND
> "Prior to Cisco CallManager Release 3.1, the concatenation was performed
> in the reverse order, and the device's calling search space came first,
> followed by the line's calling search space. This reverse behavior is
> still adopted by CTI ports and CTI route groups. "
>
>
> I suppose when Avner said that:
> "Guess the vendors workbooks were written by folks who learned it before
> there was a partition field under the line ;)"
> ... he was referring to CallManager 2.4 - before the 3.0 release.
> While Vik and I both were working with CallManager back then before Cisco
> had acquired Selsius Systems - I'm not sure how that is relevant to the
> lab since they never tested any UCM version before 3.3.
> *shrug*
> We have mostly kept to this based on it's simplicity and getting folks to
> understand the basics before moving onto more complicated scenarios.
> Though come to any ILT bootcamp we have hold and see that we vigorously
> rehearse both of them - Avner should remember this from the class he took
> from me in Dallas before getting his IE.
>
>
> Cheers and Happy 2008 Frog!
>
> Mark Snow
> CCIE #14073 (Voice, Security)
> CCSI #31583
> Senior Technical Instructor - IPexpert, Inc.
> A Cisco Learning Partner - We Accept Learning Credits!
> Telephone: +1.810.326.1444
> Fax: +1.309.413.4097
> Mailto: msnow@ipexpert.com
>
> IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On
> Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab,
> CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE
> Storage Lab Certifications.
>
>
> On Jan 2, 2008, at 6:19 AM, Radioactive Frog wrote:
>
>> Thanks Avner.
>> i'll strict to one for exam purpose - traditional and will study
>> line/device
>> for real life scenario.
>>
>> frog
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:57 ARST