Missing the point. If, for some reason, a NOTIFY gets a, for example, 410 response (instead of 200 OK), the *subscription* dialog terminates.
If an INFO gets a 410, the *call dialog* terminates. Probably not the behavior people expect. On 10/18/07 1:48 PM, "Brian Stucker" <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: Eric Burger [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 18, 2007 10:17 AM >> To: Stucker, Brian (RICH1:AR00); Dean Willis >> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois >> (SC100:3055); Hadriel Kaplan >> Subject: Re: [Sip] INFO >> >> 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. > > It doesn't *have* to fail. You can define different levels of > requirement for something. I think this is being a bit too harsh. > >> >> 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. > > Actually, > > You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE > anymore: > > http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01 > > You can suppress the auto-NOTIFY to your SUBSCRIBE, but the implication > here is that you can't SUBSCRIBE (safely) until you have at least an > early dialog or you otherwise know that the subscription isn't going to > fork because you won't get NOTIFYs back from forked dialogs that you can > 481. > > Again, seems complex to do something outside of the INVITE itself even > if it's not the most flexible mechanism. > > Regards, > Brian > >> >> >> 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. > > This is going to be super-confusing I think to people. Just use NOTIFY > if it looks, acts, and smells like NOTIFY. > >> >> 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. > > If your implementation is that broken what we do about INFO doesn't seem > relevant to increasing or decreasing the stability of the software. > >> >> 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. >> > 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
