[cisco-voip] Multiple subscriber phone load balancing - interesting

[FrogOnDSCP46EF]

dis-regard my previous post... I found my tail :)

This solution won't work and its not registration fail mechanism. Its the
keep alive mechanism between endpoint and servers listed in CCM-group.

Thanks WES.


On Wed, Jan 28, 2009 at 1:32 AM, FrogOnDSCP46EF <ciscoboy2006 at gmail.com>wrote:

> Hi WES,
>
> Have you guys labbed this up?
>
> Just curious - How does CCM_group verifies that primary server in call
> manager group has failed? - does it use "ICMP /ping" probes or some other
> method e.g. SCCP signaling?
>
> - so if it uses ping probe, on sccp registration fail on first server (due
> to reached max limit) it wont' switch over to B coz serverA still reacheble
> - if it uses some other 'intellegent' method, then its possible it will
> switch over to server B.
>
>
>
>
> On Tue, Jan 27, 2009 at 2:11 AM, Wes Sisk <wsisk at cisco.com> wrote:
>
>>  sub1 will reject the registration. unfortunately the rejection happens a
>> manner such that all phones do not simply try the next available cm.
>>
>> this is not covered in the SRND as it is not part of any valid design.
>>
>> /wes
>>
>>
>> On Monday, January 26, 2009 9:37:06 AM, FrogOnDSCP46EF
>> <ciscoboy2006 at gmail.com> <ciscoboy2006 at gmail.com> wrote:
>>
>> Hi WES,
>> thanks for the reply.
>> CM group will only do static load balancing (its pretty traditional way).
>> I was thinking to achieve same thing but in dynamic way.
>>
>> you said: "once that parameter is exceeded CM simply rejects registration
>> request"
>>
>> Does that mean once 500 phones are connected to Sub1. The 501th phone
>> which is rejected on Sub1 will connect next sub in the same CM group e.g.
>> sub2 ?
>>
>> Thats what I want to know..?
>>
>> Agreed, there will be many other virtual devices, cti rp etc in the
>> equation. But if above is true, then its dynamic load balancing....
>>
>> I can't find anything about this in the SRND.
>>
>>
>>
>> On Tue, Jan 27, 2009 at 12:36 AM, Wes Sisk <wsisk at cisco.com> wrote:
>>
>>> You don't want to do it that way.  Use CM Groups to do load balancing.
>>>  once that parameter is exceeded CM simply rejects registration
>>> requests.  That parameter has some interesting history as well where route
>>> lists, hunt lists, built in bridge devices from ip phones, and other random
>>> software / virtual devices are counted.
>>>
>>>  /Wes
>>>
>>>   On Jan 26, 2009, at 3:02 AM, FrogOnDSCP46EF wrote:
>>>
>>>
>>> Holiday today, just sitting at home on the couch with a glass of red
>>> wine.  I was doing nothing so I started flocking through CCM 6x parameters.
>>>
>>> A parameter which drew my attention was "Maximum number of register
>>> device" in call manager service parameter.
>>>
>>> I am trying to figure out the best way to load balance IP phone
>>> registration to all subscribers.
>>>
>>> Sales department has 1500 IP phones.
>>>
>>> I have 3 subscribers - Sub1, sub2, sub3
>>> Call manager group = sales_cm-group = Sub1, Sub2, Sub3
>>>
>>> Device pool for Sales department:   "DP_Sales" = sales_cm-group
>>> (sub1,sub2,sub3)
>>>
>>> If I have set 'max number of register device' = 400 in each subscriber's
>>> service parameter.
>>> How would it behave?
>>>
>>> Just talking to myself:
>>>
>>> 1. First 500 phones will register to Sub1.
>>> 2. Then next lot, 501 to 1000 phones will register to Sub2. This is bcoz
>>> Sub1 has reached its limit of 500. So Phone#501 will try to register to
>>> second subscriber #sub2 (hunting through list).
>>>
>>> 3. Then following Sub3 will register 1001 to 1500 coz sub1 and sub2 has
>>> reached their limits.
>>>
>>> If it works, this could be a good way to do load-balancing. Am I right?
>>>
>>> -frog
>>>
>>>
>>>   *Maximum Number of Registered Devices:* [image: Required Field]  This
>>> parameter specifies the maximum number of devices that can register with
>>> Cisco CallManager and is used to limit the overall resource demand. Devices
>>> that count toward this limit include: Annunciator devices, H.323
>>> gatekeepers, H.323 phones, H.323 gateways, ICT trunks (gatekeeper or
>>> non-gatekeeper-controlled), MGCP CAS trunks, MGCP gateways, MGCP FXS ports
>>> (analog ports), MGCP FXO ports, MGCP T1/E1 PRI, media termination points
>>> (hardware or software), transcoders, Music on Hold servers (not MOH audio
>>> sources), SIP trunks, IP phones, conference bridge devices (hardware or
>>> software), legacy Skinny Gateway Control Protocol devices like Cisco Analog
>>> Access, and video conference bridges (IP/VC 3540 configured with Skinny
>>> Client Control Protocol [SCCP] port). The following devices are NOT counted
>>> toward this limit: line appearances (directory numbers), route lists and
>>> built in bridges.      This is a required field.      Default:  5000
>>>  Minimum:  5000      Maximum:  15000
>>>
>>> --
>>> Smile, you'll save someone else's day!
>>> Frog
>>>  _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> Smile, you'll save someone else's day!
>> Frog
>>
>>
>>
>
>
> --
> Smile, you'll save someone else's day!
> Frog
>



-- 
Smile, you'll save someone else's day!
Frog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090128/b9d6d34b/attachment.html>