Signaling compression

This article does not cite any sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Signaling compression" – news · newspapers · books · scholar · JSTOR (July 2024) (Learn how and when to remove this message)

|

The accessibility of this article is in question. Relevant discussion may be found on the talk page. (January 2011)

|

For data compression, signaling compression, or SigComp, is a compression method designed especially for compression of text-based communication data as SIP or RTSP. SigComp had originally been defined in RFC 3320 and was later updated with RFC 4896. A Negative Acknowledgement Mechanism for Signaling Compression is defined in RFC 4077. The SigComp work is performed in the ROHC working group in the transport area of the IETF.

## Overview

[edit]

SigComp specifications describe a compression schema that is located in between the application layer and the transport layer (e.g. between SIP and UDP). It is implemented upon a virtual machine configuration which executes a specific set of commands that are optimized for decompression purposes (namely UDVM, Universal Decompressor Virtual Machine).

One strong point for SigComp is that the bytecode to decode messages can be sent over SigComp itself, so this allows to use any kind of compression schema given that it is expressed as bytecode for the UDVM. Thus any SigComp compatible device may use compression mechanisms that did not exist when it was released without any firmware change. Additionally, some decoders may be already been standardised, so SigComp may recall that code so it is not needed to be sent over the connection. To assure that a message is decodable the only requirement is that the UDVM code is available, so the compression of messages is executed off the virtual machine, and native code can be used.

As an independent system a mechanism to signal the application conversation (e.g. a given SIP session), a compartment mechanism is used, so a given application may have any given number of different, independent conversations, while persisting all the session status (as needed/specified per compression schema and UDVM code).

## General architecture

[edit]

Elements that communicate with each other, see the description page for a detailed explanation

## References

[edit]

## Related standards documents

[edit]

* RFC 3320 – Signaling Compression (SigComp)
* RFC 3321 – Signaling Compression (SigComp) – Extended Operations
* RFC 3485 – The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
* RFC 3486 – Compressing the Session Initiation Protocol (SIP)
* RFC 4077 – A Negative Acknowledgement Mechanism for Signaling Compression
* RFC 4464 – Signaling Compression (SigComp) Users' Guide
* RFC 4465 – Signaling Compression (SigComp) Torture Tests
* RFC 4896 – Signaling Compression (SigComp) Corrections and Clarifications
* RFC 5049 – Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
* RFC 5112 – The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)
* 3GPP TR23.979 Annex C – Required SigComp performance