Network Working Group M. Garcia-Martin Request for Comments: 3485 Ericsson Category: Standards Track C. Bormann J. Ott TZI/Uni Bremen R. Price Siemens/Roke Manor A. B. Roach dynamicsoft February 2003
The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent.
Garcia-Martin, et al. Standards Track [Page 1]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
Table of Contents
1. Introduction.....................................................2 2. Design considerations............................................3 3. Binary representation of the SIP/SDP dictionary..................5 4. Security Considerations.........................................13 5. IANA Considerations.............................................13 6. Acknowledgements................................................14 7. References......................................................14 7.1 Normative References........................................14 7.2 Informative References......................................14 Appendix A. SIP input strings to the SIP/SDP static dictionary.....17 Appendix B. SDP input strings to the SIP/SDP static dictionary.....26 Authors' Addresses.................................................29 Full Copyright Statement...........................................30
SIP [3] and SDP [24] are text-based protocols that use the UTF-8 charset (RFC 2279 [5]). SIP and SDP were designed for rich bandwidth links. However, when SIP/SDP is run over narrow bandwidth links, such as radio interfaces or low speed serial links, the session setup time increases substantially, compared to an operation over a rich bandwidth link.
The session setup time can decrease dramatically if the SIP/SDP signaling is compressed. The signaling compression mechanisms specified in SigComp [1] provide a multiple compression/decompression algorithm framework to compress and decompress text-based protocols such as SIP and SDP.
When compression is used in SIP/SDP, the compression achieves its maximum rate once a few message exchanges have taken place. This is due to the fact that the first message the compressor sends to the decompressor is only partially compressed, as there is not a previous stored state to compress against. As the goal is to reduce the session setup time as much as possible, it seems sensible to investigate a mechanism to boost the compression rate from the first message.
In this memo we introduce the static dictionary for SIP and SDP. The dictionary is to be used in conjunction with SIP, SDP and SigComp. The static SIP/SDP dictionary constitutes a SigComp state that can be referenced in the first SIP message that the compressor sends out.
Garcia-Martin, et al. Standards Track [Page 2]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
The static SIP/SDP dictionary is a collection of well-known strings that appear in most of the SIP and SDP messages. The dictionary is not a comprehensive list of reserved words, but it includes many of the strings that appear in SIP and SDP signaling.
The static dictionary is unique and MUST be available in all SigComp implementations for SIP/SDP. The dictionary is not intended to evolve as SIP or SDP evolve. It is defined once, and stays as is forever. This solves the problems of updating, upgrading and finding out the dictionary that is supported at the remote end when several versions of the same dictionary coexist.
Appendix A contains the collection of strings that SIP contributed to the static dictionary. The appendix includes references to the documents that define those strings.
Appendix B contains the collection of strings that SDP contributed to the static dictionary. Again, the appendix includes references to the documents that define those strings.
While these appendices are of an informative nature, Section 3 gives the normative binary form of the SIP/SDP dictionary. This is the dictionary that is included in the SigComp implementation. This dictionary has been formed from the collection of individual dictionaries given in appendices A and B.
The two input collections are collections of UTF-8 encoded character strings. In order to facilitate the readability, the appendices describe them in one table for each collection. In these tables, each row represents an entry. Each entry contains the string that actually occurs in the dictionary, its priority (see below), its offset from the first octet and its length (both in hexadecimal), and one or more references that elucidate why this string is expected to occur in SIP/SDP messages. Note: Length in this document always refers to octets.
The columns in the tables are described as follows:
String: represents the UTF-8 string that is inserted into the dictionary. Note that the quotes (") are not part of the string itself. Note also that the notation [CRLF] represents a Carriage Return character (ASCII code 0x0D) followed by a Line Feed character (ASCII code 0x0A).
Garcia-Martin, et al. Standards Track [Page 3]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
Pr: indicates the priority of this string within the dictionary. Some compression algorithms, such as DEFLATE, offer an increased efficiency when the most commonly used strings are located at the bottom of the dictionary. To facilitate generating a dictionary that has the most frequently occurring strings further down at the bottom, we have decided to allocate a priority to each string in the dictionary. Priorities range from 1 until 5. A low number in the priority column (e.g., 1) indicates that we believe in a high probability of finding the string in SIP or SDP messages. A high number in the priority column (e.g., 5) indicates lower probability of finding the string in a SIP or SDP message. This is typically the case for less frequent error codes or optional infrequent tags.
Off: indicates the hexadecimal offset of the entry with respect to the first octet in the dictionary. Note that several strings in the collections can share space in the dictionary if they exhibit suitable common substrings.
Len: the length of the string (in octets, in hexadecimal).
References: contains one or more references to the specification and the section within the specification where the string is defined.
Note that the strings stored in the dictionary are case sensitive. (Again, the strings do not comprise the quotes ("), they are just shown here to increase the readability.) Where the string is a header field, we also included the colon ":" and the amount of white space expected to occur. Note that this means that not all messages that conform to the SIP Augmented BNF, which allows other combinations (e.g., a white space or horizontal tabulator before the colon (":") sign), will benefit as much from the dictionary -- the best increase in compression performance is to be expected for messages that use the recommended formatting guidelines for SIP.
Some strings appear followed by an equal sign and some others do not. This depends on whether the string is part of a parameter name or a parameter value.
In a SIP message, all the SIP headers terminate with a CRLF pair of characters. As these characters are appended to the end of each SIP header line, right after the header values, and because the header values are typically not part of the static SIP dictionary, we cannot include the terminating CRLF as part of the SIP static dictionary. Instead, the approach we have taken is to include in each header field entry the CRLF from the previous line that prefixes every header field. We have represented CRLF by the notation [CRLF]. Therefore, in generating the actual binary dictionary, an entry in the dictionary represented as: "[CRLF]From: " has been interpreted as
Garcia-Martin, et al. Standards Track [Page 4]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
an entry whose value is CR, LF, the word From, a colon and a whitespace.
Note that most SIP header field names are included with the full string from CRLF to the colon-blank pair. However, in certain situations, when the likelihood of occurrence is not considered high (as indicated by a priority value of 3 to 5), and when there are common substrings shared by a number of headers, we have added one entry with the common substring and several entries with the non- common substrings remaining. An example is the "Proxy-Authenticate" and "Proxy-Authorization" headers. There are three entries in the dictionary: the common substring "[CRLF]Proxy-", and the non-common substrings "Authenticate: " and "Authorization: ". This allows the re-use of the non-common substrings by other entries and may save a number of bytes in the binary form of the dictionary. Note that this splitting mechanism does not apply with strings that are likely to occur very often (those whose priority is set to 1 or 2).
SIP responses start with a status code (e.g., "302") and a reason phrase (e.g., "Moved Temporarily"). The status code is a normative part, whereas the reason phrase is not normative, it is just a suggested text. For instance, both "302 Moved Temporarily" and "302 Redirect" are valid beginnings of SIP responses.
In the SIP dictionary we have included two entries per response code, one including only the status code and a space (e.g., "302 ") and another one including both the status code and the suggested reason phrase (e.g., "302 Moved Temporarily"). The former can be used when the SIP response changed the suggested reason phrase to another one. The latter can be used when the suggested reason phrase is part of the response. In this way, we accommodate both alternatives. (Note that in the actual dictionary, both strings occupy the same space in the string subset, but have two separate entries in the table subset.)
3. Binary representation of the SIP/SDP dictionary
This section contains the result of combining the SIP and the SDP dictionaries described in appendices A and B in order to create a single dictionary that is loaded into SigComp as a state.
The binary SigComp dictionary is comprised of two parts, the concatenation of which serves as the state value of the state item: A string subset, which contains all strings in the contributing collections as a substring (roughly ordered such that strings with low priority numbers occur at the end), and a table subset, which contains pairs of length and offset values for all the strings in the contributing collections. In each of these pairs, the length is
Garcia-Martin, et al. Standards Track [Page 5]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
stored as a one-byte value, and the offset is stored as a two-byte value that has had 1024 added to the offset (this allows direct referencing from the stored value if the dictionary state has been loaded at address 1024).
The intention is that all compression algorithms will be able to use the (or part of the) string subset, and some compression methods, notably those that are related to the LZ78 family, will also use the table in order to form an initial set of tokens for that compression method. The text below therefore gives examples for referencing both the table subset and the string subset of the dictionary state item.
As defined in section 3.3.3 in the Signaling Compression specification [1], a SigComp state is characterized by a certain set of information. For the static SIP/SDP dictionary, the information in the following Table 1 fully characterizes the state item.
Note that the string subset of the dictionary can be accessed using:
STATE-ACCESS (%ps, 6, 0, 0x0D8C, %sa, 0),
and the table subset can be accessed using:
STATE-ACCESS (%ps, 6, 0x0D8C, 0x0558, %sa, 0),
where %ps points to UDVM memory containing
0xfbe507dfe5e6
and %sa is the desired destination address in UDVM memory (with UDVM byte copying rules applied).
If only a subset of the dictionary up to a specific priority is desired (e.g., to save UDVM space), the values for the third and forth operand in these STATE-ACCESS instructions can be changed to:
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
The state item consists of the following elements:
Name: Value: ===================== ======================== state_identifier 0xfbe507dfe5e6aa5af2abb914ceaa05f99ce61ba5 state_length 0x12E4 state_address 0 (not relevant for the dictionary) state_instruction 0 (not relevant for the dictionary) minimum_access_length 6 state_value Representation of the table below.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[7] Vaha-Sipila, A., "URLs for telephone calls", RFC 2806, April 2000.
[8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[9] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[11] Rosenberg, J., "The Session Initiation Protocol UPDATE Method", RFC 3311, October 2002.
[12] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[13] Sparks, R., "The SIP Refer Method", Work in Progress.
Garcia-Martin, et al. Standards Track [Page 14]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
[14] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", Work in Progress.
[15] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[16] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[17] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[18] Donovan, S., and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", Work in Progress.
[19] Niemi, A., Arkko, J. and V. Torvinen , "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[20] Arkko, J., Torvinen, V., Camarillo, G., Niemi A. and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[22] Schulzrinne, H. and J. Rosenberg, "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", Work in Progress.
[23] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[24] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", Work in Progress.
[25] Sjoberg, J., Westerlund, M., Lakaniemi, A. and Q. Xie, "Real- Time Transport Protocol payload format and file storage format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs", RFC 3267, June 2002.
[26] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
Garcia-Martin, et al. Standards Track [Page 15]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
[27] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[28] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "Key Management Extensions for SDP and RTSP", Work in Progress.
[29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", Work in Progress.
[30] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. and D. Oran, "The Secure Real Time Transport Protocol", Work in Progress.
[31] Ott, J., Wenger, S., Fukunaga, S., Sato, N., Burmeister, C., and Rey, J., "Extended RTP Profile for RTCP-based feedback (RTP/AVPF)", Work in Progress.
[32] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[33] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[34] Sparks, R., "The Referred-By mechanism", Work in Progress.
[35] Willis, D. and B. Hoeneisen, "Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration", Work in Progress.
Garcia-Martin, et al. Standards Track [Page 16]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
Appendix A. SIP input strings to the SIP/SDP static dictionary
For reference, this section lists the SIP input strings that were used in generating the dictionary, as well as a priority value, the offset of the string in the generated dictionary, the length of the string, and one or more references into the referenced documents that motivate the presence of this string. Note that the notation "[CRLF]" stands for a sequence of two bytes with the values 0x0d and 0x0a, respectively.
The priority value is used for determining the position of the string in the dictionary. Lower priority values (higher priorities) cause the string to occur at a later position in the dictionary, making it more efficient to reference the string in certain compression algorithms. Hence, lower priority values were assigned to strings more likely to occur.
Table A.1: SIP input strings for the SIP/SDP dictionary
Garcia-Martin, et al. Standards Track [Page 25]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
Appendix B. SDP input strings to the SIP/SDP static dictionary
For reference, this section lists the SDP input strings that were used in generating the dictionary, as well as a priority value, the offset of the string in the generated dictionary, the length of the string, and one or more references into the referenced documents that motivate the presence of this string. Note that the notation "[CRLF]" stands for a sequence of two bytes with the values 0x0d and 0x0a, respectively.
The priority value is used for determining the position of the string in the dictionary. Lower priority values (higher priorities) cause the string to occur at a later position in the dictionary, making it more efficient to reference the string in certain compression algorithms. Hence, lower priority values were assigned to strings more likely to occur.
Adam Roach dynamicsoft 5100 Tennyson Parkway, Suite 1200 Plano, TX 75024, USA
EMail: adam@dynamicsoft.com
Garcia-Martin, et al. Standards Track [Page 29]
RFC 3485 SIP and SDP Static Dictionary for SigComp February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.