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: 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]