Explicit Subscriptions for the REFER Method
Extracted elements (24)
RFC 3515's implicit subscription on REFER conflates subscription creation with request handling, making it impossible to negotiate SUBSCRIBE extensions (duration, Event header parameters) and complicating avoidance of SIP dialog reuse. This document removes the implicit subscription to resolve these problems.
The id parameter in NOTIFY Event header fields is preserved in subscriptions using this extension even though the Refer-Events-At URI already uniquely identifies the state, making the id parameter redundant. This is done to reduce implementation changes and maintain compatibility with existing diagnostic tools.
When the REFER forks, only one final response returns to the UA. If the UA must track all locations that accepted the REFER, using the 'explicitsub' extension is inappropriate; the UA should instead send REFER within an existing dialog or use the Target-Dialog mechanism to ensure single-location acceptance.
If a REFER with 'explicitsub' or 'nosub' is sent to an element that does not support the extension, a 420 (Bad Extension) response is returned; the UA can then retry the request without the extension, falling back to RFC 3515 implicit subscription behavior.
RFC 7614 updates RFC 3515 by removing the requirement to reject out-of-dialog SUBSCRIBE requests to event 'refer'; an element MAY now accept such requests following this document's requirements, making REFER no longer the only mechanism that can create a 'refer' event subscription.
A SUBSCRIBE request to the 'refer' event at the Refer-Events-At URI MUST NOT reuse any existing dialog identifiers; it must establish a new dialog.
A UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any request other than REFER, and MUST NOT include them in any SIP response other than a 200 or 421 response to a REFER request.
A UAS MUST NOT include either option tag in the Require header field of a 200 response to a REFER request if that tag was not present in the Require header field of the request.
An element accepting a REFER request with 'explicitsub' in its Require header field MUST NOT create an implicit subscription.
An element accepting a REFER request with 'nosub' in its Require header field MUST NOT create an implicit subscription and is not required to maintain any state for serving refer event subscriptions.
An element that accepts a REFER request with 'explicitsub' in its Require header field MUST return a 200 response containing a sip: or sips: URI in the Refer-Events-At header field, and that URI MUST uniquely identify the refer event state associated with this REFER request.
Implementations SHOULD provide a Refer-Events-At URI constructed in a way that is hard to guess; using a temporary GRUU is recommended as one good way to achieve this.
Subsequent SUBSCRIBE requests used to refresh or terminate a refer event subscription MUST contain the id parameter from the NOTIFY Event header field, to maintain compatibility with existing implementations and diagnostic tools.
The event server MUST retain the final refer event state for a reasonable period of time, which SHOULD be at least 2*64*T1 (64 seconds), to serve SUBSCRIBE requests that arrive after the referred action completes.
The Refer-Events-At header field is only meaningful in a 2xx-class response to a REFER request; if it appears in any other SIP message, it MUST be ignored.
The 'explicitsub' option tag is included in the Require header field of a REFER request to suppress implicit subscription creation while allowing an explicit subscription via a URI returned in the Refer-Events-At header field.
The 'nosub' option tag is included in the Require header field of a REFER request to suppress implicit subscription creation and signal that no explicit subscription will be forthcoming, allowing the recipient to avoid maintaining refer event subscription state.
When a SUBSCRIBE arrives during the refer event state retention period after the referred action has completed, the subscription is accepted and immediately terminated with a NOTIFY containing the final event state and Subscription-State of 'terminated' with reason 'noresource'.
The 'explicitsub' option tag is registered in the 'Option Tags' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry, identifying the extension to suppress implicit REFER subscriptions and provide a URI for explicit subscription.
The 'nosub' option tag is registered in the 'Option Tags' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry, identifying the extension to suppress implicit REFER subscriptions with no explicit subscription forthcoming.
The 'Refer-Events-At' header field is registered in the 'Header Fields' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry with no compact form defined.
A malicious agent controlling the Refer-Events-At URI in a REFER response can cause a SIP SUBSCRIBE to be sent as raw traffic toward a victim, with up to 11x amplification over UDP due to retransmissions. This risk is lower than the Refer-To URI attack because only sip:/sips: schemes are allowed and a valid REFER request must be received first.
An element may authorize an initial SUBSCRIBE to 'refer' event state based solely on the Request-URI matching an existing Refer-Events-At URI. Because URI possession is often the only authorization requirement, the URI must be hard to guess and protected against eavesdropping (e.g., transmitted over TLS/DTLS or using a sips: URI).
The Refer-Events-At header field carries a sip: or sips: URI enclosed in angle brackets, with optional generic parameters. ABNF: Refer-Events-At = "Refer-Events-At" HCOLON LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT *( SEMI generic-param ). A bare addr-spec without angle brackets is invalid.