Hi Paul, So, I guess the compact version of your answer to my question is: "I am not sure" :)
So, if there is a chance that there is something which will go wrong I think we should really also consider using another method than NOTIFY. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 20. lokakuuta 2007 17:25 > To: Christer Holmberg > Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > Christer Holmberg wrote: > > 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? > > Well... > > There are transaction-stateless proxies, and > transaction-stateful proxies, and dialog-stateful proxies. > > Only a dialog-stateful proxy could make the kind of decision > you are talking about. > > AFAIK there is very little written about dialog-stateful > proxies. I think perhaps they have little utility, and have > been superseded by B2BUAs. So there isn't a lot to go on in > determining what they are permitted to do. > > In general I think a "proxy" is only permitted to return an > error to a request if it: > - isn't able to forward as requested > - is carrying out policy on behalf of the sender > or the recipient. (I suppose policy of the > carrier also applies on the assumption that > the caller or callee select the carrier and > hence implicitly agree to its policies.) > > My personal opinion is that the kind of checking you are > talking about is just "meddling" in the affairs of the UAs, > and should not be done. > But I suppose one might desire a policy that enforces > standards in this way. But if so, as a UA I don't want my > agents enforcing policies that prevent valid usages by my UA. > > Perhaps Hadriel would like to comment on this. His company > makes SBCs that I think are in the business of sticking their > nose into other people's sip usage and policing it. Do they > do this kind of enforcement? > > Paul > > > 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
