From: Godswill Oletu (oletu@inbox.lv)
Date: Wed Jan 02 2008 - 17:56:02 ARST
Thanks Mark, I got it.
Godswill Oletu
CCIE #16464 (R&S)
----- Original Message -----
From: "Mark Snow" <msnow@ipexpert.com>
To: "Godswill Oletu" <oletu@inbox.lv>
Cc: "Radioactive Frog" <pbhatkoti@gmail.com>; "Tarun Pahuja"
<pahujat@gmail.com>; "Avner Izhar" <aizhar@ccbootcamp.com>; "Cisco
certification" <ccielab@groupstudy.com>
Sent: Wednesday, January 02, 2008 2:36 PM
Subject: Re: Voice: CCM partition and css approach
> 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