Network Working Group Hans Hannu, Ericsson INTERNET-DRAFT Jan Christoffersson, Ericsson Expires: September 2001 Krister Svanbro, Ericsson Sweden March 2, 2001 Application signaling over cellular links 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the ROHC working group in IETF. Comments should be directed to the authors or to the ROHC mailing list (rohc@cdt.luth.se). Abstract This draft discusses problems arising when ASCII based application signaling protocols are used over cellular access channels. The protocols discussed are SIP, RTSP and SDP. An outline of an algorithm for compression of these protocols is given. Hannu, Christoffersson, Svanbro [Page 1] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 TABLE OF CONTENTS 1. Introduction..................................................4 2. Protocol characteristics......................................5 2.1. SIP.....................................................5 2.2. SDP.....................................................5 2.3. RTSP....................................................5 2.4. Protocol similarities...................................5 3. Cellular system radio characteristics.........................6 4. Problem description...........................................6 4.1. General.................................................7 4.2. Numerical example.......................................7 5. Possible solutions............................................8 6. Requirements on the compression scheme.......................10 6.1 General requirements...................................10 6.2 Performance requirements...............................11 7. General description of proposed compression method...........11 7.1 Existing compression methods...........................11 7.1.1 Field compression....................................11 7.1.2 Binary compression...................................12 7.1.3 IPComp...............................................12 7.2. Drawbacks with existing compression methods............12 7.3. Description of proposed solution.......................13 7.4. Compression efficiency.................................15 8. Relation to header compression...............................16 9. Conclusion...................................................16 Hannu, Christoffersson, Svanbro [Page 2] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 10. Security considerations......................................17 11. Intellectual property rights considerations..................17 12. Authors addresses...........................................17 13. References..................................................17 Hannu, Christoffersson, Svanbro [Page 3] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 1. Introduction Two communication technologies have become commonly used by the general public in the recent years: cellular telephony and the Internet. Cellular telephony has provided its users with the freedom of mobility - the possibility of always being reachable with reasonable service quality no matter where they are. However, until now the main service provided has been speech. With the Internet, the conditions have been almost the opposite. While flexibility for all kinds of usage has been its strength, its focus has been on fixed connections and large terminals, and the experienced quality of some services (such as Internet telephony) has generally been low. Due to new enhanced technologies this is about to change. Internet and cellular technologies are beginning to merge. Future cellular "phones" will contain an IP-stack and support voice over IP in addition to web-browsing, e-mail, etc. One could say that the Internet is going mobile, or that cellular systems are becoming much more than telephony depending on one's point of view. Commonly used terms in this technical area are "all-IP" and "IP all the way". These terms all relate to the case where IP is used end to end, even if the path involves cellular links, and IP is also run over the radio hop(s). This is done for all types of traffic, both the user data (e.g. voice or streaming) and control signaling data (e.g. SIP or RTSP). A great benefit of this is the service flexibility introduce by IP combined with the freedom provided by continuos mobility. A high cost, on the other hand, is the relative large overhead the IP protocol suite typically introduce, e.g. due to large headers and text-based signaling protocols. It is very important in cellular systems to use the scarce radio resources in an efficient way. It must be possible to support a sufficient number of users per cell, otherwise costs will be prohibitive [CELL]. Frequency spectrum and thus bandwidth are the most costly resources in cellular links and must be used carefully. Processing power is very cheap in comparison. Implementation or computational simplicity is therefore of less importance than bandwidth requirements and robustness against errors. The ROHC (RObust Header Compression) working group has successfully solved the problem of reducing bandwidth requirements for the header parts of e.g. RTP/UDP/IP packets. With this obstacle removed, new possibilities of enhancing mobile internet performance arise. One of these relates to application signaling protocols. Protocols such as SIP [SIP], SDP [SDP] and RTSP [RTSP] will typically be used to setup and control applications also in a mobile Internet. However, the protocol messages are generous in size and create delays due to their request/response nature. Compression of these messages should be considered in order to increase spectrum efficiency and reduce transmission delay. Hannu, Christoffersson, Svanbro [Page 4] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 2. Protocol characteristics The following application signaling protocols are the subject of study in this draft. 2.1 SIP The Session Initiation Protocol [SIP] is an application layer protocol for establishing, modifying and terminating multimedia sessions or calls. These sessions include Internet multimedia conferences, Internet telephony and similar applications. SIP can be used over either TCP [TCP] or UDP [UDP]. SIP is a text based protocol, using ISO 10646 in UTF-8 encoding. 2.2 SDP The Session Description Protocol [SDP] is used to advertise multimedia conferences and communicate conference addresses and conference tool specific information. It is also used for general real-time multimedia session description purposes. SDP is carried in the message body of SIP and RTSP messages. SDP is text based using the ISO 10646 character set in UTF-8 encoding. 2.3 RTSP The Real Time Streaming Protocol [RTSP] is an application level protocol for controlling delivery of data with real-time properties, such as audio and video. RTSP may use UDP or TCP (or other) as transport protocol. RTSP is text based using the ISO 10646 character set in UTF-8 encoding. 2.4 Protocol similarities The above protocols have many similarities. These similarities will have implications on solutions to the problems they create in conjunction with the cellular radio access. The similarities include: -Requests and reply characteristics. When a sender sends a request, it stays idle until it has received a response. Hence, it typically takes a number of round trip times to conclude e.g. a SIP session. -They are ASCII based. Thus to represent e.g. the value 230, 3 * 8 = 24 bits are used. A binary representation of the same value, by comparison, would require only 8 bits. -They are generous in size in order to provide the necessary information to the session participants. Hannu, Christoffersson, Svanbro [Page 5] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 -SIP and RTSP share many common methods, status codes and header field names. -The traffic patterns are also similar. The signaling is carried out primarily under the set up phase. For SIP this means that the majority of the signaling is carried out to set up a phone call or multimedia session. For RTSP the majority of the signaling is done before the transmission of application data. 3. Cellular system radio characteristics Partly to enable high utilization of cellular systems and partly due to the unreliable nature of the radio media, cellular links have characteristics that differ somewhat from a typical fixed link, e.g. copper or fiber. The most important characteristics are the lossy behavior of cellular links and the large round trip times. The quality in a radio system typically changes from one radio frame to another due to fading in the radio channel. Due to the nature of the radio media and interference from other radio users, the average bit error rate (BER) can be 10e-3 with a variation roughly between 10e-2 to 10e-4. To be able to use the radio media with its error characteristics, methods such as forward error correction (FEC) and interleaving are used. If these methods were not used, the BER of a cellular radio channel would be around 10 % [CELL]. Thus, radio links are by nature error prone. The final packet loss rate may be further reduced by applying low level retransmissions (ARQ) over the radio channel; this, however, trades decreased packet loss rate for a larger delay. By applying methods to decrease BER, the system delay is increased. In some cellular systems, the algorithmic channel round trip delay is in the order of 80 ms. Other sources of delays are DSP-processing, node-internal delay and transmission. A general value for the RTT is difficult to state, but, to give one example, 200 ms is mentioned in [CELL]. For cellular systems it is of vital importance to have a sufficient number of users per cell; otherwise the system cost would prohibit deployment. It is crucial to use the existing bandwidth carefully; hence the average user bit rate is typically relatively low compared to the average user bit rate in wired line systems. This is especially important for mass market services like voice. 4. Problem description The characteristics of cellular systems and the existing signaling protocols will together cause some problems. Hannu, Christoffersson, Svanbro [Page 6] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 4.1 General Figure 4.1 shows the scenario. The mobile uses Internet protocols for control of streaming flows, i.e. RTSP, and SIP for initiation of multimedia sessions. The characteristics of the cellular link with a limited user bit rate and fairly long system RTT cause a long call setup time with SIP and a long control time with RTSP because of their protocol characteristics. A numerical example is provided in the next section. mobile base fixed mobile or station network fixed terminal | ..... | | +--------+ | | ..... | ++ / +--+ | | +--+ / ++ || .....> || +-+ | || ....> || ++ /\ | | | /\ ++ / \----+-+------+---/ \-------------| <------------------- SIP/SDP, RTSP/SDP ----------------> Figure 4.1. Scenario. 4.2 Numerical example Figure 4.2 shows an example of SIP signaling between two terminals and the resulting delay under certain system assumptions. It should be noted that the used figures represent a very narrow band link even if e.g. a WCDMA system can provide maximum bit rates up to 2 Mbits/s in ideal conditions. However, this requires that one user consumes all radio resources in a cell. For a mass market service such as voice, it is always crucial to reduce the bandwidth requirements for each user. The one way delay is calculated according to the following equation: OneWayDelay = MessageSize[bits]/LinkSpeed[bits/sec] + RTT[sec] / 2 (eq. 1) The following values have been used: RTT/2: 70 ms LinkSpeed 9.6 kbps The delay formula is based on an approximation of a WCDMA radio access method for speech services. The approximation is rather crude. For instance, delays caused by possible retransmissions due to errors are ignored. Further, these calculations also assume that there is only one cellular link in the path and also take delays in an Hannu, Christoffersson, Svanbro [Page 7] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 eventual intermediate IP-network into account. Even if this approximation is crude, it is still sufficient to provide representative numbers and enable comparisons. Invitation UAC UAS Message size[bytes] Delay [ms] | | |-------- Invite --------------->| 517 500 | | |<------- 183 Session progress ---| 469 461 | | |-------- PRACK ----------------->| 234 265 | | |<------- 200 OK -----------------| 189 227 | | |<------- 180 Ringing ------------| 460 453 | | |-------- PRACK ----------------->| 234 265 | | |<------- 200 OK -----------------| 189 228 | | |<------- 200 OK -----------------| 453 448 | | |-------- ACK ------------------->| 205 240 Total 2950 3087 Figure 4.2. SIP signaling delays assuming a link speed of 9600 bits/sec and an RTT of 140 ms. Applying equation 1 to each message shown in the example in Figure 4.2 and summing up all delays gives a total delay of 3087ms from the first SIP message to the last. Thus, solutions are needed to reduce signaling delay and required bandwidth when considering both system bandwidth requirements and service setup delays. 5. Possible solutions More or less attractive solutions of the previously mentioned problems can be outlined: * Increase the user bit rate. An increase of the bit rate per user will decrease the number of users per cell. There exist systems (for example WCDMA) which can provide high bit rates and even variable rates for instance at setup of new sessions. However, there are also systems, e.g. GSM/EDGE, Hannu, Christoffersson, Svanbro [Page 8] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 where it is not possible to reach these high bit rates in all situations. At the cell borders, for example, the signal strength to noise ratio will be lower and result in a lower bit rate. In general, an unnecessary increase of the bit rate should be avoided due to the higher system cost introduced and the possibility of denial of service. The latter could for example be caused by lack of enough bandwidth to support sending of the large setup message within a required time period, which is set for QoS reasons. * Decrease the RTT of the cellular link Decreasing the RTT would require substantial system changes and is thus not feasible. Further, the RTT-delay due to interleaving and FEC will always have to be present regardless of which system is used. Otherwise the BER will be too high for the received data to be useful, or alternatively trigger retransmissions giving an average total delay of the same or higher magnitude. * Optimize message sequence for the protocols. If the request/response pattern could be eased up, then "keeping the pipe full" could be a way forward. Thus, instead of following the message sequence described in figure 4.2, more than one message would be sent in row, even though no response has been received. However, this would entail protocol changes and may be difficult at current date. * Protocol stripping. Removing fields from a message would decrease the size of the messages to some extent. However, this would cause loss of transparency and thus violate the End-to-End principle and is thus not desirable. * Compression. By compressing messages, the impact of the mentioned problems could be decreased. There is no requirement on compression on a per-hop basis. However, the flow must pass through the same entities where the compressor/decompressor resides during the session. The entities must also be aware of each other and as for header compression be able to negotiate that compression should be done. Thus, compression on a per-hop basis seems to be rather natural. With a compression factor (uncompressed/compressed) of e.g. 3 in the example considered in Section 4.2, the call setup time would decrease from 3087 ms to 1449 ms. The transparency problem would not be an issue if the compression scheme was carefully designed, so the scheme should be fully transparent. Hannu, Christoffersson, Svanbro [Page 9] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 6. Requirements on the compression scheme This section contains requirements for compression of ASCII based application signaling protocols. The requirements treat issues such as impact on the rest of the Internet infrastructure, what kind of messages and streams that must be compressed efficiently and what kind of performance the compression scheme should be able to deliver. The requirements have been divided into two broad categories: general and performance related requirements. 6.1 General requirements The compression must be transparent: when a message is compressed and then decompressed the result must be bitwise identical to the original message. The transparency must be maintained independently of what protocol that generated the message. This is to ensure that the compression scheme will not cause problems for any current or future part of the Internet infrastructure. The compression scheme must be able to coexist with the ROHC framework. Compression of IP/UDP and IP/TCP should be handled by other compression methods, like the existing ROHC profile for IP/UDP compression. Modifications to the protocols, which produce the messages that are to be compressed, must not be required for the compression scheme to work. This will simplify deployment of the compression scheme. Compression of arbitrary message streams must be supported. The compression scheme must not be limited to certain protocols, traffic patterns or sessions. This does not preclude optimization for certain streams. The compression scheme must be able to operate on unidirectional links, i.e. without explicit feedback messages from the decompressor. However, implementations on unidirectional links are expected to show a degraded performance. The compression scheme must be able to operate under all expected link delay conditions. The compression scheme must be able to operate under all expected packet loss conditions. The compression scheme must be able to operate under all expected residual bit error rate conditions. Hannu, Christoffersson, Svanbro [Page 10] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 6.2 Performance requirements The compression scheme should aim at minimizing transmission delay and maximizing the bitwise efficiency. Since there has been no work done that relates to compression of application signaling protocols it is difficult to find a suitable benchmark. The total delay, including processing time of the compression scheme, must decrease when compression is applied compared to sending the packets uncompressed on the same channel bandwidth. Error propagation must be minimized. A lost or damaged message must not prevent compression and decompression of later messages. Loss or damage to several messages should not prevent compression and decompression of later messages. The compression scheme should be able to compress and decompress when there are reordered messages reaching the compressor or decompressor. Reordering is frequent on the Internet, which implies that the compressor must be able to handle reordering. Depending on where the compressor entities reside, it can not be excluded that the decompressor must be able to handle reordering as well. 7. General description of proposed compression method An important feature needed in order for the proposed compression algorithm to be efficient and useful is a method to classify and separate flows, that is, a method for identifying the protocol type which is carried on top of IP/UDP or IP/TCP. This is a non elementary problem. One solution could be to look for certain protocol characteristic into the data transported by UDP or TCP. However, how to do this fast and reliable might be a problem. 7.1 Existing compression methods Different approaches for compression of the protocol messages are possible. 7.1.1 Field compression Compression of the messages could be done using field compression methods such as ROHC. Field compression methods are based on knowledge of the syntax of a specific protocol. Field compression is successful when applied to protocols where many header fields are Hannu, Christoffersson, Svanbro [Page 11] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 either static, are dependent on other header fields in the same packet or change in a predictable way between consecutive packets. 7.1.2 Binary compression Several binary compression algorithms are in use for general data file compression. These could possibly be used for the protocol compression discussed here. Huffman compression [HUFF] is a general method intended primarily for compression of ASCII files. Characters occurring frequently in the file are replaced by shorter codes, i.e. codes with less than the 8 bits used by the ASCII code. Huffman compression can be successful in files where relatively few characters are used. The first step when applying Huffman compression is to determine the new codes for the particular file being compressed. This code must also be used when decompressing the file. It is possible to use a fixed code for a sequence of messages; however, this would not give an optimal code for the specific message being compressed. Another widely used compression algorithm is the Lempel-Ziv [LZ77] algorithm. This algorithm operates by replacing character strings which have previously occurred in the file by references to the previous occurrence. This method is successful in files where repeated strings are common. This algorithm does not require any code to be sent to the decompressor. The well known compression programs Gzip and WinZip both use Lempel- Ziv compression followed by Huffman compression. 7.1.3 IPComp IPComp [IPComp] is a compression protocol for compression of IP [IP] payload and could hence be used for compression of SIP, SDP and RTSP. The protocol can use different compression methods, e.g. Lempel-Ziv, for the actual compression. The IPComp protocol specifies that each datagram is compressed independently of other datagrams. This is to ensure that received packets can be decompressed even if some previous packets are lost. 7.2 Drawbacks with existing compression methods Using field compression would be difficult or impossible since the studied protocols are similar to payload of IP/UDP and do not have any fixed header fields in a strict sense. That is, different protocol messages will have different fields with varying length. Hannu, Christoffersson, Svanbro [Page 12] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 A general prerequisite for successful compression using the above mentioned binary compression algorithms is that the file to be compressed is reasonably large, i.e. several kilobytes. This is a consequence of the compression algorithms. The codes for Huffman compression must not be too large compared to the file which is being compressed and the file must be large enough to have many repeated strings so that Lempel-Ziv compression becomes efficient. The messages produced by the protocols considered here are mostly a couple of hundred bytes and definitely not large enough to allow efficient compression with the mentioned algorithms on a message-by- message basis. IPComp compresses each datagram by itself without any relation to any other datagrams. This implies that efficient compression of these protocol messages using IPComp is not feasible. 7.3 Description of proposed solution The proposed solution is a framework which is robust to packet loss and will give efficient compression of messages. The approach taken here, is to compress the messages sequentially using previous messages from the same session. The compression algorithm used for compression is some, perhaps modified, version of the Lempel-Ziv algorithm. By appending a message to a previous message (dictionary), it becomes possible to replace strings in the message by references to occurrences in the previous messages. Updating of the dictionary can be done in different ways: *Append all new messages to the dictionary. This will increase the size of the dictionary throughout the session. In long sessions with large messages, the dictionary size might cause problems. *Append only new strings to the dictionary. This will also make the dictionary increase in size throughout the session, but at a slower rate. *Limit the size of the dictionary by keeping only the n most recently transmitted messages. This means that when the n+1 message of the session is appended to the dictionary, the first is removed. *Limit the size by using a sliding window of some predefined size. When a message appended to the dictionary makes the dictionary size exceed the window size by, say, x bytes, x bytes are removed from the beginning of the dictionary. Of course, a combination of these techniques is possible. The first message of the session does not have any previous message to use as dictionary. To compress this message efficiently a static Hannu, Christoffersson, Svanbro [Page 13] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 dictionary can be used containing strings that can be expected to occur, such as protocol field names, protocol token method, header field names, etc. This part of the dictionary should be kept during the entire session A potential difficulty with binary compression based on previous messages is how to obtain robustness to packet loss. It is essential that the message is decompressed using the same dictionary as the message was compressed with, otherwise the decompression will fail. Thus, a sent message can not be used to compress further messages until it is known that the message has been received at the other entity. This can be solved in different ways: *Entity 2 can send an acknowledgement to entity 1 that it has received a message and entity 1 can then use this message to compress new messages, see Figure 7.1. However, this is not necessary considering that the protocols (mostly) have a strict request/response pattern. Entity 1 Entity 2 | | |-------------m1,C(S)-------------->| |<.....................ACK,m1.......| | | |<------------m2,C(S)---------------| |.......ACK,m2.....................>| | | |-------------m3,C(S,m1)----------->| |<.....................ACK,m3.......| | | |<------------m4,C(S,m2)------------| |.......ACK,m4.....................>| Figure 7.1. Compression using special ACK messages. "m3,C(S,m1)" means message 3 (m3) compressed (C) using Static dictionary (S) and m1 as dictionaries. *If the compressor and the decompressor at one entity can communicate, then a header is appended to the compressed message. The header holds an identification number for the compressed message and an indication of which previous messages that have been received. Thus, no extra Acknowledgement message is needed. When this message is received by the decompressor the information in the header is passed to the compressor at the same entity, which then can use the indicated previous messages to improve the compression efficiency, see Figure 7.2. Hannu, Christoffersson, Svanbro [Page 14] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 Entity 1 Entity 2 | | |--------------m1,C(S)------------->| | | |<-------------m2,C(S),I(m1)--------| | | |--------------m3,C(S,m1),I(m2)---->| | | |<-------------m4,C(S,m2),I(m3)-----| Figure 7.2. Compression, with header indication. "I(m1)" means that entity 2 indicates in its message header that it has received m1. The scheme can be made even more efficient. If the compressor and decompressor at one entity can communicate and also share the dictionary (shared context), received messages, too, can be used to compress new messages. The received message can always be used as dictionary since it is certain that the message is known at the other entity. This is shown in Figure 7.3. Entity 1 Entity 2 | | |----------------m1,C(S)----------->| | | |<-----------m2,C(S,m1),I(m1)-------| | | |----------m3,C(S,m1,m2),I(m2)----->| | | |<-------m4,C(S,m1,m2,m3),I(m3)-----| Figure 7.3. Compression, with header indication and shared context. 7.4 Compression efficiency Compression efficiency of the proposed method depends among other things on the protocol type and the number of messages the session consists of. The first message will not be compressed very much, but the following messages will be compressed considerably. Some initial tests using the LZSS [LZSS] algorithm in the described compression scheme with shared context have indicated compression factors (original message size / compressed message size) of around 1.6 for the first message and 5-7 for messages at the end of the sessions. The over all compression factors of all the messages in the sessions taken together have been around 3-4. If the messages in the session of Figure 4.2. are compressed using the proposed compression algorithm (Figure 7.2) an over all compression factor of 4.4 is obtained. The individual messages are compressed in the range 1.7 to 8.5. Using the approximation of the delay in Section 3, with the compressed message sizes, a delay of Hannu, Christoffersson, Svanbro [Page 15] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 1180 ms was obtained - a reduction with almost 2/3 compared to the uncompressed case. 8. Relation to header compression A packet consists not only of application headers and application data, but also transport and network headers. Thus, attention should be paid to UDP/IP or TCP/IP as well. One suggestion could be to note that the first part of the packet is UDP/IP or TCP/IP and the second part is e.g. SIP/SDP. Thus, the first part is handled by e.g. ROHC and the second part is compressed by some method similar to the one described in this draft. However, this requires a method to separate signaling flows from ordinary UDP/IP and TCP/IP flows: see Chapter 6. Although virtually any protocol data could be compressed with this method, compression would not be efficient for other protocols that are not ASCII-based. Figure 8.1. shows a packet before and after compression. CMP is compressed information e.g. SIP, B is the possible header of the method handling the compression of the second part of the packet, and R is the ROHC header handling the first part of the packet. +--------+---------+ +---+---+----+ | IP/UDP | SIP/SDP |---- compression ---->| R | B | CMP| +--------+---------+ +---+---+----+ Figure 8.1. Packet before and after compression. To identify that a message has been compressed with a method, such as the one described in this draft, there are some alternatives depending on the environment. For example, a link layer identification method could be used, or in conjunction with ROHC, a profile number. 9. Conclusion This draft has identified an important problem which needs to be addressed. Using ASCII based signaling and control protocols over cellular access channels will result in long call setup times and long control times. Various possible solutions have been considered, such as increasing the user bit rate, shortening of the round trip time, optimizing message sequences or stripping the protocols. These methods, even if implementable, would lead to increased costs, changes of either systems or protocols or not be transparent. However, the proposed method seems to offer a tractable solution. A method for sequential binary compression of SIP and RTSP sessions has been described which is promising in terms of compression Hannu, Christoffersson, Svanbro [Page 16] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 efficiency and hence gives a substantial reduction in delay or needed bandwidth. Even though only SIP, SDP and RTSP are studied in this draft, the proposed compression method could be extended to other ASCII based protocols with similar characteristics, such as HTTP [HTTP]. 10. Security considerations This draft has discussed problems of some signaling protocols in the context of cellular system characteristics and requires no detailed security considerations at the present time. It should, however, be noted that encryption of e.g. SIP-data does not make the compression scheme outlined in this draft impossible in the same manner as encryption makes e.g. header compression impossible. However, encryption does make the outlined compression scheme much less efficient, since a static dictionary can not be used. 11. Intellectual property rights considerations Ericsson has filed patent applications that might possibly have technical relations to this contribution. See further: http://www.ietf.org/ietf/IPR/ERICSSON-General 12. Author's Addresses Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Lulea, Sweden EMail: Hans.Hannu@epl.ericsson.se Jan Christoffersson Tel: +46 920 20 28 40 Ericsson Erisoft AB Lulea, Sweden EMail: Jan.Christoffersson@epl.ericsson.se Krister Svanbro Tel: +46 920 20 20 77 Ericsson Erisoft AB Lulea, Sweden EMail: Krister.Svanbro@epl.ericsson.se 13. References [CELL] L. Westberg and M. Lindqvist, Realtime traffic over cellular access networks, Internet Draft (work in progress), November 2000. [HTTP] R. Fielding, et. al. Hypertext Transfer Protocol - HTTP/1.1. RFC 2616, June 1999. Hannu, Christoffersson, Svanbro [Page 17] INTERNET-DRAFT Application signaling over cellular links Mar 2, 2000 [HUFF] D. A. Huffman, A method for the construction of minimum- redundancy codes. Proc. Institute of Electrical and Radio Engineers. (9) 1952. [IP] J. Postel, Internet Protocol, RFC 791, September 1981. [IPComp] A. Shacham, Et. al. IP Payload Compression Protocol (IPComp) RFC 2393, December 1998. [LZSS] J.A. Storer and T.G. Szimanski, Data Compression via Textual Substitutions. Journal of the ACM 29, 1982. [LZ77] J. Ziv, and A. Lempel, A universal algorithm for sequential data compression. IEEE_Trans. Information Theory, IT-23, 1977. [RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time Streaming Protocol (RTSP). RFC 2326, April 1998. [SDP] M. Handley and V. Jacobson, SDP: Session Description Protocol. RFC 2327, April 1998. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, SIP: Session Initiation Protocol. RFC 2543, August 2000. [TCP] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [UDP] J. Postel, User Datagram Protocol, RFC 761, August 1980. This Internet-Draft expires in September 2001. Hannu, Christoffersson, Svanbro [Page 18]