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
