[asterisk-bugs] [JIRA] (ASTERISK-21164) Need clarification on distributed device state behavior and whether this behavior is a possible regression

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-21164:
---------------------------------------

             Summary: Need clarification on distributed device state behavior and whether this behavior is a possible regression
                 Key: ASTERISK-21164
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21164
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Resources/res_xmpp
         Environment: pbx1: SVN 11 r381835,  pbx2: 11.1.0, connected to OpenFire XMPP pubsub via res_xmpp
            Reporter: Rusty Newton


How should distributed device state work on a cluster of only two systems? I haven't found documentation that describes this specifically. If it doesn't exist, then it should be documented to help admins understand how to use the feature.

I've provided attached documents to show where behavior differences between an older version of 11 and a newer SVN version of 11 might indicate a regression. Or, it may just indicate behavior that was broken before and is now fixed..

A bit more detail:

On pbx1 I don't see any reflection of device state for "Custom:mystate" when pbx2 changes the state of that device.

If pbx1 changes device state first, then on pbx2 you can see new values for device state of "Custom:mystate" by using DEVICE_STATE or looking at the associated hint. However "devstate list" doesn't show a change.

Which behavior is correct? 

* see attached config.txt for xmpp.conf of the systems
* see attached state_changes.txt for a layout of the device states when either system is receiving the pubsub events.
* see attached pbx1_debug.txt for debug when pbx1 receives changes from pbx2.
* see attached pbx2_debug.txt for debug when pbx2 receive changes from pbx1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira