> I presume the answers you gave are a > result of private communication with > the authors. I can't see any way to find > those interpretations as normative or > implied by anything in the RFCs.
My questions were posted April 5 to the SIP list. I just noticed that Adam's reply didn't include the list. > > > 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. > > I gather that you are saying this should > be an error. Yes. Otherwise it could complicate distinguishing an invite from a re-invite. > > 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? > > I think this highlights some areas where > things didn't get cleaned up fully after > the introduction of dialogs. > > "Call Leg" could be read here to simply be > the obsolete name for "dialog". But with that > interpretation 481 is an inappropriate response, > because the dialog *does* exist. > > Or "Call Leg" could be read here to mean > the call-specific part/extension to a dialog. > If so, then it would be appropriate here, > but it would be inappropriate when no match > is found for a subscription with a tag. > > Or the description of 481 could be changed > to "Call Leg/Subscription/Transaction Does > Not Exist". > > Or it could simply be declared legal to > start a new call within a dialog that > doesn't yet have one. > > > > > Assuming a 405 and Allow header can be > > considered dialog specific, the 405 > > with an Allow header might be a better > > response. > > That doesn't seem quite right either. > Because the method *is* allowed, even > within a dialog. It is a particular type > of use of the method that is illegal. > > > > 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. > > Well, that would simplify things. > > By implication, any other future sip extension that creates > dialogs would presumably have to follow the same rule, > because the same arguments apply. The effect would be to > create first and second class citizens in dialogs - calls are > first class, while any other user of a dialog is 2nd class. > Only 1st class citizens can do target refreshes. (This isn't > necessarily bad - INVITE is clearly first among equals in SIP.) > > Then the language in 3261 that suggests other extensions may > define new ways of doing target refresh would be invalid. > > Seems like it would be simpler to say that a dialog has one > remote target (at each end), and it can be refreshed by any > target refresh that is otherwise valid in the dialog. (So a > target refresh by a Subscribe would affect a call that shares > the dialog.) My understanding is that RFC3265 could have allowed the Contact portion of a route to be updated within subscription dialogs. However for simplicity, the author chose not to allow it. Hopefully the lack of explicitly mentioning a "target refreshing request" within RFC3265 can be interpreted as "no requests" instead of "all requests". However when traversing other dialogs, ones established by invite, it requires being updated based upon the rules of that established the dialog. Thus re-invite contact update should change the subscriptions route. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
