> 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? > > Specifically, what happens if I send an INVITE > within a dialog established by a SUBSCRIBE? > Does it share the dialog, or does it result > in an error of some sort?
Good question. It exposes a potential complication with the 481 response when sharing invites and subscribes on a single dialog. The response could be a 481 to the INVITE because of the To tag and no active call. However should the 481 also trigger a reaction concerning the subscription? Or should a 481 to SUBSCRIBE/NOTIFY only apply to the subscription part of the dialog; and a 481 to INVITE only apply to the invitation part of the dialog? Assuming a 405 and Allow header can be considered dialog specific, the 405 with an Allow header might be a better response. > 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. > > RFC 3265 doesn't explicitly mention target > refresh or remote target. It does however discuss > refreshing of subscriptions for the purpose of > changing the expiration time. It also fails to > discuss explicitly what target address is used for > notifications, though it does say: > > This NOTIFY message is sent on the > same dialog as created by the SUBSCRIBE response. > > By inference, the Contact header in a dialog > creating SUBSCRIBE must define the notifier's > remote target. > > 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? Based upon a response that I received from Adam last April, the answer is that the Contact can't be updated. The reason cited was the desire to reduce complications caused by invitations and subscriptions potentially sharing the same dialog. > If not, what should happen if it is attempted? The Contact change should be ignored just as the Record-Route updates are ignored. However since it is basically considered a protocol violation each device can act however they desire. > 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. > > RFC 3261 section 12.2 says: > > Requests within a dialog MAY contain > Record-Route and Contact header fields. > However, these requests do not cause the > dialog's route set to be modified, although > they may modify the remote target URI. > Specifically, requests that are not target > refresh requests do not modify the dialog's > remote target URI, and requests that are > target refresh requests do. > > Q: Is this SUBSCRIBE considered a target > refresh request? No. > Q: If so, does it affect the target for the > INVITE as well? > > Q: If it is not considered a target refresh, > does it result in an error response? It shouldn't, however the UAS can react however it desires. > Q: If it doesn't result in an error response, > what address is used for NOTIFY messages? It should use the already established dialog route. > 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. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
