> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 16, 2007 4:34 PM > To: Dean Willis; Stucker, Brian (RICH1:AR00) > Cc: Eric Burger; sip; Audet, Francois (SC100:3055); Hadriel Kaplan > Subject: RE: [Sip] INFO > > > Hi, > > >>>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. > > I don't think anyone has proposed to forbid using separate dialogs. > > And, eventhough the receiver may be able to dispatch the > event to the correct application, the sender may still have > to send it on each subscription (if it doesn't know which > application is associated with each subscription), so the > result would be the same as using INFO. > > But, these are the kind of things we would need to document. > What are the issues, limitations etc with different > solutions. Then let's the implementors use what they need. > > >>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. > > All we need is draft-subscribe-header-for-invite... :)
And/or event header for INFO. Or perhaps not, but at least it's clearer (to me) what's missing now. > > Regards, > > Christer > _______________________________________________ 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
