[asterisk-dev] device_state distribution issues

[Olle E. Johansson]

9 nov 2010 kl. 17.00 skrev Klaus Darilion:

> 
> 
> 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?
We will publish two stages:
- First a proprietary use of dialog-info for devicestates 
- Then Asterisk normal dialog-info reports for extensionstate

> 
> In case of dialog: What if a device has 2 calls established - will you 
> PUBLISH 2 tuples, or a aggregated one?
As always with asterisk, we aggregate device state and extensionstate. No changes.
> 
> What if multiple servers PUBLISH state information for the same device? 
> Will you aggregate them at the server side?
Yes.
> 
> 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?
Since we publish device state it will indeed help with the queues.
You will have a devicestate provider reading the asterisk device states from 
the presence server.

/O