Got it in 1! Tagging the message with the context, also known as event in 3265 parlance, fixes the INFO application routing / context problem. I was one of the first to say we could fix INFO. In fact, I started revising Dean's draft of almost 5 years ago before I realized I was totally recreating SUBSCRIBE/NOTIFY.
In particular, the requesting party MUST do something that looks like a SUBSCRIBE, outside of the INVITE? Why? Because the call will fail if the particular reporting, like DTMF, is no supported. If the argument is reporting DTMF is a rare occurrence for, e.g., H.323 gateways, then failing a call to the H.323 gateway from a SIP Phone is not a desirable feature. The reason I decided not to go on that route is at best you save 2 messages (the instant NOTIFY and 200 OK) over using 3265. At that point, might as well use 3265. That said, I suppose, we could offer a "fast start" 3265. [If this has shades of H.323...] In this scenario the fact you advertise support or acceptance of particular INFO-packages is enough to enable a sender to send appropriately tagged INFO's to you. Of course, if one of those INFO's fails, then I will bet 75% of the implementations will tear down the call. 25% will leave the call up and RTP port open forever. I would also offer we give this mechanism a new method name, as it will NOT be backwards-compatible with INFO. On 10/15/07 11:26 AM, "Brian Stucker" <[EMAIL PROTECTED]> wrote: > > >> -----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 > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
