inline.... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Kyzivat > Sent: Thursday, December 11, 2003 11:20 AM > To: robert sparks > Cc: [EMAIL PROTECTED] > Subject: [Sip-implementors] Clarification needed - event id in REFER > refreshes > > > We've come across what seems to be an ambiguity in rfc 3515. Would like > to hear how others have interpretted it, and whether this ought to be > captured as a bug for future revision. (The answer determines how much > logic can be shared between regular subscriptions and implicit refer > subscriptions.) > > Section 2.4.6 of RFC 3515 talks about Multiple REFER Requests in a > Dialog as below: > > “Thus, for the second and subsequent REFER requests a UA receives in a > given dialog, it MUST include an id parameter[2] in the Event header > field of each NOTIFY containing the sequence number (the number from > the CSeq header field value) of the REFER this NOTIFY is associated > with. This id parameter MAY be included in NOTIFYs to the first > REFER a UA receives in a given dialog. A SUBSCRIBE sent to refresh > or terminate this subscription MUST contain this id parameter.” > > This gives discretion to the UAS of the REFER regarding the inclusion or > omission of an id= parameter in the NOTIFY for the first refer in > a dialog. > > The question is: must the UAC for the REFER follow the lead of the UAS > when performing a refresh of the subscription? > > To be specific, consider the following scenario: > > - X sends REFER to Y, with CSeq of 123. > - Y responds with 200 > - Y sends NOTIFY to X, with Event:refer;id=123 > - later, X sends SUBSCRIBE to Y, with Event:refer > (without id parameter) > > Is this valid? I don't think so, but I want to be sure. [TOLGA]IMO this is valid. You even don't have multiple subscriptions in the dialogue, why shouldn't it be valid? > > As long as the refresh attempt doesn't happen until after the first > notify is received, there seems no reason why the UAC shouldn't follow > the lead of the UAS. > > An obscure corner case is where the initial notify doesn't arrive, and > the REFER UAC decides it wants to refresh the subscription (presumed to > exist in spite of no evidence). In that case it would have to guess > whether to insert the id or not. But I think this case is bogus for the > following reasons: > - in the case of a subscribe, the 2xx establishes the subscription. > In the case of REFER this may not be the case. > - Until the first NOTIFY is received there is no determination of > the lifetime of the subscription, except via the default value > from 3515. > - it is erroneous for the NOTIFY to not be delivered for the long > period of time until the implicit subscription might be inferred > to be expiring. [TOLGA]My understanding is, if there is a single subscription in the dialogue, no need for "id". And if there are multiple subscriptions established with REFER, then the first one does not need "id", no "id" identifies the first one -but one also might include the "id", just not mandatory-, for subscriptions created with subsequent REFERS, "id" should be included, which is equal to CSeq of the corresponding REFER. > > A perhaps less obscure case would be where the UAC for the REFER doesn't > want the implicit subscription, and so sends an subscribe to cancel it > right after receiving the 200 for the refer. > > Restating the question: > > - If the recipient of a REFER (the first in a dialog) decides to > identify the subscription using id=(cseq of refer) in the corresponding > notifications, must it still recognize subscription refresh requests > that do not contain an event id? > > - Conversely, if the recipient of a REFER (the first in a dialog) > decides to identify the subscription by omitting an event id in the > corresponding notifications, must it still recognize subscription > refresh requests that do contain an event id matching the cseq of > the refer? > > I think the UAC for the REFER must follow the UAS for the refer, > identifying the subscription however it is identified in the first > notification. As a consequence, a refresh can't be sent until the first > notification is received. > > Paul > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
