> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: > > > Right: "DTMF may not be the only information users want to send to > > each other during a session." This is why one MUST > establish multiple > > subscription dialogs. How else would one keep track of the > different > > elements / local routing decisions? If you are proposing > application > > routing a'la P-Asserted-Service... > > > > One of the arguments for INFO is that it happens in a dialog, > not a session. That is, even if you have multiple event > streams, they happen on the same dialog. > > 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). 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). Deep thought: Is all INFO is missing is simply the event header? Regards, Brian _______________________________________________ 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
