[cisco-voip] CUCM park behavior change

[Wes Sisk]

Anything is possible with sufficient motivation.  Currently I am not 
aware of any planned changes.

/Wes

On Thursday, October 08, 2009 4:37:07 PM, Tim Frazee <tfrazee at gmail.com> 
wrote:
> 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 
> <mailto: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> <mailto: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 list
>>     cisco-voip at puck.nether.net <mailto: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/20091008/b23958a8/attachment.html>