draft-ietf-sip-compression-01.txt   draft-ietf-sip-compression-02.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft G. Camarillo Internet Draft G. Camarillo
Ericsson Ericsson
draft-ietf-sip-compression-01.txt draft-ietf-sip-compression-02.txt
September 17, 2002 October 29, 2002
Expires: March 2003 Expires: April 2003
Compressing the Session Initiation Protocol Compressing the Session Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 13 skipping to change at page 2, line 13
appropriate to send compressed SIP messages to a SIP entity. appropriate to send compressed SIP messages to a SIP entity.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
2 Overview of operation ............................... 4 2 Overview of operation ............................... 4
3 SigComp implementations for SIP ..................... 4 3 SigComp implementations for SIP ..................... 4
4 Sending a Request to a Server ....................... 4 4 Sending a Request to a Server ....................... 4
4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ....... 5 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ....... 5
5 Sending a Response to a Client ...................... 6 5 Sending a Response to a Client ...................... 6
6 Error Situations .................................... 7 6 Double Record-Routing ............................... 7
7 Augmented BNF ....................................... 7 7 Error Situations .................................... 7
8 Example ............................................. 7 8 Augmented BNF ....................................... 7
9 Security Considerations ............................. 10 9 Example ............................................. 8
10 Acknowledges ........................................ 10 10 Security Considerations ............................. 11
11 Authors' Addresses .................................. 10 11 Acknowledges ........................................ 11
12 Normative References ................................ 11 12 Authors' Addresses .................................. 11
13 Informative References .............................. 11 13 Normative References ................................ 11
14 Informative References .............................. 11
1 Introduction 1 Introduction
A SIP [1] client sending a request to a SIP server typically performs 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 [3] or SRV a DNS lookup for the domain name of the server. When NAPTR [3] or SRV
[4] records are available for the server, the client can specify the [4] records are available for the server, the client can specify the
type of service it wants. The service in this context is 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 transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP
server that support, for instance, three different transport server that supports, for instance, three different transport
protocols, will have three different DNS entries. protocols, will have three different DNS entries.
Since it is foreseen that the number of transport protocols supported Since it is foreseen that the number of transport protocols supported
by a particular application layer protocol is not going to grow by a particular application layer protocol is not going to grow
dramatically, having a DNS entry per transport seems like a scalable dramatically, having a DNS entry per transport seems like a scalable
enough solution. enough solution.
However, sometimes it is necessary to include new layers between the However, sometimes it is necessary to include new layers between the
transport protocol and the application layer protocol. Examples of transport protocol and the application layer protocol. Examples of
these layers are transport layer security and compression. If DNS was these layers are transport layer security and compression. If DNS was
skipping to change at page 4, line 40 skipping to change at page 4, line 40
Therefore, the presence of comp=sigcomp indicates that the SIP entity Therefore, the presence of comp=sigcomp indicates that the SIP entity
identified by the URI or by the Via header field supports SigComp and identified by the URI or by the Via header field supports SigComp and
is willing to receive compressed messages. Having comp=sigcomp mean is willing to receive compressed messages. Having comp=sigcomp mean
"willingness" as well as "support" allows the receiver of a SIP "willingness" as well as "support" allows the receiver of a SIP
message to influence the decision of whether or not to use SigComp at message to influence the decision of whether or not to use SigComp at
a given time. a given time.
3 SigComp implementations for SIP 3 SigComp implementations for SIP
Note that, as stated in [5], every implementation that supports Every SIP implementation that supports SigComp MUST implement the
SigComp needs to implement the static dictionary for SIP and SDP. procedures described in this document.
In addition, every SIP implementation that supports SigComp MUST
implement the procedures described in this document.
4 Sending a Request to a Server 4 Sending a Request to a Server
A request is sent to the host part of a URI. This URI, referred to as 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 next-hop URI, is the Request-URI of the request or an entry in
the Route header field. the Route header field.
If the next-hop URI contains the parameter comp=sigcomp, the client If the next-hop URI contains the parameter comp=sigcomp, the client
SHOULD compress the request using SigComp as defined in [2]. SHOULD compress the request using SigComp as defined in [2].
If the next-hop URI is a SIPS URI, the request MUST be compressed If the next-hop URI is a SIPS URI, the request SHOULD be compressed
before it is passed to the TLS layer. before it is passed to the TLS layer.
A client MUST NOT send a compressed request to a server if it does A client MUST NOT send a compressed request to a server if it does
not know whether or not the server supports SigComp. not know whether or not the server supports SigComp.
Regardless of whether the request is sent compressed or not, if a Regardless of whether the request is sent compressed or not, if a
client would like to receive subsequent requests within the same client would like to receive subsequent requests within the same
dialog in the UAS->UAC direction compressed, this client SHOULD add dialog in the UAS->UAC direction compressed, this client SHOULD add
the parameter comp=sigcomp to the URI in the Contact header field if 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 it is a user agent client. If the client is a proxy, it SHOULD add
skipping to change at page 6, line 6 skipping to change at page 5, line 52
to wait until the dialog is established in order to begin compressing to wait until the dialog is established in order to begin compressing
messages. One of the biggest gains that SigComp can bring to SIP is messages. One of the biggest gains that SigComp can bring to SIP is
the ability to compress the initial INVITE of a dialog, when the user the ability to compress the initial INVITE of a dialog, when the user
is waiting for the session to be established. Therefore, clients need is waiting for the session to be established. Therefore, clients need
a means to obtain a comp=sigcomp URI from their outbound proxy before a means to obtain a comp=sigcomp URI from their outbound proxy before
the user decides to establish a session. the user decides to establish a session.
One solution to this problem is manual configuration. However, One solution to this problem is manual configuration. However,
sometimes it is necessary to have clients configured in an automatic sometimes it is necessary to have clients configured in an automatic
fashion. Unfortunately, current mechanisms for SIP client fashion. Unfortunately, current mechanisms for SIP client
configuration (e.g., using DHCP [6]) do not allow to provide the configuration (e.g., using DHCP [5]) do not allow to provide the
client with URI parameters. In this case, the client SHOULD send an client with URI parameters. In this case, the client SHOULD send an
uncompressed OPTIONS request to its outbound proxy. The outbound uncompressed OPTIONS request to its outbound proxy. The outbound
proxy can provide an alternative SIP URI with the comp=sigcomp proxy can provide an alternative SIP URI with the comp=sigcomp
parameter in a Contact header field in a 200 OK response to the parameter in a Contact header field in a 200 OK response to the
OPTIONS. The client can use this URI for subsequent requests that are OPTIONS. The client can use this URI for subsequent requests that are
sent through the same outbound proxy using compression. sent through the same outbound proxy using compression.
RFC3261 [1] does not define how a proxy should respond to an OPTIONS RFC3261 [1] does not define how a proxy should respond to an OPTIONS
request addressed to itself. It only describes how servers respond to request addressed to itself. It only describes how servers respond to
OPTIONS addressed to a particular user. Section 11.2 of RFC3261 says: OPTIONS addressed to a particular user. Section 11.2 of RFC3261 says:
skipping to change at page 6, line 39 skipping to change at page 6, line 36
with comp=sigcomp in their registrar. All incoming requests for the with comp=sigcomp in their registrar. All incoming requests for the
user will be sent to this SIP URI using compression. user will be sent to this SIP URI using compression.
5 Sending a Response to a Client 5 Sending a Response to a Client
A response is sent to the host in the sent-by parameter of the Via 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 header field. If the topmost Via header field contains the parameter
comp=sigcomp, the response SHOULD be compressed. Otherwise, the comp=sigcomp, the response SHOULD be compressed. Otherwise, the
response MUST NOT be compressed. response MUST NOT be compressed.
A proxy performing Record-Route inspects the Record-Route header In order to avoid asymmetric compression (i.e., two SIP entities
field in the response and the Contact header field in the request exchanging compressed requests in one direction and uncompressed
that triggered this response (see example in Section 8). It looks for requests in the other direction) proxies need to rewrite their
the URI of the next upstream (closer to the user agent client) hop in Record-Route entries in the responses. A proxy performing Record-
the route set. If this URI contains the parameter comp=sigcomp, the Route inspects the Record-Route header field in the response and the
proxy SHOULD add comp=sigcomp to its entry in the Record-Route header Contact header field in the request that triggered this response (see
field. If this URI does not contain the parameter comp=sigcomp, the example in Section 9). It looks for the URI of the next upstream
proxy SHOULD remove comp=sigcomp (if it is present) from its entry in (closer to the user agent client) hop in the route set. If this URI
the Record-Route header field. contains the parameter comp=sigcomp, the proxy SHOULD add
comp=sigcomp to its entry in the Record-Route header field. If this
URI does not contain the parameter comp=sigcomp, the proxy SHOULD
remove comp=sigcomp (if it is present) from its entry in the Record-
Route header field.
The same way, a user agent server SHOULD add comp=sigcomp to the 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 Contact header field of the response if the URI of the next upstream
hop in the route set contained the parameter comp=sigcomp. hop in the route set contained the parameter comp=sigcomp.
6 Error Situations 6 Double Record-Routing
Although proxies usually add zero or one Record-Route entries to a
particular request, some proxies add two of them to avoid Record-
Route rewriting. A typical example of double Record-Routing is a SIP
proxy that acts as a firewall between two networks. Depending on
which network a request comes from, it will be received on a
different interface by the proxy. The proxy adds one Record-Route
entry for one interface and a second one for the other interface.
This way, the proxy does not need to rewrite the Record-Route header
field on the response.
Proxies that receive compressed messages from one side of the dialog
(e.g., upstream) and uncompressed messages from the other side (e.g.,
downstream) MAY use the mechanism described above.
If a proxy detects that the next-hop proxy for a request is the proxy
itself and that the request will not be sent through the network, the
proxy MAY choose not to compress the request even if the URI contains
the comp=sigcomp parameter.
7 Error Situations
If a compressed SIP request arrives to a SIP server that does not If a compressed SIP request arrives to a SIP server that does not
understand SigComp, the server will not have any means to indicate understand SigComp, the server will not have any means to indicate
the error to the client. The message will be impossible to parse, and 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 there will be no Via header field indicating an address to send the
error response. error response.
If a SIP client sends a compressed request and the client transaction If a SIP client sends a compressed request and the client transaction
times out without having received any response, the client SHOULD times out without having received any response, the client SHOULD
retry the same request without using compression. If the compressed retry the same request without using compression. If the compressed
request was sent over a TCP connection, the client SHOULD close that request was sent over a TCP connection, the client SHOULD close that
connection and open a new one to send the uncompressed request. connection and open a new one to send the uncompressed request.
Otherwise the server would not be able to detect the beginning of the Otherwise the server would not be able to detect the beginning of the
new message. new message.
7 Augmented BNF 8 Augmented BNF
This section provides the augmented Backus-Naur Form (BNF) of both This section provides the augmented Backus-Naur Form (BNF) of both
parameters described above. parameters described above.
The compression URI parameter is a "uri-parameter", as defined by the The compression URI parameter is a "uri-parameter", as defined by the
SIP ABNF (Section 25.1 of [1]): SIP ABNF (Section 25.1 of [1]):
compression-param = "comp=" ("sigcomp" / other-compression) compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token other-compression = token
The Via compression parameter is a "via-extension", as defined by the The Via compression parameter is a "via-extension", as defined by the
SIP ABNF (Section 25.1 of [1]): SIP ABNF (Section 25.1 of [1]):
via-compression = "comp" EQUAL ("sigcomp" / other-compression) via-compression = "comp" EQUAL ("sigcomp" / other-compression)
other-compression = token other-compression = token
8 Example 9 Example
The following example illustrates the use of the parameters defined The following example illustrates the use of the parameters defined
above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake
between a UAC and a UAS through two proxies. Proxy P1 does not between a UAC and a UAS through two proxies. Proxy P1 does not
Record-Route but proxy P2 does. Both proxies support compression, but Record-Route but proxy P2 does. Both proxies support compression, but
they do not use it by default. they do not use it by default.
UAC P1 P2 UAS UAC P1 P2 UAS
|(1)INVITE(c) | | | |(1)INVITE(c) | | |
skipping to change at page 10, line 26 skipping to change at page 11, line 4
Route:P2;comp=sigcomp Route:P2;comp=sigcomp
Contact: UAC;comp=sigcomp Contact: UAC;comp=sigcomp
The UAC sends the ACK (7) compressed directly to P2 (P1 did not The UAC sends the ACK (7) compressed directly to P2 (P1 did not
Record-Route). Record-Route).
(8) ACK UAS (8) ACK UAS
Via: P2 Via: P2
Via: UAC;comp=sigcomp Via: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp Contact: UAC;comp=sigcomp
P2 sends the ACK (8) uncompressed to the UAS. P2 sends the ACK (8) uncompressed to the UAS.
9 Security Considerations 10 Security Considerations
A SIP entity receiving a compressed message has to decompress it and A SIP entity receiving a compressed message has to decompress it and
to parse it. This requires slightly more processing power than only to parse it. This requires slightly more processing power than only
parsing a message. This implies that a denial of service attack using parsing a message. This implies that a denial of service attack using
compressed messages would be slightly worse than an attack with compressed messages would be slightly worse than an attack with
uncompressed messages. uncompressed messages.
An attacker inserting the parameter comp=sigcomp in a SIP message An attacker inserting the parameter comp=sigcomp in a SIP message
could make a SIP entity send compressed messages to another SIP could make a SIP entity send compressed messages to another SIP
entity that did not support SigComp. Appropriate integrity mechanisms entity that did not support SigComp. Appropriate integrity mechanisms
should be used to avoid this attack. should be used to avoid this attack.
10 Acknowledges 11 Acknowledges
Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia provided Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia provided
valuable comments on this memo. valuable comments on this memo.
11 Authors' Addresses 12 Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
electronic mail: Gonzalo.Camarillo@ericsson.com electronic mail: Gonzalo.Camarillo@ericsson.com
12 Normative References 13 Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[2] R. Price et al. , "Signaling compression," Internet Draft, [2] R. Price et al. , "Signaling compression," Internet Draft,
Internet Engineering Task Force, June 2002. Work in progress. Internet Engineering Task Force, June 2002. Work in progress.
13 Informative References 14 Informative References
[3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) [3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," RFC 2915, Internet Engineering Task Force, DNS resource record," RFC 2915, Internet Engineering Task Force,
Sept. 2000. Sept. 2000.
[4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," RFC 2782, Internet Engineering the location of services (DNS SRV)," RFC 2782, Internet Engineering
Task Force, Feb. 2000. Task Force, Feb. 2000.
[5] M. Garcia et al. , "The session initiation protocol (SIP) and [5] H. Schulzrinne, "DHCP option for SIP servers," Internet Draft,
session description protocol (SDP) static dictionary for signaling
compression (sigcomp)," Internet Draft, Internet Engineering Task
Force, July 2002. Work in progress.
[6] H. Schulzrinne, "DHCP option for SIP servers," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress. Internet Engineering Task Force, Mar. 2002. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/