Referring to Multiple Resources in the Session Initiation Protocol (SIP)
RFC 5368

Document Type RFC - Proposed Standard (October 2008; No errata)
Last updated 2013-03-02
Replaces draft-ietf-sipping-multiple-refer
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5368 (Proposed Standard)
Telechat date
Responsible AD Cullen Jennings
Send notices to sip-chairs@ietf.org, gonzalo.camarillo@ericsson.com
Network Working Group                                       G. Camarillo
Request for Comments: 5368                                      Ericsson
Category: Standards Track                                       A. Niemi
                                                              M. Isomaki
                                                                   Nokia
                                                        M. Garcia-Martin
                                                                Ericsson
                                                            H. Khartabil
                                                      Ericsson Australia
                                                            October 2008

Referring to Multiple Resources in the Session Initiation Protocol (SIP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines extensions to the SIP REFER method so that it
   can be used to refer to multiple resources in a single request.
   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  3
   4.  The multiple-refer SIP Option-Tag  . . . . . . . . . . . . . .  4
   5.  Suppressing REFER's Implicit Subscription  . . . . . . . . . .  4
   6.  URI-List Format  . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  Behavior of SIP REFER-Issuers  . . . . . . . . . . . . . . . .  6
   8.  Behavior of REFER-Recipients . . . . . . . . . . . . . . . . .  6
   9.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . 10
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 11

Camarillo, et al.           Standards Track                     [Page 1]
RFC 5368                   SIP Multiple REFER               October 2008

1.  Introduction

   RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with a
   REFER method that allows a user agent (UA) to request a second UA to
   send a SIP request to a third party.  For example, if Alice is in a
   call with Bob, and decides Bob needs to talk to Carol, Alice can
   instruct her SIP UA to send a REFER request to Bob's UA providing
   Carol's SIP Contact information.  Assuming Bob has given it
   permission, Bob's UA will attempt to call Carol using that contact.
   That is, it will send an INVITE request to that contact.

   A number of applications need to request this second UA 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 requests can
   be used to refer other user agents (such as conference servers) to
   multiple destinations.  In addition, this mechanism uses the
   suppression of the REFER method implicit subscription specified in
   RFC 4488 [RFC4488].

2.  Terminology

   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
   [RFC2119] and indicate requirement levels for compliant
   implementations.

   This document reuses the following terminology defined in RFC 3261
   [RFC3261]:

   o  User Agent (UA)
   o  User Agent Client (UAC)
   o  User Agent Server (UAS)

   This document defines the following new terms:

   REFER-Issuer:  a user agent issuing a REFER request.

   REFER-Recipient:  an entity receiving a REFER request and forwarding
      a SIP request to a number of REFER-Targets.  The REFER-Recipient
      is typically a network entity, such as a URI-list server, that
Show full document text