I'm using Line/Device calling search spaces and understand the need and purpose of the secondary forwarding CSS (at least I thought I did). What I was not aware was that the forward busy and no answer would not use the combined search spaces. Is this correct or is there a setting somewhere that I'm missing? If I have to create a new CSS for forward busy and no answer anyways, what is the benefit of using the secondary search space?
Under calling search space for forward options; keep "Use system default" option selected and then assign the appropriate CSS to forward busy and no answer option with correct number given under destination field.
Thanks for the reply. Maybe I'm not understanding your response. I want to be able to use the secondary CSS and the forwarding CSS to give me a combined forwarding CSS for forward busy and no answer. I need this CSS to be different from the line CSS and I do not want to have to create a new forwarding CSS.
I don't necessarily need different CSS's for forward all and forward busy. Maybe I'm not verbalizing this correctly.
Calling Search Space Activation Policy With Configured CSS
Forward All CSS Internal only CSS (blocking)
Secondary Calling Search Space for Forward All Device Level CSS (allow)
Forward Busy Internal only CSS (blocking)
Forward No Answer Internal only CSS (blocking)
My Device level CSS allows all patterns.
My Internal only CSS contains only blocking patterns.
Call forward all CSS works fine as my Device and Internal only CSS's combine to give me an effective CSS. For forward busy and no answer, it appears to be only using the Internal only CSS which only contains blocking patterns/partitions. I assume this is because Call Manager is not combining the Secondary forwarding CSS (device level) with the forward busy or no answer CSS.
I can create new CSS's that are not blocking for my forward busy and no answer, but that defeats the purpose of having the secondary forwarding CSS and I might as well use those CSS's for forward all as well.
This setting is only used for CFWDALL scenarios and not forward busy/no answer.
Your explanation above for your cfwdall is a bit wrong. The device CSS does not come into play during cfwdall at all. Its either the configured css for cfwdall or a combination of secondary CSS and configured cfwdall css..
When you forward calls by using the CFwdAll softkey on the phone, the automatic combination of the line CSS and device CSS does not get used. Only the configured Primary CFA CSS and Secondary CFA CSS get used.
Hope this clarifies it for you. I usually configure my Cfwd CSS to mimic the combination of my dev/line css so that my CoR is maintatined for each user.
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
Thanks for the reply. I understand that the device level CSS is not used for forwarding. It just so happens that in my case, for forwarding, I'm using the same CSS that I use on the device (for allow patterns) combined with a blocking CSS. This only works for forward all situations and not for busy and no answer. Why Cisco would only allow this to be applied to the forward all is beyond me. In my opinion, that defeats the purpose of having the ability to use the secondary forwarding CSS. Just wanted to make sure I wasn't missing something.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...