On Thu, 2003-12-11 at 13:55, Paul Kyzivat wrote: > Robert Sparks wrote: > > Hmm. > > > > Yes - I agree there is a bug here. I'll look at the revision history > > of the document to see when/why it was introduced. > > > > IIRC, the intent was that the REFER establishes the content of the > > Event header entirely - the NOTIFYer doesn't add an id if one isn't > > present. > > That would be good. > > > I think the text should say > > > > 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 the first > > REFER a UA sends in a given dialog. A SUBSCRIBE sent to refresh > > or terminate this subscription MUST contain this id parameter. > > Hmm. You are suggesting that an event id be present in the REFER? That > would require an Event header in the refer, which isn't legal AFAIK.
You're right, of course - I've been working too closely with SUBSCRIBE the last couple of weeks. So, what I say above is just out-in-space wrong. Let me start over. The original text is correct (whew). So, I agree that refresh SUBSCRIBEs must match the identifiers (specifically the Event id, or its absence) from the initial NOTIFY (or NOTIFYs if the REFER forked). Attempting to issue a refresh before that initial NOTIFY arrives is not particularly useful. If you are trying to unsubscribe, you are just adding traffic - the more efficient thing to do is 481 the NOTIFY. (The most efficient thing to do is request that no subscription be created in the first place, one we agree on a standard way to signal that). I can't think of a case where trying to change the duration to something non-zero before you get the initial notify wouldn't equally be served by waiting until the initial notify arrives. > > That is, a NOTIFYer is not supposed to add an id parameter unless one > > appeared in the SUBSCRIBE. > > > > Given the ambiguity in the current spec, implementations of both the > > REFERer and the NOTIFYer need to recognize an Event header with no > > id as equivalent to an Event header with the id equal to the CSeq > > of that first REFER with a given dialog identifier - even for > > refresh SUBSCRIBES. > > So you are saying that a notifier that inserts an id for the first refer > MUST accept a resubscribe with no id, *and* that a notifier that inserts > no id for the first refer MUST accept a resubscribe with an id? The above is noise - rewind and erase. Sorry. > > A related question: > > This applies just to the first refer in a dialog. A second refer *must* > use an ID even if it is not issued until after the subscription for the > prior refer has terminated? I believe this is the intent, but want to be > sure. (In any case, in the interest of being forgiving, there is a > temptation to make things work if the notifier doesn't use an id in this > case.) Yes - the intent was that any subscription established by the second or subsequent REFER sharing a given dialog identifier MUST have an explicit id, even if the initial SUBSCRIBE has already terminated. > > Paul > > > RjS > > > > On Thu, 2003-12-11 at 10:20, Paul Kyzivat wrote: > > > >>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. > >> > >>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. > >> > >>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
