[asterisk-dev] device_state distribution issues

[Klaus Darilion]

Russell Bryant wrote:
> On Mon, 2010-11-08 at 10:56 -0600, Kevin P. Fleming wrote:
>> On 11/08/2010 06:12 AM, Klaus Darilion wrote:
>>
>>> Does Asterisk keep proper state of remote devices (e.g. with a call 
>>> timeout)? If yes, then it is a bug. If no - then it would explain this 
>>> behavior but IMO would be a serious limitation.
>> I suspect you may be trying to do something that is not yet supported:
>> to my knowledge, the device state distribution that exists today is to
>> allow a device that is managed by *one* server to be visible to other
>> servers, so they can make decisions based on its state. It does not
>> support *multi-master* mode, where multiple servers are involved in
>> computing the state of a single device. For that to be possible, there
>> would have to be some 'owner' of the device to consolidate the
>> information from the servers involved.
> 
> In the case of res_ais, it works by having every server report state
> changes that occur on that server.  The result is that each server has
> an internal table of the state of each device from the perspective on
> each server involved.  When the state changes on _any_ server, it then
> looks at the last known state of that device on all servers and
> determines an overall state.  So, based on that, this is supposed to
> work.

Hi Russel! I just tried with AIS but the problem is still the same:

- watcher (BLF) SUBSCRIBEd to SIP/client1 on server1

- SIP/client1 on server2 makes a call
   -> event is distributed to server1
   -> NOTIFY
   -> BLF is on

- SIP/client1 on server1 makes a call
   -> BLF is still on

- SIP/client1 on server1 hangs up
   -> NOTIFY state=terminated
   -> BLF is off although SIP/client1 has still an active call server1


regards
Klaus




> 
> The way this works is that each event is tagged with a server ID
> (referred to as an entity ID, or EID).  From a quick look at the XMPP
> implementation, it appears that the server ID is not being propagated.
> So, the failure you are seeing is not ideal (a bug actually, please
> report it), but it is the expected behavior right now.
> 
> The XMPP distributed device state code needs to be updated such that the
> EID information element is included in state changes that it sends out
> such that its behavior matches that of the AIS implementation.
>