Integration of Resource Management and Session Initiation Protocol (SIP)
RFC 3312
|
| Document |
Type |
|
RFC - Proposed Standard
(October 2002; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
ps
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3312 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Allison Mankin
|
|
Send notices to |
|
<rohan@cisco.com>
|
Network Working Group G. Camarillo, Ed.
Request for Comments: 3312 Ericsson
Category: Standards Track W. Marshall, Ed.
AT&T
J. Rosenberg
dynamicsoft
October 2002
Integration of Resource Management
and 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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines a generic framework for preconditions, which
are extensible through IANA registration. This document also
discusses how network quality of service can be made a precondition
for establishment of sessions initiated by the Session Initiation
Protocol (SIP). These preconditions require that the participant
reserve network resources before continuing with the session. We do
not define new quality of service reservation mechanisms; these
preconditions simply require a participant to use existing resource
reservation mechanisms before beginning the session.
Camarillo, et. al. Standards Track [Page 1]
RFC 3312 Integration of Resource Management and SIP October 2002
Table of Contents
1 Introduction ................................................... 2
2 Terminology .................................................... 3
3 Overview ....................................................... 3
4 SDP parameters ................................................. 4
5 Usage of preconditions with offer/answer ....................... 7
5.1 Generating an offer .......................................... 8
5.1.1 SDP encoding ............................................... 9
5.2 Generating an Answer ......................................... 10
6 Suspending and Resuming Session Establishment .................. 11
7 Status Confirmation ............................................ 12
8 Refusing an offer .............................................. 13
8.1 Rejecting a Media Stream ..................................... 14
9 Unknown Precondition Type ...................................... 15
10 Multiple Preconditions per Media Stream ....................... 15
11 Option Tag for Preconditions .................................. 16
12 Indicating Capabilities ....................................... 16
13 Examples ...................................................... 16
13.1 End-to-end Status Type ...................................... 17
13.2 Segmented Status Type ....................................... 21
13.3 Offer in a SIP response ..................................... 23
14 Security Considerations ....................................... 26
15 IANA Considerations ........................................... 26
16 Notice Regarding Intellectual Property Rights ................. 27
17 References .................................................... 27
18 Contributors .................................................. 28
19 Acknowledgments ............................................... 28
20 Authors' Addresses ............................................ 29
21 Full Copyright Statement ...................................... 30
1 Introduction
Some architectures require that at session establishment time, once
the callee has been alerted, the chances of a session establishment
failure are minimum. One source of failure is the inability to
reserve network resources for a session. In order to minimize "ghost
rings", it is necessary to reserve network resources for the session
before the callee is alerted. However, the reservation of network
resources frequently requires learning the IP address, port, and
session parameters from the callee. This information is obtained as
a result of the initial offer/answer exchange carried in SIP. This
exchange normally causes the "phone to ring", thus introducing a
chicken-and-egg problem: resources cannot be reserved without
performing an initial offer/answer exchange, and the initial
offer/answer exchange can't be done without performing resource
Show full document text