A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages
RFC 4483
|
Document |
Type |
|
RFC - Proposed Standard
(May 2006; Errata)
|
|
Author |
|
Eric Burger
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 4483 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Allison Mankin
|
|
Send notices to |
|
<rohan@ekabal.com>
|
Network Working Group E. Burger, Ed.
Request for Comments: 4483 Cantata Technolgy, Inc.
Category: Standards Track May 2006
A Mechanism for Content Indirection
in Session Initiation Protocol (SIP) Messages
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 (2006).
Abstract
This document defines an extension to the URL MIME External-Body
Access-Type to satisfy the content indirection requirements for the
Session Initiation Protocol (SIP). These extensions are aimed at
allowing any MIME part in a SIP message to be referred to indirectly
via a URI.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Use Case Examples ...............................................3
3.1. Presence Notification ......................................4
3.2. Document Sharing ...........................................4
4. Requirements ....................................................5
5. Application of RFC 2017 to the Content Indirection Problem ......6
5.1. Specifying Support for Content Indirection .................6
5.2. Mandatory support for HTTP URI .............................7
5.3. Rejecting Content Indirection ..............................7
5.4. Specifying the Location of the Content via a URI ...........7
5.5. Marking Indirect Content Optional ..........................7
5.6. Specifying Versioning Information for the URI ..............8
5.7. Specifying the URI Lifetime ................................8
5.8. Specifying the type of the Indirect Content ................8
5.9. Specifying the Size of the Indirect Content ................9
5.10. Specifying the Purpose of the Indirect Content ............9
5.11. Specifying Multiple URIs for Content Indirection .........10
Burger Standards Track [Page 1]
RFC 4483 Content Indirection in SIP Messages May 2006
5.12. Specifying a Hash Value for the Indirect Content .........10
5.13. Supplying Additional Comments about the Indirect
Content ..................................................11
5.14. Relationship to Call-Info, Error-Info, and
Alert-Info Headers .......................................11
6. Examples .......................................................12
6.1. Single Content Indirection ................................12
6.2. Multipart MIME with Content Indirection ...................12
7. Security Considerations ........................................13
8. Contributions ..................................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
1. Introduction
The purpose of the Session Initiation Protocol [9] (SIP) is to
create, modify, or terminate sessions with one or more participants.
SIP messages, like HTTP, are syntactically composed of a start line,
one or more headers, and an optional body. Unlike HTTP, SIP is not
designed as a general-purpose data transport protocol.
There are numerous reasons why it might be desirable to specify the
content of the SIP message body indirectly. For bandwidth-limited
applications such as cellular wireless, indirection provides a means
to annotate the (indirect) content with meta-data, which may be used
by the recipient to determine whether or not to retrieve the content
over a resource-limited link.
It is also possible that the content size to be transferred might
overwhelm intermediate signaling proxies, thereby unnecessarily
increasing network latency. For time-sensitive SIP applications,
this may be unacceptable. Indirect content can remedy this by moving
the transfer of this content out of the SIP signaling network and
into a potentially separate data transfer channel.
There may also be scenarios where the session-related data (body)
that needs to be conveyed does not directly reside on the endpoint or
User Agent. In such scenarios, it is desirable to have a mechanism
whereby the SIP message can contain an indirect reference to the
desired content. The receiving party would then use this indirect
Show full document text