A Framework for Conferencing with the Session Initiation Protocol (SIP)
RFC 4353
|
| Document |
Type |
|
RFC - Informational
(February 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4353 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Allison Mankin
|
|
Send notices to |
|
rohan@ekabal.com, dean.willis@softarmor.com
|
Network Working Group J. Rosenberg
Request for Comments: 4353 Cisco Systems
Category: Informational February 2006
A Framework for Conferencing with the
Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, generally known as conferencing,
are more complicated. This document defines a framework for how such
conferencing can occur. This framework describes the overall
architecture, terminology, and protocol components needed for multi-
party conferencing.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
Rosenberg Informational [Page 1]
RFC 4353 Conferencing Framework with SIP February 2006
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................27
1. Introduction
The Session Initiation Protocol (SIP) [1] supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, however, are more complicated.
SIP can support many models of multi-party communications. One,
referred to as loosely coupled conferences, makes use of multicast
media groups. In the loosely coupled model, there is no signaling
relationship between participants in the conference. There is no
central point of control or conference server. Participation is
gradually learned through control information that is passed as part
of the conference (using the Real Time Control Protocol (RTCP) [2],
for example). Loosely coupled conferences are easily supported in
SIP by using multicast addresses within its session descriptions.
In another model, referred to as fully distributed multiparty
conferencing, each participant maintains a signaling relationship
Show full document text