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