04-18-2013 04:09 AM - edited 03-16-2019 04:52 PM
Hi All,
When Line and Device are in different CSS, how is the call handled? This is causing me a lot of confusion. I had an extension that couldn't make outgoing external calls. The Line CSS did not have the required partition, but the device CSS did. I thought they were concatenated together? If this the case, why would the person be unable to dial out if the Device CSS had a correct partition?
Thanks
04-18-2013 05:11 AM
Hello
Kindly be informed that you have twp options for CSS:
1-CSS on the line
or
2-CSS on the device
If you put CSS on your line , it will overwirte the CSS on the device , so the CSS of the device it will be useless. Be carefull for CSS you have to select which location you have to put your CSS , recommended the CSS for line.
Thank you
please rate if this will help
04-18-2013 05:14 AM
Islam,
Your statement is invalid, the CSSes get concatenated, this is very typical and recommended approach to use routing CSS at the device level and blocking CSS at the line. Again, well described in SRND.
HTH,
Chris
05-31-2016 12:52 AM
What happens when you don't have any CSS applied at Line level but CSS applied to Device only or vice-versa? Will you not be able to make or receive any calls if Line or Device is not taking precedence over one or the other? Also, how would this work in a Cross Cluster Extension Mobility Scenario if again one or the other doesn't have any CSS applied to them? Regards
05-31-2016 01:02 AM
If you don't have CSS applied at Line level but applied to Device only, then only Device CSS will be applicable and whether you can make any calls or not depends on the partitions accessed by respective device CSS. Same is applicable viceversa.
EMCC also carries the same concept except device CSS is configured under device profile viz EMCC CSS.
- Vivek
04-18-2013 05:12 AM
This is well described in SRND, the idea behind device/line approach is to use site specific wide open CSS at the device level and blocking CSS at the line level. This way for deployment with multiple locations you use one routing CSS per site and you build global blocking CSS that can be applied to all locations. The line CSS on phones have precedence over device CSS if there are exact patterns matched in both.
HTH,
Chris
04-18-2013 05:34 AM
Hi Chris,
Thanks again for the info.
Regarding my situation above. If the 2 are concatenated, what would be the reason for extensions external calls not working?
"The Line CSS did not have the required partition, but the device CSS did" - using the login above, shouldn't the call have routed?
Thanks
04-18-2013 05:48 AM
Perhaps there was a blocking pattern being matched, you can use Dialed Number Analyzer to see this.
Chris
04-18-2013 06:33 AM
Hi Guys,
Thanks for the info...
Still think I'm confused..
You say - Perhaps if there was a blocking pattern being matched.
If my Line CSS only allowed Internal Numbers, but the Device CSS allowed external, does this classify the Line CSS as "blocking external numbers"?
This is the understanding I currently have is -
1. "an external number is dialled" -
2. Line CSS has no matching partition for this (it only has internal dialling partition)
3. Device CSS DOES have a matching partition for External Calls.
The above was true in my situation, but for some reason the caller couldn't dial out?
04-25-2013 06:28 PM
Grant,
If my Line CSS only allowed Internal Numbers, but the Device CSS allowed external, does this classify the Line CSS as "blocking external numbers
I doubt strongly if this qualifies as line level blocking...Line level blocking comes into play when you use specific route patterns or xlation patterns to block certain patterns at the line level...
When I deploy Line/Dev model CSS..My DEV CSS has access to my PSTN partition..All patterns and my Line CSS has access only to the patterns I want to block...
So if my DEV CSS= CSS_PSTN_ALL
and CSS_PSTN_ALL= UK_PSTN
If my Lin CSS= Internal_CSS, then the final CSS on the device looks like this
Internal_CSS, CSS_PSTN_ALL
With this, this user has access to all PSTN numbers. There is no reason why the call should be blocked...Something else must be going on...
Out of curiosity I configured a test phone to use exactly your config and the user can dial all numbers.
LINE Level blocking comes into play when the CSS on the line matches a blocking pattern..because the CSS on the line takes priority over the DEV CSS, the blocked parttern is matched and call fails...
So please investigate further or take CUCM traces..I am keen to find out whats going on..
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
10-19-2018 07:27 AM
Chris' last sentence is what nailed it for me. I had a 9.! on the Line CSS blocked (I want no outbound calls on Line 2). But Line 2 was still able to call out because the Device CSS was more definitive( CSS Unrestricted).
I guess I will have to duplicate every pattern in CSS Unrestricted and block them all in (Internal Only Line 2 CSS).
Thanks Chris!
04-18-2013 06:00 AM
Hi Grant,
Here's the clip from the SRND that Chris nicely referenced (+5 Chris) and
the key principle that Chris described (TIE goes to the Line level CSS);
If the same route pattern appears in two partitions, one contained in the line's calling search space and one contained in the device's calling search space, then according to the r ules described in the section on
Partitions, Unified CM selects the route pattern listed first in the concatenated list of partitions (in this case, the route pattern associated with the line's calling search space).
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html#wp1044321
Guidelines for the Line/Device Approach
Consider the following guidelines when using the line/device approach:
•For this approach to work, the blocked patterns configured within the line calling search space must be at least as specific as the route patterns configured within the device calling search space. Wherever possible, Cisco recommends that you configure the blocked patterns as more specific than the routed ones, to avoid any possibility of error. Use extra care when dealing with the @ wildcard because the patterns defined within it are very specific.
•AAR is triggered when on-net DNs are dialed. Access to these DNs can be controlled by the same processes described previously. AAR uses a different calling search space for rerouted calls. In most cases, the AAR calling search space can be the same as the site-specific, unrestricted device calling search space because it can never be dialed directly by end users.
•Refer to the section on Call-Forward Calling Search Spaces, for guidance on using the line/device approach for Call Forward All actions.
From:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html#wp1150997
Cheers!
Rob
"Talk about a dream
Try to make it real"
- Springsteen
04-18-2013 06:08 AM
Hello
very usefull information , in all my life i only confiugure CSS on the line .
Many thanks Rob for these information
04-18-2013 06:37 AM
Islam,
So, how do you make things like extension mobility work to ensure it uses local GW, etc? traditional approach was to only use CSS at the device level, but I've never heard of anyone using just line level, there is a lots of caveats with that approach.
Chris
04-18-2013 07:11 AM
Hello Chris
You are completely true , what i need to say to attach phone with route pattern (i use CSS on the line ) for outgoing calls , many thanks for these information .
Thank you
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide