[cisco-voip] CUCM 6.0 Calling Search Space issue...

Fri Jun 19 04:45:38 EDT 2009

Ok i found something. when i looked at the partitions, i figured out that
there are 33 of them. I clicked one of the listed partitions which defined
as emergency calls, i selected time schedule that i created. And did the
test whether i can call emergency numbers or not. But no use. It did not
work out.

Let me describe the time schedule which i created. I am going to demonstrate
it as seen in CUCM.Name: test
Time of Day Start: typetimeofday.TIMEOFDAY_SLICE40
Time of Day End: typetimeofday.TIMEOFDAY_SLICE41
Repeat Every Week from TypeDayOfWeek.DAYOFWEEK_MON through
TypeDayOfWeek.DAYOFWEEK_SUN

I selected slice 40 (as i figured out 1 slice equals to 15mins.) as it
indicates that time is 10:00. I selected that because it's 11:00 o'clock in
here. After configuring time period , i selected this into the Time Schedule
option, and named it test_emergency_calls.

After creating Time schedule, i got into the partition which i mentioned
above, and selected the Time Schedule test_emergency_calls.

I could not find TURKEY in specific time list box so i selected the option
"originating device". Could it be the problem? Not selecting the appropriate
time zone??

In brief, i configured all the emergency calls to be able to performed
between 10:00 and 10:15 but did not work out. Besides i was searching the
cisco documentation and found a sentence which is a little weird.

"TOD settings comes into effect when the lines are included in a Hunt List.
The settings only apply to the Hunt Pilot and not to the lines within that
Hunt List. "

As i know hunt lists are imaginary DN's that combines pre-defined numbers of
DN's under one to form a pool. As a matter of fact, there isn't any
possibility that all used DN's could be in a Hunt list.

I am a little bit confused now...

Thanks in advance

CEM

On Thu, Jun 18, 2009 at 11:49 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>wrote:

