Network Working Group Hans Hannu, Ericsson (Editor) INTERNET-DRAFT Sweden Expires: June 2002 December 21, 2001 Signaling Compression Requirements & Assumptions 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 a submission of the IETF ROHC WG. Comments should be directed to its mailing list, rohc@cdt.luth.se. Abstract The purpose of this document is to outline requirements on a ROHC signaling compression scheme for compression and decompression of messages from signaling protocols, such as SIP/SDP. Hannu [Page 1] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 0. Document History - June 7, 2001, version 00. First version - July 06, 2001, version 01. Updated with additional requirements - September 05, 2001, version 02. Part of the problem draft, , has been included. Deleted requirements from previous version: Number 9 and 12. Changed requirements (previous->current): 13->6, 11->9, 6->10, 10-modified->7, 8-modified->8, 10-modified->7, 7-modified->11, New requirements: Number 3a and 12. - November 21, 2001, version 03. An assumption section, Section 4, is added to this version. New requirement: 6. Section 5.2 is clarified to be valid for both unreliable and reliable underlying transport. - December 21, 2001, version 04. A static dictionary useful for evaluation purposes is added to appendix A. The test sequence A2 has also been updated. Table of contents 1. Introduction..................................................3 1.2. Protocol characteristics....................................3 1.2.1. SIP.......................................................3 1.2.2. SDP.......................................................3 1.2.3. RTSP......................................................4 1.2.4. Protocol similarities.....................................4 1.3. Cellular system radio characteristics.......................4 2. Motivation for signaling reduction............................5 2.1. Estimation of Call Setup Delay using SIP/SDP................5 2.1.1. Delay results.............................................6 3. Alternatives for signaling reduction..........................7 4. Assumptions...................................................8 5. Requirements..................................................8 5.1. General requirements........................................9 5.2. Performance requirements...................................10 5.2.1. Robustness...............................................11 5.2.2. Compression efficiency...................................11 6. Security considerations.......................................12 7. IANA considerations...........................................12 8. Editor's address..............................................12 9. References....................................................12 Appendix A. Test sequences.......................................13 Hannu [Page 2] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 1. Introduction In wireless environments and especially in cellular systems, such as GSM/GPRS, there is a need to maximize the transport efficiency of data over the radio interface. The radio spectrum is rather expensive and must be carefully used. Therefore the cellular systems must support a sufficient number of users to make them economical feasible. Thus, there is a limitation in the per user bandwidth. Compressing the headers of the network and transport protocols used for carrying user data is one way to make more efficient use of the scarce radio resources [ROHC]. However, compression of the messages from signaling protocols, such as SIP/SDP, should also be considered to increase the radio resource usage even further. Compression will also improve the service quality, by reducing the user idle time, at e.g. call setup. When IP will be used end-to-end, new applications, such as streaming, will be brought to tiny end-host, such as cellular devices. This will introduce additional traffic in cellular systems. Compression of signaling messages, such as RTSP [RTSP], should also be considered to improve both the service availability and quality. New services with their corresponding signaling protocols make it reasonable to consider a scheme that is generic. The scheme should be generic in the meaning that the scheme efficiently can be applied to arbitrary protocols with certain characteristics, such as the ASCII based protocols SIP and RTSP. 1.2. Protocol characteristics The following application signaling protocols are expected to be commonly used in the future. Some of their characteristics are described below. 1.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. 1.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 Hannu [Page 3] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 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.³ 1.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. 1.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 e.g. 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. - They are generous in size in order to provide the necessary information to the session participants. - SIP and RTSP share many common header field names, methods and status codes. 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. 1.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 Hannu [Page 4] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 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 %. 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 it might be as high as 200 ms. 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. 2. Motivation for signaling reduction The need for solving the problems caused by the signaling protocol messages is exemplified in this chapter by looking at a typical SIP/SDP Call Setup sequence over a narrow band channel. 2.1 Estimation of Call Setup Delay using SIP/SDP Figure 2.1 shows an example of SIP signaling between two termination points with a wireless link between, 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 Hannu [Page 5] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 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 eventual intermediate IP-network into account. Even if this approximation is crude, it is still sufficient to provide representative numbers and enable comparisons. The message size given in Figure 2.1, is typical for a SIP/SDP call setup sequence. Client Network-Proxy Size [bytes] Time [ms] | | |---------- INVITE --------->| 620 517+70=587 | | |<-- 183 Session progress ---| 500 417+70=487 | | |---------- PRACK ---------->| 250 208+70=278 | | |<----- 200 OK (PRACK) ------| 300 250+70=320 : : |<...... RSVP and SM .......>| : : |---------- COMET ---------->| 620 517+70=587 | | |<----- 200 OK (COMET) ------| 450 | | + |<------ 180 Ringing --------| 230 567+70=637 | | |---------- PRACK ---------->| 250 208+70=278 | | |<----- 200 OK (PRACK) ------| 300 | | + |<--------- 200 OK ----------| 450 625+70=695 | | |----------- ACK ----------->| 230 192+70=262 Figure 2.1. SIP signaling delays assuming a link speed of 9600 bits/sec and a RTT of 140 ms. 2.1.1 Delay results Applying equation 1 to each SIP/SDP message shown in the example of Figure 2.1 gives a total delay of 4131 ms from the first SIP/SDP message to the last. The RSVP and Session Management (Radio Bearer setup), displayed in Figure 2.1 will add approximately 1.5 seconds to the total delay, using equation 1. However, there will also be RSVP and SM signaling prior to the SIP INVITE message to establish the radio bearer, which would add approximately another 1.5 seconds. Hannu [Page 6] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 In [TSG] there is a comparison between GERAN call setup using SIP and ordinary GSM call setup. For a typical GSM call setup the time is about 3.6 seconds, and for the case when using SIP, the call setup is approximately 7.9 seconds. Another situation that would benefit from reduced signaling is when carrying signaling messages over narrow bandwidth links in mid-call. For GERAN, this will result in frame stealing with degraded speech quality as a result. Thus, solutions are needed to reduce the signaling delay and the required bandwidth when considering both system bandwidth requirements and service setup delays. 3. Alternatives for signaling reduction More or less attractive solutions to 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, 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 in the short term. 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, Hannu [Page 7] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 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. Compared to the other possible solutions compression can be made, and must be, transparent to the end-user application. Thus, compression seems to be the most attractive way forward. 4. Assumptions - Negotiation How the usage of compression is negotiated is out of the scope for the compression solution and must be handled by e.g. the protocol which messages are to be compressed. - Reliable transport With reliable transport it is assumed a transport that recovers from data that is damaged, lost, duplicated, or delivered out of order, [TCP]. - Unreliable transport With unreliable transport it is assumed a transport that does not have the capabilities of a reliable transport. 5. Requirements This chapter states requirements for a signaling compression scheme to be developed in the IETF ROHC WG. The requirements are divided into two parts. Section 5.1 sets general requirements concerning the Internet infrastructure, while Section 5.2 sets requirements on the scheme itself. Hannu [Page 8] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 5.1. General requirements 1. Transparency: When a message is compressed and then decompressed the result must be bitwise identical to the original message Justification: This is to ensure that the compression scheme will not cause problems for any current or future part of the Internet infrastructure. Note: See also requirement 9. 2. Header compression coexistence: The compression scheme must be able to coexist with header compression, especially the ROHC protocol. Justification: Signaling compression is used because there is a need to conserve bandwidth usage. In that case, header compression will likely be needed too. 3a. Compatibility: The compression scheme must be constructed in such a way that it allows the above protocols' mechanisms to negotiate whether the compression scheme is to be applied or not. Justification: Two entities must be able to communicate regardless if the signaling compression scheme is implemented at both entities or not. 3b. Ubiquity: Modifications to the protocols generating the messages that are to be compressed, must not be required for the compression scheme to work. Justification: This will simplify deployment of the compression scheme. Note: This does not preclude making extensions, which are related to the signaling compression scheme, to existing protocols, as long as the extensions are backward compatible. 4. Generality: Compression of arbitrary message streams must be supported. The signaling compression scheme must not be limited to certain protocols, traffic patterns or sessions. It must not assume any message pattern to be able to perform compression. Justification: There might be a future need for compression of different ASCII based signaling protocols. This requirement will minimize future work. Hannu [Page 9] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 Note: This does not preclude optimization for certain streams. 5. Unidirectional routes: The compression scheme must be able to operate on unidirectional routes, i.e. without explicit feedback messages from the decompressor. Note: Implementations on unidirectional routes might possibly show a degraded performance compared to implementations on bi-directional routes. 6. Transport: The solution must work for both unreliable and reliable underlying transport protocols, e.g. UDP and TCP. Justification: The protocols, which generate the messages that are to be compressed, may use either an unreliable or a reliable underlying transport. Note: This should not be taken to mean that the same set of solution mechanisms must be used over both unreliable and reliable transport. 5.2. Performance requirements The performance requirements in this section and the following subsections are valid for both unreliable and reliable underlying transport. 7. Scalability: The scheme must be flexible to accommodate a range of compressors/decompressors with varying memory and processor capabilities. Justification: A primary target for the signaling compression scheme is cellular systems, where the mobile terminals have varying capabilities. 8. Delay: The signaling compression must not noticeably add to the delay experienced by the end user. Justification: Reduction of the user experienced delay is the main purpose of signaling compression. Note: This requirement is intended to prevent schemes that achieve compression efficiency at the expense of delay, i.e. queuing of messages to improve the compression efficiency should be avoided. The following requirements are grouped into two subsections, a robustness section and a compression efficiency section. Hannu [Page 10] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 5.2.1. Robustness The requirements in this section concern the issue when compressed messages should be correctly decompressed. The transparency requirement (first requirement), covers the issue with faulty decompressed messages. 9. Residual errors: The compression scheme must be resilient against errors undetected by lower layers, i.e. the probability of incorrect decompression caused by such undetected errors must be low. Justification: A primary target for the signaling compression scheme is cellular systems, were undetected errors might be introduced on the cellular link. 10. Error propagation: Propagation of errors due to signaling compression should be kept at an absolute minimum. Loss or damage to a single or several messages, between compressor and decompressor should not prevent compression and decompression of later messages. Justification: Error propagation reduces resource utilization and quality. 11. Delay: The compression scheme must be able to perform compression and decompression of messages under all expected delay conditions. 5.2.2. Compression efficiency This section states requirements related to compression efficiency. 12. Message loss: Loss or damage to a single or several messages, on the link between compressor and decompressor, should not prevent the usage of later messages in the compression and decompression process. 13. Moderate message misordering: The scheme should allow for correct decompression of messages, that have been moderately misordered (1-2 messages) between compressor and decompressor. The scheme should not prevent the usage of later message in the compression and decompression process. Justification: Misordering is frequent on the Internet, and this kind of misordering is common. Hannu [Page 11] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 6. Security considerations A protocol specified to meet these requirements must be able to cope with packets that has undergone security measures, such as encryption, without adding any security risks. This document by itself, however, does not add any security risks. 7. IANA considerations A protocol which meets these requirements may require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement. 8. Editor's Address Hans Hannu Tel: +46 920 20 21 84 Ericsson Erisoft AB Lulea, Sweden EMail: Hans.Hannu@epl.ericsson.se 9. References [ROHC] C. Bormann, Et. al., RObust Header Compression, RFC 3095, July 2001. [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. [UDP] J. Postel, User Datagram Protocol, RFC 761, August 1980. [TCP] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [TSG] Nortel Networks, A Comparison Between GERAN Packet-Switched Call Setup Using SIP and GSM Circuit-Switched Call Setup Using RIL3-CC, RIL3-MM, RIL3-RR, and DTAP, 3GPP TSG GERAN #2, GP-000508, 6-10 November 2000. Hannu [Page 12] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 Appendix A. Test sequences The SIP message sequences depicted in figure A1 and A2 together with the static dictionary, should be used to test the compression scheme for compression efficiency and processing and memory requirements. Call Setup delays should be calculated according to equation (1) in section 2.1. - Static dictionary Needed spaces are indicated with Needed carriage returns are indicated with Needed line feeds are indicated with All other possible spaces, carriage returns, line feeds etc, must be disregarded when using the static dictionary in your implementations. INVITEsip:SIP/2.0Via:SIP/2.0/UDP:5060 From:To:Call-ID:CSeq:1INVITE Contact:Content-Type:application/sdp Content-Length:0SIP/2.0100Trying SIP/2.0180RingingSIP/2.0200OK SIP/2.0181CallIsBeingForwarded SIP/2.0182QueuedSIP/2.0183SessionProgress PRACKsip:COMETsip:ACKsip:BYEsip:Accept:Accept- Encoding:Accept-Language:Allow:Authorization: Content-Encoding:Content-Length:Encryption: Expires:Hide:Contact:Max-Forwards: Proxy-Authenticate:Proxy-Authorization:Proxy-Require: Require:ResponseKey:Route:Timestamp: Unsupported:User-Agent:WWW-Authenticate:Supported: Remote-Party-ID:Proxy-Require:Anonymity: User A User B | | | INVITE F1 | |----------------------->| | (100 Trying) F2 | |<-----------------------| | 180 Ringing F3 | |<-----------------------| | | | 200 OK F4 | |<-----------------------| | ACK F5 | |----------------------->| | Both Way RTP Media | Hannu [Page 13] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 |<======================>| | | | BYE F6 | |<-----------------------| | 200 OK F7 | |----------------------->| | | Figure A1. From "draft-ietf-sip-call-flows-05.txt". Message Details: F1 INVITE User A -> User B INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 (100 Trying) User B -> User A SIP/2.0 100 Trying Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: 12345601@here.com CSeq: 1 INVITE Content-Length: 0 F3 180 Ringing User B -> User A SIP/2.0 180 Ringing Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=8321234356 Call-ID: 12345601@here.com CSeq: 1 INVITE Hannu [Page 14] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 Content-Length: 0 F4 200 OK User B -> User A SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=8321234356 Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F5 ACK User A -> User B ACK sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=8321234356 Call-ID: 12345601@here.com CSeq: 1 ACK Content-Length: 0 F6 BYE User B -> User A BYE sip:UserA@here.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy ;tag=8321234356 To: BigGuy Call-ID: 12345601@here.com CSeq: 1 BYE Content-Length: 0 F7 200 OK User A -> User B SIP/2.0 200 OK Via: SIP/2.0/UDP there.com:5060 From: LittleGuy ;tag=8321234356 To: BigGuy Call-ID: 12345601@here.com CSeq: 1 BYE Content-Length: 0 Hannu [Page 15] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 Entity A Entity B | | | INVITE F1 | |----------------------->| | (100 Trying) F2 | |<-----------------------| | 183 Session Progress F3| |<-----------------------| | PRACK F4 | |----------------------->| | 200 OK F5 | |<-----------------------| | COMET F6 | |----------------------->| | 200 OK F7 | |<-----------------------| | 180 Ringing F8 | |<-----------------------| | PRACK F9 | |----------------------->| | 200 OK F10 | |<-----------------------| | 200 OK F11 | |<-----------------------| | ACK F12 | |----------------------->| | Both Way RTP Media | |<======================>| Figure A2. From "3GPP TS 24.228 (v1.8.0 December/2001)". Message Details: F1 INVITE Entity A -> Entity B INVITE sip:+1-212-555-2222@home1.net;user=phone SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] Supported: 100rel Remote-Party-ID: ôJohn Doeö ;privacy=off Anonymity: Off From: ôAlien Blasterö ;tag=171828 To: sip:B36(SHA-1(+1-212-555-2222; time=36123E5B; seq=73))@localhost Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Contact: sip:[5555::aaa:bbb:ccc:ddd] Content-Type: application/sdp Content-Length: 586 Hannu [Page 16] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd b=AS:64 t=907165275 0 m=video 3400 RTP/AVP 98 99 a=qos:mandatory sendrecv a=rtpmap:98 H261 a=rtpmap:99:MPV m=video 3402 RTP/AVP 98 99 a=rtpmap:98 H261 a=rtpmap:99:MPV a=qos:mandatory sendrecv m=audio 3456 RTP/AVP 97 96 0 15 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv m=audio 3458 RTP/AVP 97 96 0 15 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv F2 (100 Trying) Entity A <- Entity B SIP/2.0 100 Trying Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ; tag=171828 To: sip:B36(SHA-1(+1-212-555-2222; time=36123E5B; seq=73))@localhost Call-ID: cb03a0s09a2sdfglkj490333 CSeq: 127 INVITE Content-Length: 0 F3 183 Session Progress Entity A <- Entity B SIP/2.0 183 Session Progress Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] Media-Authorization: 0020000100100101706366312e78797a2e6e6574000c02013942563330373200 Remote-Party-ID: ôJohn Doeö ;privacy=off;screen=yes Anonymity: Off Require: 100rel From: ôAlien Blasterö ;tag=171828 To: sip:B36(SHA-1(+1-212-555-2222; time=36123E5B; seq=73))@localhost;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Hannu [Page 17] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 CSeq: 127 INVITE Contact: sip:[5555::eee:fff:aaa:bbb] RSeq: 9021 Content-Disposition: precondition Content-Type: application/sdp Content-Length: 342 v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::eee:fff:aaa:bbb b=AS:64 t=907165275 0 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=audio 6544 RTP/AVP 97 96 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 G726-32/8000 a=qos:mandatory sendrecv confirm m=audio 0 RTP/AVP 97 96 0 15 F4 PRACK Entity A -> Entity B PRACK sip:[5555::eee:fff:aaa:bbb] SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 128 PRACK Rack: 9021 127 INVITE Content-Type: application/sdp Content-Length: 305 v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd b=AS:64 t=907165275 0 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=audio 3456 RTP/AVP 97 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=qos:mandatory sendrecv m=audio 0 RTP/AVP 97 96 0 15 F5 200 OK Entity A <- Entity B Hannu [Page 18] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 128 PRACK Content-Length: 0 F6 COMET Entity A -> Entity B COMET sip:[5555::eee:fff:aaa:bbb]SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 129 COMET Content-Type: application/sdp Content-Length: 303 v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::aaa:bbb:ccc:ddd b=AS:64 t=907165275 0 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=audio 3456 RTP/AVP 97 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=qos:success sendonly m=audio 0 RTP/AVP 97 96 0 15 F7 200 OK Entity A <- Entity B SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 129 COMET Content-Length: 0 F8 180 Ringing Entity A <- Entity B Hannu [Page 19] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 SIP/2.0 180 Ringing Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] Require: 100rel From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 CSeq: 127 INVITE Contact: sip:[5555::eee:fff:aaa:bbb] RSeq: RSeq: 9022 Content-Length: 0 F9 PRACK Entity A -> Entity B PRACK sip:[5555::eee:fff:aaa:bbb]SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 130 PRACK Rack: 9022 127 INVITE Content-Length: 0 F10 200 OK Entity A <- Entity B SIP/2.0 200 OK ia: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 130 PRACK Content-Length: 0 F11 200 OK Entity A <- Entity B SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 CSeq: 127 INVITE Contact: sip:[5555::eee:fff:aaa:bbb] Hannu [Page 20] INTERNET-DRAFT Signaling Compression req. & assumptions Dec. 21 , 2001 Content-Type: application/sdp Content-Length: 303 v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=- c=IN IP6 5555::eee:fff:aaa:bbb b=AS:64 t=907165275 0 m=video 0 RTP/AVP 99 m=video 0 RTP/AVP 99 m=audio 6544 RTP/AVP 97 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=qos:success sendrecv m=audio 0 RTP/AVP 97 96 0 15 F12 ACK Entity A -> Entity B ACK sip:[5555::eee:fff:aaa:bbb] SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: ôAlien Blasterö ;tag=171828 To: ;tag=314159 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 ACK Content-Length: 0 This Internet-Draft expires in June 2002. Hannu [Page 21]