[cisco-voip] CUCM park behavior change

[Tim Frazee]

I agree.

but, one nice thing about the round robin approach was if you kept
re-parking the call, it kept the same park slot. sounds like that was just a
side-effect of how the code was.

so, is it safe to say that in CUCM 7.x and future that park slot allocation
will be top down instead of round robin? It would be nice to have a toggle
for this? (hell, theres toggles for everything else... :)

On Thu, Oct 8, 2009 at 9:31 AM, Wes Sisk <wsisk at cisco.com> wrote:

>  we've seen a few cases about this.  there was nothing in the original
> feature design that required the selection order.  When In Memory Database
> (IMDB) was implemented in CM7.x (woo hooo! less dependence on informix
> realtime access) the change in selection order was a byproduct.  As there
> was no previous requirement for selection order it was hard(impossible) to
> call this "breakage".
>
> /Wes
>
>
> On Thursday, October 08, 2009 9:17:26 AM, Tim Frazee <tfrazee at gmail.com><tfrazee at gmail.com>wrote:
>
> Group,
>
> I am running 7.1.2.31900 PUB/SUB setup and I noticed a difference in park
> behavior that I'm ok with, but curious as to why its different and how to
> change if I wanted to.
>
> As far as I can remember, when you parked a call and your park range was
> (for example) 702X, it would use a round-robin method of number allocation.
> It would always choose the next number in the range regardless of the state
> of the previous park numbers.
>
> Now the behaviour is top down. It chooses the first number in the range if
> its available. If I repark a call, it gets a different park slot than it had
> before This is different than I remember the all of Callmanager versions
> operation.
>
> ------------------------------
>
> _______________________________________________
> cisco-voip mailing listcisco-voip at puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091008/5be33735/attachment.html>