From: "Paul Mossman" <[EMAIL PROTECTED]>
RFC 4235 doesn't seem to specify that the notifier must explicitly list
each terminated dialogs in a full state notification.
In fact, it probably shouldn't.
Doing so would put an unnecessary burden on the notifier when reporting
full state. It would have to track which subscribers had previously
been notified about dialogs that are now terminated.
Though it seems that notifiers are expected to send updates with state
'terminated' with an 'event' attribute to explain why if they're
sending partial updates.
If a notifier sends a series of partial events, do we want the
information content to be different than if it sent a series of full
events?
This would also mean that two full state notification documents for the
same notifier and point in time could look different, depending on the
history of the subscriber.
They are different anyway, given the 'version' counter in
<dialog-info>. But this does make it worse, yes.
That seems strange to me.
There are a series of conceptual problems. RFC 3265 assumes that
there is a 'state', full updates are just a dump of the state, and
partial updates are just deltas between two states at different times.
But this model is violated in a number of ways:
- 'version' starts counting at 1 for every subscription, so it's
subscription-data, not state-data. (Fortunately, nobody enforces
this restriction!)
- 'terminated' is not a state, but a transition. So it "obviously"
should be in partial notifications, but it's not clear if it should
be in full notifications. But since 'terminated' carries additional
data ('event') beyond just the removal of the dialog from the
dialog-set, we can't just eliminate 'terminated' from the model.
Hence it appears in the state diagram.
- The inclusion of 'duration' means that the state changes
continuously, so we implicitly assume that changes of the duration
datum do not trigger sending of updates.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
