From: Mark Snow (msnow@ipexpert.com)
Date: Wed Jan 02 2008 - 17:36:04 ARST
Hi Godswill,
Yes - I think you have it:
Traditional is setting up your Classes of Restriction (Often 4
Classes: Restricted, Local, Long Distance, and International calling)
with CSS and those CSSs contain PTs in which lie Route Patterns that
point to specific RL/RG/GW most often for a specific site. So you get
Site Specific Call Routing along with the desired Class of Restriction
- and yes - you apply that CSS at only the Device level.
The Line Device Approach has you setting up 1 CSS that allows access
to everything (in terms of Restricted, Local, Long Distance, and
International calling) and points only to the PT/RP/RL/RG/GW combo I
mentioned above but for 1 specific site - (and then of course you set
1 of those CSSs up for each site you have) and apply that CSS to the
Device (assuming it won't move between sites - that would require 4.2
and Device Mobility - but I digress...).
Then you setup the 4 CSSs for Class of Restriction - (and only 4
regardless of how many sites you have) - and you don't put any PTs
with 'allow' Route Patterns in that CSS - you ONLY put Blocking Route
Patterns:
- for International calling rights - CSS with maybe an Internal PT -
but no blocking or otherwise PSTN PTs
- for Long Distance calling rights - CSS with an International
Blocking RP in a PT in the CSS
- for Local calling rights - CSS with an International Blocking RP/PT
and a Long Distance Blocking RP/PT in the CSS
- for Restricted calling rights - CSS with an International Blocking
RP/PT, a Long Distance Blocking RP/PT, and a Local Blocking RP/PT in
the CSS (still allowing things like Internal PT and a 911PT)
Then knowing, as you mentioned, that the Line PTs (which are blocking)
are put first over the Device PTs (which are allowing everything and
pointing to the site specific GW) in the Concatenated CSS - that your
call will both have the proper CoR and also go to the proper site GW -
even when using things like Extension Mobility.
Again, do read the UCM SRND pages 344-351 (at a minimum) and bear in
mind the caveats and considerations I mentioned below.
HTH!
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 12:08 PM, Godswill Oletu wrote:
> 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