[asterisk-dev] device_state distribution issues

Klaus Darilion klaus.mailinglists at pernau.at
Tue Nov 9 10:00:16 CST 2010



Am 09.11.2010 16:31, schrieb Olle E. Johansson:
>
> 9 nov 2010 kl. 16.26 skrev Russell Bryant:
>
>> On Tue, 2010-11-09 at 11:14 +0100, Klaus Darilion wrote:
>>> btw: has someone ever did any performance measuring of devicestate
>>> distribution? I would suspect ais to have much better performance as it
>>> avoids the additional hop of the XMPP server, avoids XML
>>> encoding/parsing and is sent by multicast (good for multiple servers as
>>> it avoids the sequential XMPP ntofications). Thus, for LAN environments
>>> I think ais is much better suited than XMPP.
>>>
>>> So, what is now the purpose of res_ais vs. res_jabber?
>>>
>>> I think the goal of device state distribution with XMPP is to have
>>> synchronize the device state over between geographically distributed
>>> servers (e.g. main office and branch offices) not for having multiple
>>> Asterisk servers for load balancing.
>>>
>>> AIS based state distribution seems very lightweight. Thus, in high
>>> traffic environments where a single server can not handle all the load
>>> (lots of idle traffic due to REGISTER and OPTIONS, transcoding ...) it
>>> allows you to have an Asterisk cluster with one aggregated device state
>>> for each device over the whole cluster. Of course at some point if there
>>> are many nodes and too many state changes then the cluster may collapse
>>> due to the immense ais traffic, but I think state changes are usually
>>> not that much (mostly only when a call is created and hangup) compared
>>> to other load (RTP, idle traffic) and so I think a cluster of 10 servers
>>> or more should not be a problem.
>>>
>>> So, do my comments make sense?
>>
>> I have not done a performance comparison, but I agree with your
>> comments.  That is why I think it makes sense to keep both in the tree,
>> even though they provide the same functionality.
>>
> And we're adding the same functionality over SIP. It will not only
> distribute the states, but also offload Asterisk since you can have the
> SIP subscriptions on a separate server.

Olle, I guess you will have similar problems. I wonder:

What Event type do you use? presence? dialog? proprietary?

In case of dialog: What if a device has 2 calls established - will you 
PUBLISH 2 tuples, or a aggregated one?

What if multiple servers PUBLISH state information for the same device? 
Will you aggregate them at the server side?

PUBLISHing device state to an external presence server will help you to 
offload BLF subscriptions, but it won't help you for example with 
queues. Or will you PUBLISH the state also to other Asterisk servers?

regards
Klaus



More information about the asterisk-dev mailing list