Internet Engineering Task Force SIP WG
Internet Draft G. Camarillo
Ericsson
M. A. Garcia
Ericsson
draft-camarillo-sip-sigcomp-00.txt
February 21, 2002
Expires: May, 2002
SigComp discovery for SIP
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 defines a mechanism for SIP clients to discover SIP
servers that support signalling compression. DNS NAPTR records are
used for this purpose.
1 Introduction
SigComp [1] defines an architecture to compress signalling messages
generated by text-based protocols such as SIP [2]. A SIP entity
generates a SIP message and then passes it to the SigComp compressor.
The compressor compresses the message and sends it over the network
to the decompressor of the remote party. The decompressor
G. Camarillo et. al. [Page 1]
Internet Draft SIP February 21, 2002
decompresses the message and passes it to the SIP application.
However, before the first SIP compressed message can be sent, it is
necessary to discover whether or not the remote party supports
SigComp and the IP address and port number (including transport
protocol) where the decompressor expects to receive compressed SIP
messages.
Note that a particular server might support SigComp compression for
several application layer protocols such as HTTP, RTSP and SIP.
Decompressors for different protocols will typically use different
port numbers. Discovery of SigComp services for protocols other that
SIP is outside the scope of this document, although the mechanisms
described here can be trivially adapted for other protocols.
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3].
3 SigComp Discovery Using DNS NAPTR Records
[4] defines how to use DNS NAPTR [5] records to locate a SIP server.
The following values for the NAPTR service field are already defined
in [4]:
o SIP+D2T: SIP over TCP
o SIPS+D2T: SIP over TLS over TCP
o SIP+D2U: SIP over UDP
o SIP+D2S: SIP over SCTP
We define new values for the NAPTR service field:
o SIP+D2CT: SIP/SigComp over TCP
o SIPS+D2CT: SIP/SigComp over TLS over TCP
o SIP+D2CU: SIP/SigComp over UDP
o SIP+D2CS: SIP/SigComp over SCTP
A SIP client trying to locate a SIP server MUST follow the procedures
described in [4]. If these procedures result in a DNS query that
returns NAPTR records, the client can use the records with the new
G. Camarillo et. al. [Page 2]
Internet Draft SIP February 21, 2002
service field values defined above to contact the server using
SigComp. Note that after the NAPTR record is obtained, normal
processing as described in [5] is followed to obtain the IP address
and port number of the server. This typically involves an SRV query
[6], as described in [4].
3.1 Example
Assume that a client wants to contact sip:user@example.com. Since the
client uses a low bandwidth access, it wishes to use signalling
compression. The client performs a NAPTR query for the example.com
domain, and the following records are returned:
;; order pref flags service regexp replacement
IN NAPTR 100 100 "s" "SIP+D2T" "" _sip._tcp.school.edu
IN NAPTR 100 100 "s" "SIP+D2U" "" _sip._udp.example.com
IN NAPTR 100 100 "s" "SIP+D2CU" "" comp-udp.example.com
An SRV lookup of comp-udp.example.com would return:
;; priority weight port target
IN SRV 0 1 5062 server1.example.com
IN SRV 0 2 5062 server2.example.com
Note that once the IP address and the port number of the server have
been discovered, SigComp provides the necessary mechanisms to
exchange capabilities such as the UDVM (Universal Decompressor
Virtual Machine) version or the overall memory size of the
decompressor.
4 A Client Wishing to be Contacted Using SigComp
A SIP client informs its registrars about its current location using
the REGISTER request. A REGISTER request allows a SIP client to
provide a SIP registrar with different URIs where the user can be
reached. This URIs are carried in the Contact header field of the
REGISTER request.
A client that wishes to receive incoming SIP requests using SigComp
compression simply adds a transport parameter to the Contact header
field in the REGISTER as shown in the example below:
G. Camarillo et. al. [Page 3]
Internet Draft SIP February 21, 2002
Contact: <sip:Bob@client1.example.com;transport=comptcp>
This document defines the following transport parameters:
transport=comptcp SigComp over TCP
transport=compudp SigComp over UDP
transport=compsctp SigComp over SCTP
Note that a SIPS (secure SIP) URI with a transport=comptcp will be
contacted using SigComp over TLS over TCP.
OPEN ISSUE: This use of the transport parameter seems to
overload the transport parameter itself. We can come up
with a new URI parameter instead.
5 IANA Considerations
This document defines four new values to be added to the service
field values of the NAPTR record for SIP defined in [4].
Service Field Protocol
SIP+D2CT SigComp (RFC xxxx) over TCP
SIPS+D2CT SigComp (RFC xxxx) over TLS over TCP
SIP+D2CU SigComp (RFC xxxx) over UDP
SIP+D2CS SigComp (RFC xxxx) over SCTP
6 Acknowledgments
Hans Hannu and Jonathan Rosenberg provided valuable comments on this
document.
7 Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
Miguel Angel Garcia
G. Camarillo et. al. [Page 4]
Internet Draft SIP February 21, 2002
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Miguel.A.Garcia@ericsson.com
8 Bibliography
[1] R. Price, H. Hannu, et al. , "Signaling compression (sigcomp),"
Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in
progress.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[4] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers,"
Internet Draft, Internet Engineering Task Force, Jan. 2002. Work in
progress.
[5] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," Request for Comments 2915, Internet Engineering
Task Force, Sept. 2000.
[6] 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.
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
G. Camarillo et. al. [Page 5]
Internet Draft SIP February 21, 2002
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
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 et. al. [Page 6]