One question below.... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Kyzivat > Sent: Thursday, December 11, 2003 2:56 PM > To: Robert Sparks > Cc: [EMAIL PROTECTED] > Subject: [Sip-implementors] Re: Clarification needed - event id in REFER > refreshes > > > > > 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. > > > 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. [TOLGA]Is this ambiguity a bug or is this the way it should be? I didn't interprete it as a bug till now, and so was interpreting a NOTIFY/SUBSCRIBE with no "id" as sent for the subscription established with the first REFER. Is there a problem with the semantics defined in RFC? It seems working. > > 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? > > 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.) > > 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 >
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
