On Oct 15, 2007, at 1:26 PM, Brian Stucker wrote:
The trick is demuxing the event streams, or in other words,
figuring out the context for each event. INFO currently gives
us nothing but the content- modifiers to figure this out.
That's not enough, as has widely been argued.
How does 3265 make this any better?
We're talking about identifying a data blob using an event plus a
content-type instead of a supported plus a content-type for a
period of
time to start and end in conjunction with the INVITE dialog (so the
subsciption-state header is mooted).
3265 makes it better in two ways:
1) It provides distinct dialogs for each channel of the mux. Thus,
two events of the same class, but related to different subscriptions,
can be distinguished.
2) It provides semantic distinction, such that two events that
transport the same kind of content but that have different effects on
the application can be distinguished.
The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but
retains 2. The argument is that this makes it good enough for some
applications. However, there are obviously applications where it
might NOT be good enough, and a separate dialog ala 3265 would be
required.
So a NOTIFY with an event header or an INFO without an event
header, all
other things being the same and the constrained semantics of the
NOTIFY
usage being put forward here...
Wouldn't it be equally valid to simply allow the INFO message to carry
an event header and say that INFO is the same as a NOTIFY with an
implicit subscription to an INVITE dialog? Isn't this pretty much what
it does already (minus the event header).
There needs to be an explicit declaration of willingness to receive
the semantic load indicated by the event package. Given that, one
could certainly envision revising INFO to do the job.
Deep thought: Is all INFO is missing is simply the event header?
Yes. The problem is that INVITE and 200 (OK) are missing the
"subscribe" header.
--
Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