>  I think you’re misunderstanding what people are suggesting with the
> time-based partitions.
>
>
>
> You are correct that “CSS contains partitions and partitions contains route
> patterns.” It is **those** partitions that you would apply the time-of-day
> routing to. The partition (or lack thereof) that the phones’ DNs are in has
> nothing to do with it.
>
>
>
> --
>
> Mike Norton
>
> I.T. Support
>
> Peace Wapiti School Division No. 76
>
> Helpdesk: 780-831-3080
>
> Direct: 780-831-3076
>
>
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *cem caglayan
> *Sent:* June-18-09 2:26 PM
> *To:* Chris Ward (chrward)
>
> *Cc:* cisco-voip Voip
> *Subject:* Re: [cisco-voip] CUCM 6.0 Calling Search Space issue...
>
>
>
> As i described, i could not find any other option except changing CSS. I'm
> not expert on this topic but as i figured out, CSS contains partitions and
> partitions contains route patterns. So if formulized in a cluster, the issue
> seems like this:
>
> CSS>partition>route pattern.
>
>
> So all of our phones' dial rules (route patterns in other words) are
> described into CSS which are selected in DN settings.
>
> I looked at Class of Control but i could not find anything.
>
> Let me explain my situation again, maybe there are some other ways to solve
> this issue.
>
> When our shift ends at work (it's about 18:30), i would like to block all
> the phones' outgoing calls except interior. In other words, after a
> specified time of day (let's call it 19:00), only interior calls have to be
> made. If you read my older posts, our phones are not in partitions, just CSS
> describes their calling ability. I'm going to put some pictures of the CM
> when i get back to work, maybe the issue could be understood easier.
>
> thanks in advance.
> CEM
>
>  On Thu, Jun 18, 2009 at 7:02 PM, Chris Ward (chrward) <chrward at cisco.com>
> wrote:
>
> I saw a response early in this thread that was not directly replied to.
> Why won't Time of Day routing fulfill your requirements?
>
> -Chris
>
>
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
> (rratliff)
> Sent: Thursday, June 18, 2009 11:40 AM
> To: cem caglayan
> Cc: cisco-voip Voip
> Subject: Re: [cisco-voip] CUCM 6.0 Calling Search Space issue...
>
> If you truly want to change all phones' CSS to None and back to their
> original value on a scheduled basis you would have to script this via
> AXL.  You would need to first discover all the lines and note their
> current CSS.  Then update all of those lines to use CSS None.  When
> it comes time to revert you change the CSS back to the value you
> discovered (and stored) originally.
>
> As Lelio said if you can provide more details about the policy you
> are trying to implement there is a very good chance it can be done in
> a way that doesn't require changing all of your phone configurations
> each night.
>
> -Ryan
>
> On Jun 18, 2009, at 8:51 AM, Lelio Fulgenzi wrote:
>
> I think you'll find yourself in a mess of trouble trying to do it by
> changing the calling search space. The timed based partitions is
> probably your best bet.
>
> Remember, the partition the phone is in has nothing to do with the
> partitions it can reach.
>
> Please explain your set up a bit more for us, and we'll try to help
> with suggestions using time based partitions. I haven't used them
> much, but it's fairly easy from what I recall.
>
> The one thing I always forget is when the <none> partition is
> searched. I can't remember if it is searched after all the other
> partitions only if no other match is found, or if it is searched in
> order and best match rules apply.
>
> For the long term sanity of your setup, I'd strongly suggest moving
> your DNs to a partition. It's easier to manage things like that.
>
> You'll also have to let us know what you are trying to block, access
> to phones or access to off-net? And what dial plan strategy are you
> using? allow with device and block with DN, or just allow with device?
>
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "Bad grammar makes me [sic]" - Tshirt
>
>
> ----- Original Message -----
> From: "Michael Back" <Michael.Back at nisd.net>
> To: "Daniel" <dan.voip at danofive.id.au>, "cem caglayan"
> <cem.caglayan at gmail.com>
> Cc: cisco-voip at puck.nether.net
> Sent: Thursday, June 18, 2009 8:27:11 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [cisco-voip] CUCM 6.0 Calling Search Space issue...
>
> You could try extension mobility.  Make sure the phone CSS is most
> restrictive, and put the appropriate CSS on the line like you are
> currently doing.  You can set a timer for Extension Mobility to log out
> after a specified period.
>
> MB
>
>  >>> cem caglayan <cem.caglayan at gmail.com> 6/18/2009 5:55 AM >>>
> First of all thanks for the tip Dan,
>
> The main problem is, we do not have any partitions which all the
> phones
> assigned to..
>
> Our dial rules are described in "Calling Search Spaces" which consist 4
> or
> more partitions. Besides, all the phones' Calling Search Spaces are
> setted
> into the directory number configuration. I've found how to change all
> the
> phones' Calling Search Spaces to the desired value under the "Bulk
> Administration>Phones>Add/Update Lines>Update Lines" section.
>
> But the main problem is, we have 3 PRI lines and 12 GSM lines connected
> to
> CM via PRI by 2N Stargate. And as i described, all the phones' Calling
> Search Spaces are not the same at all. For example my phone can call
> GSM and
> landlines, but my manager's can call international including my dial
> rule.
> My Calling Search Space is "Landlines and GSM" but my manager's
> "International Calls (which means everywhere can be called)".
>
> So in brief, the problem is when i set all these phones' calling
> search
> space to NONE on a scheduled job. How can i restore them to their
> original
> values??
>
> By the way i have found to backup all the phone settings under "Bulk
> Administration>Phones>Export Phones>All Details". But it stores the
> data in
> a TXT file. So i can not restore from that backup.
>
> Is there any way to fullfill according to my CUCM 6.0 profile???
>
> On Thu, Jun 18, 2009 at 9:46 AM, Daniel <dan.voip at danofive.id.au>
> wrote:
>
>  > Hi,
>  >
>  > Have you looked into time periods and schedules?
>  >
>  > Apply a time schedule to a partition to allow access only during a
> certain
>  > time period.
>  >
>  > cheers,
>  >
>  > Dan
>  >
>  > On Thu, Jun 18, 2009 at 4:16 PM, cem caglayan
> <cem.caglayan at gmail.com>wrote:
>  >
>  >> Hi all,
>  >>
>  >> I want to set some (about 300) users' calling search space to be set
> to
>  >> "none" after shift and bring them to their original values in the
>  >> morning,because of company policy. Is there any way to do this
> automatically
>  >> or can this action be scheduled? Because, as you know, it is very
> difficult
>  >> to set all these users' settings to desired one and bring them back
> to old
>  >> values. I looked at some features including Job scheduler and
> Enterprise
>  >> settings but no use.
>  >>
>  >>
>  >> Thanks in advance.
>  >>
>  >> Cem
>  >>
>  >> _______________________________________________
>  >> cisco-voip mailing list
>  >> cisco-voip at puck.nether.net
>  >> https://puck.nether.net/mailman/listinfo/cisco-voip
>  >>
>  >>
>  >
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090619/d267b4e6/attachment.html>