Hi Paul, I am talking about a proxy. So, you are saying that the proxy would always forward the NOTIFY, even if it does not have any state of a subscription dialog, or subscription usage within a dialog? Regards, Christer
________________________________ From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Sat 20/10/2007 00:34 To: Christer Holmberg Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John Subject: Re: [Sip] INFO Christer Holmberg wrote: > Hi, > > One potential issue: the stateful intermediate receives a NOTIFY without any > previous SUBSCRIBE. Is there a chance it would act on this, e.g. by sending a > 4xx response, or are we sure it would always simply forward the NOTIFY and > assume the endpoint will handle it? Are you talking about a B2BUA or a proxy? If a B2BUA, it suffers the common problem that it needs to be aware of pretty much all the standards in use by those it is connecting. If it was not aware of this new extension, and it was trying to enforce rules about what messages are allowed in what contexts, then yes it might cause trouble. But we specify stuff all the time that has similar issues with B2BUAs. Its up to B2BUAs to figure out how to be transparent or else go away. If its a proxy it has no business making such a judgment. Paul > Regards, > > Christer > > > > ________________________________ > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Fri 19/10/2007 18:52 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > > > Brian Stucker wrote: >> If we're going to change the way that error messages are handled that >> are returned for NOTIFY messages isn't it going to be a bit complicated >> to determine at the transaction layer if the NOTIFY was negotiated via >> INVITE or via SUBSCRIBE? >> >> I mean, the endpoints may know what's going on, but boxes in the middle >> might not. > > I don't see any reason why *proxy* middle boxes need to know anything > about this. B2BUAs will need to know, but then they will know. > >> I'm a bit concerned that by tweaking 3265 in this way we're going to >> move more complexity into all subscription processing whether it's a >> usage within a dialog, a separate dialog or this new thing. > > It would only affect those that support it. > > And I don't think it will be a big deal, but then this is just > speculation at this point, since no details have been worked out. Its > always possible that it would turn into a mess. > > Paul > >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] >>> Sent: Friday, October 19, 2007 10:55 AM >>> To: Hadriel Kaplan >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >>> Brian (RICH1:AR00) >>> Subject: Re: [Sip] INFO >>> >>> >>> >>> Hadriel Kaplan wrote: >>>> Which is one of the reasons I think it should be INFO. >>> Using it would only be an update to rfc2976, right? >>>> -hadriel >>> I don't think the distinction is significant. Either way it >>> should be designed to be backward compatible. And neither way >>> will require actually changing those other documents. >>> >>> Using NOTIFY: >>> >>> - will need some new header(s) in INVITE and responses to >>> negotiate this >>> new capability within the invite dialog usage. >>> >>> - once that is done it will have established some new rules for using >>> NOTIFY in that context. This will not be used unless negotiated, >>> so there aren't any backward compatibility issues. >>> >>> - for those that *do* support this, the same code should ideally be >>> able to use either this technique or real subscriptions, with only >>> minor tweaks. >>> >>> - I would expect that any event packages defined in the future that >>> could meaningfully be used in this way would be designed from the >>> ground up to support both styles. >>> >>> Using INFO: >>> >>> - I don't think it will be sufficient to just add headers to >>> NOTIFY itself. IMO there still needs to be negotiation of >>> the particular usages of NOTIFY. So there still need to be >>> new header(s) in invite and responses. >>> >>> - once the negotiation is done there will need to be some new >>> header(s) to provide added context for the INFO. >>> >>> - any usage that currently has an event package would have >>> to be modified to be used with INFO. >>> >>> Bottom line - I think a "lighter weight" subscription >>> mechanism serves all the same needs that an enhanced INFO >>> does, is no harder to implement, and has other benefits. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] >>>>> Sent: Friday, October 19, 2007 7:48 AM >>>>> To: Elwell, John >>>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>>> Subject: Re: [Sip] INFO >>>>> >>>>> Yes, my thinking has been that this would be a matter of >>> negotiating >>>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>>> isn't legal today - this would be an extension to both >>> 3261 and 3265. >>>>> Paul >>>>> >>>>> Elwell, John wrote: >>>>>> Michael, >>>>>> >>>>>> Yes, I guess some of the postings on this thread have >>> hinted that it >>>>>> would be the same dialog usage. I suppose if the >>> subscriptions are >>>>>> deemed to terminate at the time of the BYE transaction, then it >>>>>> would indeed by the same dialog usage. So it would appear to be >>>>>> within the letter of the dialogusage draft. However, one or two >>>>>> postings have suggested different. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Procter [mailto:[EMAIL PROTECTED] >>>>>>> Sent: 19 October 2007 08:48 >>>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>>> Cc: sip; Brian Stucker >>>>>>> Subject: RE: [Sip] INFO >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>>> INTIFY as Christer suggests) in this way would not >>> constitute a new >>>>>>> dialog-usage. A new usage would imply periodic >>> resubscription and >>>>>>> specific termination, whereas sending INTIFY within the >>> context of >>>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>>> terminate the call, and INTIFY no longer has a context. >>>>>>> >>>>>>> This neatly avoids violating the letter of the >>> dialogusage draft, >>>>>>> but you could probably argue that creating sub-usages of the >>>>>>> INVITE-usage isn't necessarily in keeping with the >>> spirit of the draft... >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:[EMAIL PROTECTED] >>>>>>>> Sent: 19 October 2007 07:41 >>>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: RE: [Sip] INFO >>>>>>>> >>>>>>>> Adam, >>>>>>>> >>>>>>>> Now that you have reminded us of the dialogusage draft, >>> perhaps it >>>>>>>> would be appropriate to remind people of the following from the >>>>>>>> abstract: >>>>>>>> "This memo argues that multiple dialog usages should be >>> avoided. >>>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>>> behavior for elements that cannot currently avoid them." >>>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>>> seems to deprecate introduction of further dialog >>> reuses. So if we >>>>>>>> were to go with NOTIFY, would this be a new dialog >>> usage, and if >>>>>>>> so, >>>>>>> do we really >>>>>>>> want to go ahead with something in contradiction to the >>> sentiment >>>>>>>> of that recently-approved draft? >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Adam Roach [mailto:[EMAIL PROTECTED] >>>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>>> To: Paul Kyzivat >>>>>>>>> Cc: sip; Brian Stucker >>>>>>>>> Subject: Re: [Sip] INFO >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>>> is INFO. It >>>>>>>>>> is my impression that INFO was designed for use with >>> INVITE, and >>>>>>>> so >>>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>>> And Robert >>>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>>>>> draft >>>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>>> 2976 predates >>>>>>>>> the current terminology, but a quick re-read does show >>> that it's >>>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>>> >>>>>>>>> /a >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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 > _______________________________________________ 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
