Network Working Group H. Hannu (Editor), Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: May 2002 C. Clanton, Nokia
S. Forsgren. Ericsson
K. Le, Nokia
K. Leung, Nokia
Z. Liu, Nokia
R. Price, Siemens/Roke Manor
J. Rosenberg, Dynamicsoft
K. Svanbro, Ericsson
November 21, 2001
Signaling Compression (SigComp)
draft-ietf-rohc-sigcomp-02.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se.
Hannu, et al. [Page 1]
INTERNET-DRAFT SigComp November 21 , 2001
Abstract
The Session Initiation Protocol (SIP), along with many other
protocols used for multimedia communications, such as RTSP, are
textual protocols engineered for bandwidth rich links. With the
planned usage of these protocols in wireless handsets as part of 2.5G
and 3G cellular networks, the large size of their messages and the
chatty nature of the protocols are problematic.
This document provides a modular, robust and efficient message
compression scheme, suitable for compression of ASCII based
protocols' messages.
0. Document History
- October 19, 2001, version 00
First version. The draft describes the current ideas, from people
involved in the ROHC WG, of how to perform compression of
application signaling messages.
- October 31, 2001, version 01
Second version. Additional section, 5.2.1, which describes when a
message identifier can be reused.
- November 21, 2001, version 02
Third version. Section 6 has been moved to a separate draft. The
third version describes a modular solution, providing flexibility
for implementers to decide which functions they want to integrate.
Table of contents
1. Introduction..................................................3
2. Terminology...................................................3
3. High-level description of SigComp.............................4
4. The SigComp protocol..........................................5
5. Compression Framework Component...............................9
6. Capability exchange...........................................13
7. Security considerations.......................................14
8. IANA considerations...........................................14
9. Authors' addresses............................................14
10. Intellectual Property Right Considerations....................16
11. References....................................................16
Hannu, et al. [Page 2]
INTERNET-DRAFT SigComp November 21 , 2001
1. Introduction
The Session Initiation Protocol (SIP) [SIP], along with many other
application protocols used for multimedia communications, such as
RTSP [RTSP], are textual protocols engineered for bandwidth rich
links. As a result, these messages have not been optimized for
message size. Typical SIP messages are from a few hundred bytes to as
high as 2000. To date, this has not been a significant problem.
With the planned usage of these protocols in wireless handsets as
part of 2.5G and 3G cellular networks, the large size of these
messages is problematic. The problem is not bandwidth efficiency (the
media stream still consumes the majority of the bandwidth), but
rather latency. With low-rate IP connectivity, store-and-forward
delays are significant. For CDMA2000, for example, the basic channel
will support only 9.6 kbps. At this rate, transmission of each byte
requires 0.8ms. A 500 byte SIP message requires nearly half a second
to transmit. Taking into account retransmits, and the multiplicity of
messages that are required in some flows, call setup and feature
invocation are adversely affected. Therefore, we believe there is
merit in investigating ways to reduce message sizes.
This document defines SigComp, a modular, robust and efficient
message compression scheme, even when the transport path between the
compressor and decompressor is unreliable, i.e. prone to errors,
losses and misordering.
From the view of external users, SigComp is only to provide
compression service. What you get is the service of the underlying
transport + compression. Nothing more. Nothing less.
SigComp consists of a compression component and a protocol component.
The protocol component should not be "extracted" out of the contents
of this document for other purpose.
This document does not specify a negotiation mechanism. The
application that would like to apply SigComp should also negotiate
the usage of 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].
Byte buffer
The decompressor used by SigComp maintains a byte buffer, which
depending on the implementation choice, contain any previously
received text strings that might be useful for future compression.
Hannu, et al. [Page 3]
INTERNET-DRAFT SigComp November 21 , 2001
Context
The context of SigComp is the necessary information to perform
compression and decompression. The correct context to use is
identified by the IP Source and Destination addresses.
3. High-level description of SigComp
Compression and decompression is performed at two communicating end-
points, A and B, see Figure 1. When a message is to be compressed the
compressing entity looks up the IP source and destination addresses
and identifies the correct context to use. If no context exists, one
is created. Depending on the implementation of the SigComp
compressing entity the protocol might add a header to the output of
the compressor. The final SigComp message is then passed on to
underlying layers for transport to the decompressing entity.
Upon the arrival of a SigComp message the SigComp decompressing
entity will, if no context exists create one. If the SigComp message
carries a header it removes the header and takes the appropriate
actions (which depends on the implementation of the decompressing
entity), then it gives the remaining SigComp message as input to the
decompressor. After a correct decompression the uncompressed message
will be passed on to the receiver.
original +------------------+ SigComp +--------------------+
message | +----------+ | message | +------------+ |
------------+>|Compressor|-- - + - - - - - -+>|Decompressor|-----+->
| +-----|----+ | | +----|-------+ |
| +---|---+ | | +---|---+ |
| |Context| | | |Context| |
| +---+---+ | | +---+---+ |
| +---+---+ | | +---+---+ |
| |Context| | | |Context| |
decompressed | +---|---+ | SigComp | +---|---+ |
message | +-----|--------+ | message | +----|-----------+ |
<------------+-| Decompressor |<+- - - - - - +-| Compressor |<+--
| +--------------+ | | +----------------+ |
+------------------+ +--------------------+
A B
Figure 1. SigComp High-level view.
Note: There is no need for one uncompressed message to correspond to
exactly one compressed message. Two or more compressed messages can
be sent to reconstruct a single uncompressed message, which is useful
for segmenting compressed messages that are larger than the MTU of
the transport protocol, see [ALG].
Hannu, et al. [Page 4]
INTERNET-DRAFT SigComp November 21 , 2001
4. The SigComp protocol
The main task of the SigComp protocol is to provide feedback from the
decompressor to its peer compressor. The amount of feedback
information and how the compressor react to the feedback are choices
of the implementation. An implementation may also choose not to
implement any feedback mechanisms.
For the purpose of feedback, SigComp has a set of headers, as defined
in Section 4.1. The use of headers is established at the capability
exchange phase, see Section 6. The acknowledgment procedure in
Section 4.2 together with the headers MAY be used by a decompressing
entity to provide knowledge to the compressing entity about what
SigComp messages it has received. This would allow the compressor to
use previously sent messages in the compression process, even when
the underlying transport protocol is unreliable, see Section 5.
4.1. The SigComp headers
The SigComp headers consist of the following fields:
Message IDentification (MID) number
The MID number is used to keep track of sent and received
messages, and is useful for detecting message loss and/or
misordering.
CRC-verification of messages (CRC-M)
This CRC is calculated over the uncompressed message, e.g. the SIP
INVITE message, and is used to verify the correctness of a
decompressed SigComp message.
Acknowledgement
A SigComp acknowledgement can either be carried within a SigComp
message (Piggybacked) or be sent by itself (Standalone).
Note: It is assumed that the total length of a SigComp message is
provided by the underlying transport layer. Since the length of the
header part is self-contained the length of the compressed
information can be derived by subtracting the header length from the
total SigComp message length. The compressed information length could
be zero in the case of a Standalone acknowledgement.
Header formats are described in the following sub-sections.
Hannu, et al. [Page 5]
INTERNET-DRAFT SigComp November 21 , 2001
4.1.1. Normal header formats
These are the normal header formats to use. Format 1 SHOULD be used
when there has been no gap in the received MID numbers up to the
generation of this SigComp message. To acknowledge received SigComp
messages after a gap in the received MID numbers, Format 2 MUST be
used
Format 1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MID | Cumulative ACK|
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
/ Compressed information /
/ according to Section 5 /
+---+---+---+---+---+---+---+---+
Format 2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | MID |
+---+---+---+---+---+---+---+---+
| CRC-M |
+---+---+---+---+---+---+---+---+
| AC | RMID (1) |
+---+---+---+---+---+---+---+---+
| RMID (2) | RMID (3) |
+---+---+---+---+---+---+---+---+
: :
/ /
: :
+---+---+---+---+---+---+---+---+
| RMID (C-1) | RMID (C) |
+---+---+---+---+---+---+---+---+
/ Compressed information /
/ according to Section 5 /
+---+---+---+---+---+---+---+---+
MID: "0000" to "1101".
The Message IDentification (MID) number is commonly increased with
one for each sent message. However, there is the exception when
the next MID to be assigned is not "free", see Section 4.2.1.
Hannu, et al. [Page 6]
INTERNET-DRAFT SigComp November 21 , 2001
Cumulative ACK
Acknowledges all SigComp messages with MID number equal to or less
than the value of this field. The value of this field MUST NOT be
set to a value so that non-received SigComp messages are
acknowledged. A received acknowledgement with higher value than
the maximum MID MUST be ignored and MUST NOT be considered as an
acknowledgement for SigComp messages.
CRC-M
TBW
RMID
Received MID of a SigComp message, which is being acknowledged.
AC
Number of received SigComp message being acknowledged (RMID),
which are included in the List. If AC is an even number the last
RMID, RMID(C), is only padding, in order to get octet aligned.
4.1.2. Extended message formats
Format 3
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 | TBD |
+---+---+---+---+ +
/ TBD /
: :
/ /
+---+---+---+---+---+---+---+---+
Note: The usage of this format is yet to be determined.
(Decompressing failure etc.)
4.2. Acknowledgement procedure
The acknowledgement procedure is dependent on the information carried
in the SigComp headers. It is RECOMMENDED that all SigComp messages
are acknowledged.
Three functions are needed:
- A function that holds the received MID-numbers which should be
acknowledged.
Hannu, et al. [Page 7]
INTERNET-DRAFT SigComp November 21 , 2001
- A function that keeps a mapping between sent MID numbers and
acknowledged MID numbers.
- A function that controls which MID numbers that an entity is
allowed to use.
It is up to the implementation to realize these functions
The acknowledgement procedure is best described using an example, see
Figure 3.
A B
| |
Step (0) |<----------- MID 1B ----------|
| |
Step (1) |-------- MID 1A, ACK 1B ---->|
| |
Step (2) |<--------MID 2B, ACK 1A ------|
| |
Figure 3. Example of the acknowledgement procedure.
Step (0): A SigComp message with Message IDenitifcation number 1 is
sent from B to A, denoted MID 1B in Figure 3. MID 1B MUST be
acknowledged by A until A is confident that B knows that MID 1B is
received.
Step (1): Entity A acknowledges MID 1B with SigComp message MID 1A. A
mapping between MID 1A and MID 1B is stored at A. Note that MID 1A do
not have to carry compressed information, it can be a Standalone
Acknowledgement.
Step (2): Entity B acknowledges MID 1A and stores a mapping between
MID 2B and MID 1A. When Entity A receives MID 2B it uses the mapping
to find out which SigComp message(s) from B was acknowledged by MID
1A. The mapping is removed and MID 1B MUST NOT be acknowledged
anymore.
4.2.1. Reuse of Message IDentification numbers
This section describe when a MID can be reused to avoid
misinterpretations in case of wraparound of MID numbers combined with
message loss and/or misordering.
A MID number MUST NOT be reused until the SigComp message with that
particular MID number has been acknowledged and stopped being
acknowledged, or that the message can be regarded as lost.
Hannu, et al. [Page 8]
INTERNET-DRAFT SigComp November 21 , 2001
Figure 4, is a continuation of the example given in Figure 3. The
Figure depicts an example when it is allowed to reuse a MID number
that has been acknowledged and stopped being acknowledged.
A B
| |
Step (3) |-------- MID 2A, ACK 2B ---->|
| |
Figure 4. Continuation of Figure 3.
Step (3): When Entity B receives an acknowledgement for MID 2B it
knows that the mapping for MID 1B is removed at A. Therefore it
is safe for entity B to reuse MID 1B.
A message can be regarded as lost, if the SigComp entity has received
acknowledgments for higher MID numbers than the MID number the entity
wishes to reuse. However, as SigComp must stand against moderate
misordering according to [REQ], a MID number X MUST NOT be regarded
as lost until an acknowledgement for message(s) with MID numbers >
(X+2) has been received.
5. Compression Framework Component
SigComp uses the "Universal Decompression Algorithm" described in
[ALG] for the actual compression. The "universal decompressor" is
capable of interoperating with a wide range of compression
algorithms. It is the compressor which decides what information that
is stored in the dictionary of the decompressor. The compressor also
controls how the decompressor performs the decompression.
This section describes various features that a SigComp implementation
may use to improve the compression efficiency. Some of these feature
requires additional entries in the byte buffer of the "universal
decompressor".
5.1. Pre-population
A compressor MAY pre-populate the dictionary with well-known
information (text-strings), in order to increase the compression
efficiency. This is a rather simple approach with the "universal
decompressor", see [ALG].
5.2. Per-message compression
Compressing a message without any relation to any other message is
referred to as per-message compression. Per-message compression can
be used regardless of the reliability of the underlying transport and
Hannu, et al. [Page 9]
INTERNET-DRAFT SigComp November 21 , 2001
the usage of the SigComp headers, as it is not dependent on any
previously transmitted messages. To get compression of messages at
all, this is the approach which all implementations of SigComp MUST
support.
Implementation support for the features in the following sections is
optional.
5.3. Dynamic compression
A compressing entity MAY choose to use previously sent messages in
the compression process in an attempt to improve the compression
efficiency. This is referred to as dynamic compression. To ensure
reliable operation of the compression algorithm a compressor MUST NOT
use dynamic compression, unless it is certain of that the message it
is about to compress can be decompressed by the decompressor. If
SigComp is used over reliable transport, such as TCP, dynamic
compression does not introduce any robustness problem. To withhold
robustness over unreliable transport, such as UDP, the SigComp
acknowledgement procedure MUST be used when dynamic compression is
applied. Thus, a previously sent message MUST NOT be used in the
compression process until it has been acknowledged. Referring to
Figure 3, B MAY use information in 1B to improve the compression
efficiency of the message corresponding to 2B.
5.4. Shared compression
Shared compression is referred to the case when a compressor 'A' make
use of decompressed messages received by the decompressor located at
the same SigComp entity. These decompressed messages MUST originate
from the corresponding SigComp entity, which decompressor is
controlled by compressor 'A'. Shared compression is OPTIONAL and its
support is established in the capability exchange.
To allow shared compression it is REQUIRED to use the SigComp
acknowledgment procedure regardless of the reliability of the
underlying transport.
Referring to Figure 3, B MAY use information in 1A to improve the
compression efficiency of the message corresponding to 2B.
For shared compression to be applicable with the "universal
decompressor" a SigComp entity supporting shared compression MUST
implement two additional entries in the byte buffer of the
decompressor:
shared_start
This is the start address in the byte buffer where original
Hannu, et al. [Page 10]
INTERNET-DRAFT SigComp November 21 , 2001
messages (not compressed) from this entity, which are being
acknowledged, are to be placed into the byte buffer of the
decompressor. By setting shared_start = 0, a compressor can
avoid that any acknowledged message is written to the byte buffer.
shared_length
This is used by the protocol part to inform the decompressor
algorithm if there was any new information, and the length of it,
written to the shared compression part of the byte buffer. To
avoid that same message information is processed twice, in case of
multiple acknowledges for one message, the protocol MUST set
shared_length = 0.
Figure 5. depicts a logical view of the decompressor byte buffer at a
SigComp entity which supports shared compression.
+----A----------------------B---------------------+
| | Circular buffer for | Circular buffer for |
| | received messages | shared compression |
+----A----------------------B---------------------+
Figure 5. Logical view of the decompressor byte buffer.
A and B are the addresses which circular_buffer and shared_start
point to. The received circular buffer will be between
circular_buffer and shared_start-1. When the decompressing SigComp
entity receives a SigComp message containing acknowledgements for
e.g. MID-2 and MID-3 it will copy the original messages
corresponding to MID-2 and MID-3 to the decompressor buffer at the
address specified in shared_start.
5.4.1. Specification of ordering constraints
Inconsistency in the dynamic context data can happen if the context
is shared and messages, which will update the dynamic context data,
are sent concurrently by both entities. The approach to deal with
this problem is to specify ordering constraints of all update
messages sent by both entities so that the order is total and the
same at both entities, at least for the eligible updates. Three rules
are defined; local, causality and concurrent rule. With the first two
rules and the use of the 3-way handshake, it is possible to ensure
consistency during updates of dynamic context data, but there is one
case that these do not resolve; dynamic context data updates issued
concurrently by both entities.
With an update request in the description of the rules below means;
Every message that carries information that is used to update the
dynamic context data.
Hannu, et al. [Page 11]
INTERNET-DRAFT SigComp November 21 , 2001
Local Rule
When a dynamic context data update request R' is sent before R" at
the same entity, R' is scheduled to perform an update before R" at
both entities. A sending entity schedules its own update requests
according to their sequence numbers, whereas a receiving entity
schedules these requests according to the request sequence
numbers, which can be inferred from the sequence numbers of those
SigComp messages containing these requests.
Causality rule
When a SigComp message containing a dynamic context data update
request R' piggybacks with acknowledgements, R' is scheduled to
perform an update after all the updates corresponding to the
acknowledged update requests.
Concurrent rule
The problem explained above can be eliminated by requiring the
maintenance of a total order relationship for a sequence of all
known context update requests at each entity. This requires that
one entity is the master and one is the slave.
An example showing how the scheme with the total order relationship
solves the inconsistent context update problem is shown in Figure 6.
Suppose all messages exchanged between Entity X (a master entity) and
Entity Y (a slave entity) are employed for subsequent
compression/decompression, and all received messages are acknowledged
and piggybacked in all subsequent messages sent by the receiver.
Whenever concurrent dictionary updates are happened, update requests
initiated from the master entity are ordered first. For example, the
update requests for Messages 1, 2, and 3 are ordered before those for
Messages 101, 102, and 103 respectively in the list of the total
order relationship for a sequence of dictionary updates (TOL).
DD is a logical representation of the Dynamic Context Data, TSS is
the logical representation of sent SigComp messages and TRS is the
logical representation storage of received SigComp messages.
Since the update request for Message 1 is ordered before that for
Message 101 according to the total order relationship, the update
request for Message 101 at Entity Y is blocked until that for Message
1 becomes ready to be moved, as indicated by the reception of the
acknowledgement piggybacked with Message 3.
| |
DD = {} | | DD = {}
TSS = {1} | | TSS = {101}
TRS = {} | | TRS = {}
TOL = {1} | | TOL = {}
| [1] [101] |
Hannu, et al. [Page 12]
INTERNET-DRAFT SigComp November 21 , 2001
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {} | | DD = {}
TSS = {1, 2} | | TSS = {101, 102}
TRS = {101} | | TRS = {1}
TOL = {1, 101, 2} | | TOL = {1}
| [2] [102] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {1} | | DD = {}
TSS = {2, 3} | | TSS = {101 - 103}
TRS = {101, 102} | | TRS = {1, 2}
TOL = {101, 2, | | TOL = {1, 101, 2}
102, 3} | |
| [3] [103] |
|-----------\ /-----------|
| \/ |
| /\ |
|<----------/ \---------->|
| |
DD = {1, 101, 2} | | DD = {1, 101}
TSS = {3} | | TSS = {102, 103}
TRS = {102, 103} | | TRS = {2, 3}
TOL = {102,3,103} | | TOL = {2, 102, 3}
| |
CD Entity X CD Entity Y
Figure 6. An Example of Proposed Scheme with Total Order Relationship
for Dynamic Context Data Updates.
6. Capability exchange
Before two SigComp entities start to send compressed messages between
them, they MUST agree on the capabilities they will use. This section
does not specify how to perform the exchange, but preferably it
should be conducted at the negotiation of applying SigComp.
Buffer size
The available byte buffer size of the decompressor MUST be
exchanged.
Hannu, et al. [Page 13]
INTERNET-DRAFT SigComp November 21 , 2001
SigComp headers
Only in the case when both SigComp entities indicate the use of
headers, the SigComp protocol MUST add a SigComp header to the
compressor output. In any other case the protocol MUST NOT add a
header.
Shared compression
If a SigComp entity supports shared compression it MAY indicate
that. However, shared compression can only be used in combination
with SigComp headers. A SigComp entity is not required to use
shared compression even if it is supported by the corresponding
entity.
CPU power
TBW
7. Security considerations
TBW
8. IANA considerations
TBW
9. Authors' addresses
Hans Hannu, Editor
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 84
Fax: +46 920 20 20 99
EMail: hans.hannu@epl.ericsson.se
Jan Christoffersson
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 28 40
Fax: +46 920 20 20 99
EMail: jan.christoffersson@epl.ericsson.se
Hannu, et al. [Page 14]
INTERNET-DRAFT SigComp November 21 , 2001
Christopher Clanton
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4886
Fax: +1 972 894-4589
E-mail: christopher.clanton@nokia.com
Stefan Forsgren
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 23 39
Fax: +46 920 20 20 99
EMail: stefan.forsgren@epl.ericsson.se
Khiem Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4882
Fax: +1 972 894-4589
E-mail: khiem.le@nokia.com
Ka Cheong Leung
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-0630
Fax: +1 972 894-4589
E-mail: kacheong.leung@nokia.com
Zhigang Liu
2-700
Mobile Networks Laboratory
Nokia Research Center
6000 Connection Drive Irving, TX 75039, USA
Phone: +1 972 894-5935
Fax: +1 972 894-4589
Hannu, et al. [Page 15]
INTERNET-DRAFT SigComp November 21 , 2001
EMail: zhigang.liu@nokia.com
Richard Price
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Phone: +44 1794 833681
Email: richard.price@roke.co.uk
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
Email: jdrosen@dynamicsoft.com
Krister Svanbro
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@epl.ericsson.se
10. Intellectual Property Right Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
11. References
[ALG] R. Price et. al., Universal Decompression Algorithm,
Internet Draft (work in progress), November 2001.
<draft-ietf-rohc-sigcomp-algorithm-00.txt>
[DEFLATE] "DEFLATE Compressed Data Format Specification version
1.3", RFC 1951, P. Deutsch, May 1996
[RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time
Streaming Protocol (RTSP), RFC 2326, April 1998.
Hannu, et al. [Page 16]
INTERNET-DRAFT SigComp November 21 , 2001
[REQ] H. Hannu (Editor), Signaling Compression Requirements &
Assumptions, Internet Draft (work in progress),November
2001. <draft-ietf-rohc-signaling-req-assump-03.txt>
[SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg,
SIP: Session Initiation Protocol, RFC 2543, August 2000.
This Internet-Draft expires in May 2002.
Hannu, et al. [Page 17]
