> -----Original Message----- > From: Paul Kyzivat > > I have discovered what appears to be ambiguity/unspecified > behavior in the > workings of dialogs, as specified in RFCs 3261 and 3265. I've > tried to frame > this as clearly as I can in questions below. I would appreciate > clarifications from anybody who considers themselves expert > in the topic. > > Thanks, > Paul > > 1) --------------------------------------------- > > According to RFC 3265, it is legal to send a SUBSCRIBE within a dialog > established by an INVITE. In this case, the subscribe, the > invite, and all > the notifies resulting from the subscribe share the same dialog. > > Q: Is the converse true?
Yes; that is the intention. I don't expect to see it happening very much, but the protocol is intended to allow it. > 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. > 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. [Two questions deleted as not-applicable in light of the other information] > 4) --------------------------------------------- > > Suppose a dialog is being shared by an INVITE and a > SUBSCRIBE. (Assume both > specified the same Contact address.) Then a reINVITE is used > to cause a > target refresh, providing a new Contact address. > > Q: Does this change in remote target affect where NOTIFY > messages are sent? Yes. /a _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
