Subject: [Sipping] comments on draft-johnston-sipping-batch-notify-00

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Mar 2009 19:51:58 -0400

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
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Mar 2009 11:07:20 -0500

Jonathan,

Thanks for your comments - see my responses below.

Thanks,
Alan

Jonathan Rosenberg wrote:
> 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?

We have found use cases for both.  In some cases, just a snapshot is 
needed, with some other mechanism being used for ongoing synchronization.

In other cases, perhaps the more common cases, the subscription will be 
continued.  As a result, since there will be less state to transfer, the 
subscription will become a normal one, and probably not use these batch 
methods.

> continue to compute the presence state.

Agreed - for presence, it would be the raw event state rather than any 
output from an event state compositor. 

> 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.

I agree that the conference state use case is perhaps contrived - it 
isn't a real one that we've used it for.  I need to think about it some 
more.  However, I suspect it could be useful for syncing conference 
notification servers (as opposed to the actual focus doing the mixing 
and signaling).

> intend that the body of the subscribe could contain, for example, a 
> list of the URI for which state is desired?

This mechanism should work with filters, so the subscribe could include 
a filter body which would change it from all state to filtered state.

> backup. Seems you have the 'catch the running train problem' of 
> database state sync and you'd need to continuously keep the 
> subscription going.

Right - I think this is the more common case.  In some cases, a 
different mechanism (such as publication) might be used to share ongoing 
state after the batch sync is complete.  Does that make any sense?

> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Mar 2009 11:15:58 -0500

Jonathan,

Thanks for your comments - see my response below.

Thanks,
Alan