Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
RFC 5366
|
| Document |
Type |
|
RFC - Proposed Standard
(October 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5366 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Cullen Jennings
|
|
Send notices to |
|
(None)
|
Network Working Group G. Camarillo
Request for Comments: 5366 Ericsson
Category: Standards Track A. Johnston
Avaya
October 2008
Conference Establishment Using Request-Contained Lists
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 describes how to create a conference using SIP URI-list
services. In particular, it describes a mechanism that allows a User
Agent Client to provide a conference server with the initial list of
participants using an INVITE-contained URI list.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Re-INVITE Request Generation ...............................3
4. URI-List Document Format ........................................3
5. Conference Server Procedures ....................................5
5.1. Re-INVITE Request Handling .................................6
6. Example .........................................................6
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
Camarillo & Johnston Standards Track [Page 1]
RFC 5366 INVITE-Contained Lists October 2008
1. Introduction
Section 5.4 of [RFC4579] describes how to create a conference using
ad hoc SIP [RFC3261] methods. The client sends an INVITE request to
a conference factory URI and receives the actual conference URI,
which contains the "isfocus" feature tag, in the Contact header field
of a response -- typically a 200 (OK) response.
Once the UAC (User Agent Client) obtains the conference URI, it can
add participants to the newly created conference in several ways,
which are described in [RFC4579].
Some environments have tough requirements regarding conference
establishment time. They require the UAC to be able to request the
creation of an ad hoc conference and to provide the conference server
with the initial set of participants in a single operation. This
document describes how to meet this requirement using the mechanism
to transport URI lists in SIP messages described in [RFC5363].
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 [RFC2119].
3. User Agent Client Procedures
A UAC that wants to include the set of initial participants in its
initial INVITE request to create an ad hoc conference adds a body
whose disposition type is 'recipient-list', as defined in [RFC5363],
with a URI list that contains the participants that the UAC wants the
conference server to invite. Additionally, the UAC MUST include the
'recipient-list-invite' option-tag (which is registered with the IANA
in Section 8) in a Require header field. The UAC sends this INVITE
request to the conference factory URI.
The INVITE transaction is also part of an offer/answer exchange that
will establish a session between the UAC and the conference server,
as specified in [RFC4579]. Therefore, the INVITE request may need to
carry a multipart body: a session description and a URI list.
3.1. Response Handling
The status code in the response to the INVITE request does not
provide any information about whether or not the conference server
was able to bring the users in the URI list into the conference.
Show full document text