Referring to Multiple Resources in the Session Initiation Protocol (SIP)
EricssonHirsalantie 1102420JorvasFinlandGonzalo.Camarillo@ericsson.comNokiaP.O. Box 321NOKIA GROUPFIN 00045FinlandAki.Niemi@nokia.comNokiaP.O. Box 100NOKIA GROUPFIN00045Finlandmarkus.isomaki@nokia.comNokiaP.O.Box 6Nokia Siemens NetworksFIN02022Finlandmiguel.garcia@nsn.comEricsson Australiahisham.khartabil@gmail.com
RAI
SIP Working GroupSIPREFERmultiple
This document defines extensions to the SIP REFER method so that this
method can be used to refer servers to multiple resources. These
extensions include the use of pointers to Uniform Resource Identifier
(URI)-lists in the Refer-To header field and the "multiple-refer" SIP
option-tag.
RFC 3261 (SIP) is extended by RFC 3515 with a REFER method that allows a
user agent to request a server to send a request to a third
party. Still, a number of applications need to request a server to
initiate transactions towards a set of destinations. In one example,
the moderator of a conference may want the conference server to send
BYE requests to a group of participants. In another example, the same
moderator may want the conference server to INVITE a set of new
participants.
We define an extension to the REFER method so that REFER request can
be used to refer servers to multiple destinations. In addition, this
mechanism uses the suppression of the REFER method implicit
subscription specified in RFC 4488 to
suppress REFER's implicit subscription.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for
compliant implementations.
We define the following three new terms:
the user agent issuing the REFER
request.the user agent receiving the REFER
request.the intended final recipient of the
request to be generated by the REFER-Recipient.
This document defines an extension to the SIP REFER method specified
in RFC 3515 that allows a SIP User
Agent Client (UAC) to include a URI-list as specified in the XML Format for Representing Resource Lists of
REFER-Targets in a REFER request and send it to a server. The server
will create a new request for each entry in the list of REFER-Target
URIs.
The URI-list of REFER-Targets is used in conjunction with the XML Format Extension for
Representing Copy Control Attributes in Resource Lists to
allow the sender indicate the role (e.g., 'to', 'cc', or anonymous) in
which the REFER-Target is involved in the signalling.
We represent the multiple REFER-Targets of a REFER using a URI-list as
specified in the XML
Format for Representing Resource Lists . A UAC (User Agent
Client) that wants to refer a server to a set of destinations creates
a SIP REFER request. The Refer-To header contains a pointer to a
URI-list, which is included in a body part, and an option-tag in the
Require header field: "multiple-refer". This option-tag indicates the
requirement to support the functionality described in this
specification.
When the server receives such request it creates a new request per
destination and sends them.
This document does not provide any mechanism for UACs to find out
about the results of a REFER with multiple REFER-Targets. Furthermore,
it does not provide support for the implicit subscription mechanism
that is part of the SIP REFER method. The way UACs are kept informed
about the results of a REFER is service specific. For example, a UAC
sending a REFER to INVITE a set of participants to a conference can
discover which participants were successfully brought into the
conference by subscribing to the conference
state event (RFC 4575) .
We define a new SIP option-tag for the Require and Supported header
fields: "multiple-refer".
A user agent including the "multiple-refer" option-tag in a Supported
header field indicates compliance with this specification.
A user agent generating a REFER with a pointer to a URI-list in its
Refer-To header field MUST include the "multiple-refer" option-tag in
the Require header field of the REFER.
REFER requests with a single REFER-Target establish implicitly a
subscription to the refer event. The REFER-Issuer is informed about
the result of the transaction towards the REFER-Target through this
implicit subscription. As described in RFC
3515 , NOTIFY requests sent as a result of an implicit
subscription created by a REFER request contain a body of type "message/sipfrag", RFC 3420 , that describes
the status of the transaction initiated by the REFER-Recipient.
In the case of a REFER-Issuer that generates a REFER with multiple
REFER-targets, the REFER-Issuer is typically already subscribed to
other event package that can provide the information about the result
of the transactions towards the REFER-Targets. For example, a
moderator instructing a conference server to send a BYE request to a
set of participants is usually subscribed to the conference state
event package for the conference. Notifications to this event package
will keep the moderator and the rest of the subscribers informed of
the current list of conference participants.
Most of the applications using multiple REFER do not need its implicit
subscription. Consequently, a SIP REFER-Issuer generating a REFER
request with multiple REFER-Targets SHOULD include the "norefersub"
option-tag in a Require header field and SHOULD include a Refer-Sub
header field set to "false" to indicate that no notifications about
the requests should be sent to the REFER-Issuer. The REFER-Recipient
SHOULD honor the suggestion and also include a Refer-Sub header field
set to "false" in the 200 (OK) response. The "norefersub" SIP
option-tag and the Refer-Sub header field are specified in RFC 4488 .
RFC 4488 indicates that a
condition for the REFER-Issuer to include a Refer-Sub header is that
the REFER-Issuer is sure that the REFER request will not fork.
At the time of writing, there is no extension that allows to report
the status of several transactions over the implicit subscription
associated with a REFER dialog. That is the motivation for this
document to recommend the usage of the "norefersub" option-tag. If in
the future such an extension is defined, REFER-Issuers using it could
refrain from using the "norefersub" option-tag and use the new
extension instead.
As described in the
Framework and Security Considerations for SIP URI-List Services
, specifications of individual URI-list services, need to
specify a default format for 'recipient-list' bodies used within the
particular service.
The default format for 'recipient-list' bodies for conferencing UAs
(User Agents) and servers is the XML Formats for Representing
Resource Lists extended with the XML Format Extension for
Representing Copy Control Attributes in Resource Lists .
REFER-Recipients handling 'recipient-list' bodies MUST support both of
these formats and MAY support other formats.
As described in the XML Format Extension for
Representing Copy Control Attributes in Resource Lists , each
URI can be tagged with a 'copyControl' attribute set to either "to",
"cc", or "bcc", indicating the role in which the recipient will get
the referred SIP request. However, depending on the target SIP method,
a 'copyControl' attribute lacks sense. For example, while a
'copyControl' attribute can be applied to INVITE requests, it does not
make sense with mid-dialog requests such as BYE requests.
In addition to the 'copyControl' attribute, URIs can be tagged with the
'anonymize' attribute, also specified in the XML Format Extension for
Representing Copy Control Attributes in Resource Lists to prevent
that the server discloses the target URI in a URI-list.
Additionally, the XML Format Extension for
Representing Copy Control Attributes in Resource Lists defines
a 'recipient-list-history' body that contains the list of recipients.
The default format for 'recipient-list-history' bodies for conference
services is also the
XML Formats for Representing Resource Lists extended with the XML Format Extension for
Representing Copy Control Attributes in Resource Lists .
Conferencing servers supporting this specification MUST support both
of these formats; UASes MAY support these formats. Both conferencing
servers and UASes MAY support other formats.
Nevertheless, the XML
Format for Representing Resource Lists document provides
features, such as hierarchical lists and the ability to include
entries by reference relative to the XCAP root URI, that are not
needed by the multiple REFER service defined in this document.
shows an example of a flat list that
follows the resource list document.
As indicated in and a SIP REFER-Issuer that creates a REFER
request with multiple REFER-Targets includes a "multiple-refer" and
"norefersub" option-tags in the Require header field and, if
appropriate, a Refer-Sub header field set to "false". The REFER-Issuer
includes the set of REFER-Targets in a recipient-list body whose
disposition type is 'recipient-list', as defined in the Framework and Security
Considerations for SIP URI-List Services . The URI-list body is
further described in .
The Refer-To header field of a REFER request with multiple
REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC
2392 ) that points to the body part that carries the
URI-list. The REFER-Issuer SHOULD NOT include any particular URI more
than once in the URI-list.
The XML Format for
Representing Resource Lists document provides features, such
as hierarchical lists and the ability to include entries by reference
relative to the XCAP root URI. However, these features are not needed
by the multiple REFER service defined in this document. Therefore,
when using the default resource list document, SIP REFER-Issuers
generating REFER requests with multiple REFER-Targets SHOULD use flat
lists (i.e., no hierarchical lists) and SHOULD NOT use
<entry-ref> elements.
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 to determine the status code of the
response to the REFER.
The REFER-Recipient SHOULD not create an implicit subscription, and
SHOULD add a Refer-Sub header field set to "false" in the 200 OK
response.
The incoming REFER request typically contains a URI-list document or
reference with the actual list of recipients. If this URI-list
includes resources tagged with the 'copyControl' attribute set to a
value of "to" or "cc", and if appropriate for the service, e.g., if it
is non-mid dialog request, the URI-list server SHOULD include a
URI-list in each of the outgoing requests. This list SHOULD be
formatted according to the XML Format for
Representing Resource Lists and the XML Format Extension for
Representing Copy Control Attributes in Resource Lists. The
URI-list server MUST follow the procedures specified in XML Format for Representing Resource Lists
with respect handling of the 'anonymize', 'count' and 'copyControl'
attributes.
Section 4 of the
Framework and Security Considerations for SIP URI-List Services
discusses cases when duplicated URIs are found in a URI-list. In
order to avoid duplicated requests, REFER-Recipients MUST take those
actions specified in
Framework and Security Considerations for SIP URI-List Services into
account to avoid sending duplicated request to the same recipient.
If the server includes a URI-list in an outgoing request, it MUST
include a Content-Disposition header field,
specified in RFC 2183 , with the value set to
'recipient-list-history' and a 'handling'
parameter, specified in RFC 3204 , set to "optional".
Since the multiple REFER service does not use hierarchical lists nor
lists that include entries by reference to the XCAP root URI, a
REFER-Recipient receiving a URI-list with more information than what
has been described in MAY discard all the
extra information.
The REFER-Recipient follows the rules in RFC
3515 to generate the necessary requests towards the
REFER-Targets, acting as if it had received a regular (no URI-list)
REFER per each URI in the URI-list.
shows an example flow where a
REFER-Issuer sends a multiple-REFER request to the focus of a
conference, which acts as the REFER-Recipient. The REFER-Recipient
generates a BYE request per REFER-Target. Details for using REFER
request to remove participants from a conference are specified in
RFC 4579.
The REFER request (1) contains a Refer-To header field that includes a
pointer to the message body, which carries a list with the URIs of the
REFER-Targets. In this example, the URI-list does not contain the
copyControl attribute extension. The REFER's Require header field carries
the "multiple-refer" and "norefersub" option-tags. The Request-URI is
set to a Globally Routable User
Agent URIs (GRUU) (as a guarantee that the REFER request will
not fork). The Refer-Sub header field is set to "false" to request the
suppression of the implicit subscription.
shows an example of this REFER request. The resource list document
contains the list of REFER-Target URIs along with the method of the
SIP request that the REFER-Recipient generates.
shows an example of the BYE request (3) that
the REFER-Recipient sends to the first REFER-Target.
The Framework and
Security Considerations for SIP URI-List Services discusses
issues related to SIP URI-list services. Given that a REFER-Recipient
accepting REFER requests with multiple REFER-targets acts as an
URI-list service, implementations of this type of server MUST follow
the security-related rules in the Framework and Security
Considerations for SIP URI-List Services . These rules include
mandatory authentication and authorization of clients, and opt-in
lists.
Additionally, REFER-Recipients SHOULD only accept REFER requests
within the context of an application the server understands (e.g., a
conferencing application). This implies that servers MUST NOT accept
REFER requests for methods they do not understand. The idea behind
these two rules is that servers are not used as dumb servers whose
only function is to fan-out random messages they do not understand.
This document defines a new SIP option-tag: "multiple-refer". This
option-tag should be registered in the SIP Parameters registry.
The following row shall be added to the "Option Tags" section of the
SIP Parameter Registry:
NameDescriptionReferencemultiple-referThis option tag indicates support for REFER requests that contain a
resource list document describing multiple REFER targets.[RFCXXXX]
Note to the RFC Editor: Please replace [RFCXXXX] with the RFC number
of this specification.