> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Friday, October 19, 2007 11:52 AM > To: Stucker, Brian (RICH1:AR00) > 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.
Call stateful proxies (not B2BUAs) will probably chew up your call dialog. > > > 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. Maybe. Let's just keep the middle in mind so the ends works. > > 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
