|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Alan, Thanks for putting this together. First some questions:* is this meant to do a one-time sync? or provide ongoing synchronization between two event servers? I think your primary use case is syncing state between a primary and backup, in which case it would seem to me you'd need this on an ongoing basis, no?
* Assuming the primary use case is syncing state between a primary and backup, these batch notifications don't seem sufficient to make that work. In the case of presence, you really need the input states to the compositor - whatever they are - in order to allow the backup to continue to compute the presence state. Similarly, in the case of conferencing state, the conference itself would need to move to the backup in order for the backup to continue to generate event state. If you've moved the conference over anyway, the backup has the state it needs to generate the event notifications. So I don't see what is served by the batch notifications.
* is the assumption that the subscription is to ALL state? Or do you intend that the body of the subscribe could contain, for example, a list of the URI for which state is desired?
And a comment:* the example shows the server terminating the subscription when it is 'done'. However, the state may have changed since it was sent to the backup. Seems you have the 'catch the running train problem' of database state sync and you'd need to continuously keep the subscription going.
Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@xxxxxxxxx http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP