> -----Original Message----- > From: ext Adam Roach [mailto:adam@;dynamicsoft.com] > Sent: Monday, November 04, 2002 10:52 PM > To: '[EMAIL PROTECTED]' > Cc: '[EMAIL PROTECTED]' > Subject: RE: [Sip-implementors] Questions about Dialogs >
> > 2) --------------------------------------------- > > > > Q: Can a SUBSCRIBE cause a target refresh? > > > > RFC 3261, section 12.2 says: > > > > For dialogs that have been established with an > > INVITE, the only target refresh request defined is re-INVITE (see > > Section 14). Other extensions may define different > target refresh > > requests for dialogs established in other ways. > > That's somewhat unfortunate phrasing, and I don't think the intention > was quite what was said there. (We attempted to harmonize 3261 with > 3265 before they were both released, but 3261 is large enough that > something was bound to be missed). > > > Analogy to 3261 would suggest that a SUBSCRIBE used to refresh a > > subscription could refresh the target by including a Contact > > header with a > > new value. Is this valid? If not, what should happen if it is > > attempted? > > That is the intention. The dialog handling in 3265 is a bit under- > specified, and will be cleaned up in the next version. May I suggest that we only allow target refresh requests to have the same method as the request that created the dialog. i.e.: only a reINVITE can be target refresh requests for a dialog created by INVITE, only reSUBSCRIBE can be target refresh requests for a dialog created by SUBSCRIBE. For a dialog created by INVITE, a SUBSCRIBE does not update the target. For a dialog created by SUBSCRIBE, an INVITE does not update the target. This is the only way to do it to avoid complexity and confusion. Otherwise you got to start asking about REFER and other extensions that create dialogs. I would prefer implementors to be able to build a generic dialogs module in their stack that doesn't need to know about methods. I mean what if I send a MESSAGE within a dialog? my generic dialogs module no longer can be method agnostic because it has to know that MESSAGE does not refresh a target, but it has to know that SUBSCRIBE does... too complicated. In my suggestion, a dialog state would include the method that created the dialog, call it dialog-method, and only requests with methods that match the dialog-method are target refresh requests. > > > 3) --------------------------------------------- > > > > Suppose a dialog has been established by an INVITE. Then, a > > SUBSCRIBE is > > sent within this dialog. Further, suppose that the Contact > > header in the > > SUBSCRIBE differs from the the remote target of the invite dialog. > > > > Q: Is this SUBSCRIBE considered a target refresh request? > > This is an example of where the dialog handling in 3265 is > underspecified. My intention is to clearly define SUBSCRIBE > as a target refresh request in future revisions. Of course, > consensus may take us in a different direction. > > > Q: If so, does it affect the target for the INVITE as well? > > Yes. They share dialog state, and the contact information (being > part of the route) is portion of that dialog state. I disagree. Reasons are stated above. Regards, Hisham _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
