Internet Engineering Task Force SIP WG
Internet Draft G. Camarillo
Ericsson
draft-camarillo-sip-compression-00.txt
April 22, 2002
Expires: October 2002
Compressing the Session Initiation Protocol
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 to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes a mechanism to signal that compression is
desired for one or more SIP messages. It also states when it is
appropriate to send compressed SIP messages to a SIP entity.
G. Camarillo [Page 1]
Internet Draft SIP April 22, 2002
Table of Contents
1 Introduction ........................................ 3
2 Overview of operation ............................... 4
3 Sending a Request to a Server ....................... 4
4 Sending a Response to a Client ...................... 5
5 Error Situations .................................... 6
6 Augmented BNF ....................................... 6
7 Security Considerations ............................. 6
8 Authors' Addresses .................................. 6
9 Bibliography ........................................ 7
G. Camarillo [Page 2]
Internet Draft SIP April 22, 2002
1 Introduction
A SIP [1] client sending a request to a SIP server typically performs
a DNS lookup for the domain name of the server. When NAPTR [2] or SRV
[3] records are available for the server, the client can specify the
type of service it wants. The service in this context is the
transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP
server that support, for instance, three different transport
protocols, will have three different DNS entries.
Since it is foreseen that the number of transport protocols supported
by a particular application layer protocol is not going to grow
dramatically, having a DNS entry per transport seems like a scalable
enough solution.
However, sometimes it is necessary to include new layers between the
transport protocol and the application layer protocol. Examples of
these layers are transport layer security and compression. If DNS was
used to discover the availability of these layers for a particular
server, the number of DNS entries needed for that server would grow
dramatically.
A server that, for example, supported TCP and SCTP as transports, TLS
for transport security and Sigcomp for signaling compression, would
need the 8 DNS entries listed below:
1. TCP, no security, no compression
2. TCP, no security, SigComp
3. TCP, TLS, no compression
4. TCP, TLS, SigComp
5. SCTP, no security, no compression
6. SCTP, no security, SigComp
7. SCTP, TLS, no compression
8. SCTP, TLS, SigComp
It is clear that this way of using DNS is not scalable. Therefore, an
application layer mechanism to express support of signalling
compression is needed.
Note that for historical reasons both HTTP and SIP use a
different port for TLS on top of TCP than for TCP alone,
G. Camarillo [Page 3]
Internet Draft SIP April 22, 2002
although at present this solution is not considered
scalable any longer.
2 Overview of operation
There are two types of SIP messages; SIP requests and SIP responses.
Clients send SIP requests to the host part of a URI and servers send
responses to the host in the sent-by parameter of the Via header
field.
We define two parameters, one for SIP URIs and the other for the Via
header field. The format of both parameters is the same, as shown in
the examples below:
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.atlanta.com:5060;branch=z9hG4bK87asdks7;comp=sigcomp
The presence of this parameter in a URI indicates that the request
has to be compressed using Sigcomp, as defined in [4]. The presence
of comp=sigcomp in a Via header field indicates that the response has
to be compressed using Sigcomp.
3 Sending a Request to a Server
A request is sent to the host part of a URI. This URI, referred to as
the next-hop URI, is the Request-URI of the request or an entry in
the Route header field.
If the next-hop URI contains the parameter comp=sigcomp, the client
SHOULD compress the request using Sigcomp as defined in [4]. The
next-hop URI can contain such a parameter due to a number of reasons:
o The URI was obtained from a Record-Route header field when the
dialog was established.
o The URI was previously registered in a registrar using a
REGISTER request.
o The URI was obtained from a Contact header field in a 3xx or
485 response to the request.
o The URI was obtained out of band.
If the next-hop URI does not contain the parameter comp=sigcomp but
the client wishes to compress the request, the client can
G. Camarillo [Page 4]
Internet Draft SIP April 22, 2002
compress the request if, and only if, it knows that the
server supports Sigcomp. This knowledge can be obtained in a number
of ways:
o In a previous transaction, the client obtained a URI for the
same server with the parameter comp=sigcomp (e.g., a Contact
header field in a 2xx response for a previous OPTIONS request
or an entry in the route set of a previous dialog).
o In a previous transaction, the server sent a request or a
response using Sigcomp.
o The client is statically configured to compress all the
traffic to that particular server.
A client SHOULD NOT send a compressed request to a server if it does
not know whether or not the server supports Sigcomp.
If a client does not know whether or not the server supports Sigcomp,
but in case the server supported it, it would like to receive
compressed responses, this client SHOULD add the parameter
comp=sigcomp to the topmost entry of the Via header field. The
request, however, as stated above, will not be compressed.
Regardless of whether the request is sent compressed or not, if a
client would like to receive subsequent requests within the same
dialog compressed, this client SHOULD add the parameter comp=sigcomp
to the URI in the Contact header field if it is a user agent client.
If the client is a proxy, it SHOULD add the parameter comp=sigcomp to
its URI in the Record-Route header field.
4 Sending a Response to a Client
A response is sent to the host in the sent-by parameter of the Via
header field. If the topmost Via header field contains the parameter
comp=sigcomp, the response SHOULD be compressed. Otherwise, the
response SHOULD NOT be compressed.
A proxy performing Record-Route inspects the Record-Route and the
Contact header fields in the response. It looks for the URI of the
next upstream (closer to the user agent client) hop in the route set.
If this URI contains the parameter comp=sigcomp, the proxy SHOULD add
comp=sigcomp to its entry in the Record-Route header field.
The same way, a user agent server SHOULD add comp=sigcomp to the
Contact header field of the response if the URI of the next upstream
hop in the route set contained the parameter comp=sigcomp.
G. Camarillo [Page 5]
Internet Draft SIP April 22, 2002
5 Error Situations
If a compressed SIP request arrives to a SIP server that does not
understand SigComp, the server will not have any means to indicate
the error to the client. The message will be impossible to parse, and
there will be no Via header field indicating an address to send the
error response.
If a SIP client sends a request and the client transaction times out
without having received any response, the client SHOULD retry the
same request without using compression. If the compressed request was
sent over a TCP connection, the client SHOULD close that connection
and open a new one to send the uncompressed request. Otherwise the
server would not be able to detect the beginning of the new message.
6 Augmented BNF
This section provides the augmented Backus-Naur Form (BNF) of both
parameters described above.
The compression URI parameter is a uri-parameter, as defined by the
SIP ABNF:
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
The Via compression parameter is a via-extension, as defined by the
SIP ABNF:
via-compression = "comp" EQUAL ("sigcomp" / other-compression)
other-compression = token
7 Security Considerations
A SIP entity receiving a compressed message has to decompress it and
to parse it. This requires slightly more processing power than only
parsing a message. This implies that a denial of service attack using
compressed messages would be slightly worse than an attack with
uncompressed messages.
8 Authors' Addresses
Gonzalo Camarillo
Ericsson
G. Camarillo [Page 6]
Internet Draft SIP April 22, 2002
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
9 Bibliography
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[2] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," Request for Comments 2915, Internet Engineering
Task Force, Sept. 2000.
[3] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments 2782,
Internet Engineering Task Force, Feb. 2000.
[4] R. Price, J. Rosenberg, C. Bormann, H. Hannu, and Z. Liu,
"Universal decompressor virtual machine (udvm)," Internet Draft,
Internet Engineering Task Force, Jan. 2002. Work in progress.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
G. Camarillo [Page 7]
Internet Draft SIP April 22, 2002
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
G. Camarillo [Page 8]