Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049
| Document | Type |
RFC - Proposed Standard
(December 2007; No errata)
Updates RFC 3486
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5049 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Magnus Westerlund | ||
| Send notices to | richard.price@cogent-dsn.com | ||
Network Working Group C. Bormann
Request for Comments: 5049 Universitaet Bremen TZI
Category: Standards Track Z. Liu
Nokia Research Center
R. Price
EADS Defence and Security Systems Limited
G. Camarillo, Ed.
Ericsson
December 2007
Applying Signaling Compression (SigComp)
to 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 some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters,
compartment and state management, and a few issues on SigComp over
TCP. Any implementation of SigComp for use with SIP must conform to
this document and SigComp, and in addition, support the SIP and
Session Description Protocol (SDP) static dictionary.
Bormann, et al. Standards Track [Page 1]
RFC 5049 Applying SigComp to SIP December 2007
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compliance with This Specification ..............................3
4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
4.2. state_memory_size (SMS) for SIP/SigComp ....................4
4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
4.4. SigComp_version (SV) for SIP/SigComp .......................5
4.5. locally available state (LAS) for SIP/SigComp ..............5
5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
6. Continuous Mode over TCP ........................................6
7. Too-Large SIP Messages ..........................................7
8. SIP Retransmissions .............................................7
9. Compartment and State Management for SIP/SigComp ................7
9.1. Remote Application Identification ..........................8
9.2. Identifier Comparison Rules ...............................10
9.3. Compartment Opening and Closure ...........................11
9.4. Lack of a Compartment .....................................13
10. Recommendations for Network Administrators ....................13
11. Private Agreements ............................................14
12. Backwards Compatibility .......................................14
13. Interactions with Transport Layer Security (TLS) ..............14
14. Example .......................................................15
15. Security Considerations .......................................17
16. IANA Considerations ...........................................17
17. Acknowledgements ..............................................17
18. References ....................................................18
18.1. Normative References .....................................18
18.2. Informative References ...................................19
Bormann, et al. Standards Track [Page 2]
RFC 5049 Applying SigComp to SIP December 2007
1. Introduction
SigComp [RFC3320] is a solution for compressing messages generated by
application protocols. Although its primary driver is to compress
SIP [RFC3261] messages, the solution itself has been intentionally
designed to be application agnostic so that it can be applied to any
application protocol; this is denoted as ANY/SigComp. Consequently,
many application-dependent specifics are left out of the base
standard. It is intended that a separate specification be used to
describe those specifics when SigComp is applied to a particular
application protocol.
This document binds SigComp and SIP; this is denoted as SIP/SigComp.
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 RFC 2119 [RFC2119].
Show full document text