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.
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
