Network Working Group T. Einarsson Internet-Draft M. Westerlund Intended status: Standards Track T. Lohmar Expires: June 24, 2007 I. Johansson Ericsson December 21, 2006 Multiple aggregated control URIs for RTSP draft-einarsson-mmusic-rtsp-macuri-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract By introducing multiple aggregated control URIs to be used with PLAY requests inside one single RTSP session, it is possible to switch content channel with minimal delay, since no new transport setup is needed. This is important for delivering TV-like services with short zapping times over unicast networks. Another important use case is hybrid unicast and broadcast distribution of live media, e.g. mobile Einarsson, et al. Expires June 24, 2007 [Page 1] Internet-Draft Multi-aggregated URIs for RTSP December 2006 TV. The possibility of this mechanism can be signalled implicitly using a standard SDP description for each content channel but with identical media control URIs, or by one common SDP description with a new attribute for multiple control URIs. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases and requirements . . . . . . . . . . . . . . . . . . 4 3.1. Content switch in unicast only network . . . . . . . . . . 4 3.2. Unicast and Broadcast clients . . . . . . . . . . . . . . 5 3.3. Hybrid unicast-broadcast scenario . . . . . . . . . . . . 5 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Design choices . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Channel selection signalling . . . . . . . . . . . . . . . 7 4.3. SDP syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Traditional SDP with identical MC URIs . . . . . . . . 9 4.3.2. One common SDP description with multiple AC URIs . . . 11 4.3.3. Comparison of the two SDP schemes . . . . . . . . . . 11 4.4. More complex use cases . . . . . . . . . . . . . . . . . . 12 4.4.1. Partial switch . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Different number of media for different content channels . . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Einarsson, et al. Expires June 24, 2007 [Page 2] Internet-Draft Multi-aggregated URIs for RTSP December 2006 1. Definitions 1.1. Glossary 3GP: 3GPP file format 3GPP: Third Generation Partnership Project AC URI: Aggregated Control URI BC: Broadcast DVB-H: Digital Video Broadcasting Handheld FE: Front End IGMP: Internet Group Management Protocol MC: Multicast MC URI: Media Control URI MBMS: Multimedia Broadcast/Multicast Service PSS: Packet-switched Streaming Service RTSP: Real Time Streaming Protocol SDP: Session Description Protocol UC: Unicast 2. Introduction Television services over IP networks are getting more and more popular, both in fixed and cellular networks. In cellular networks, the first TV services are using unicast radio bearers as e.g. the 3GPP standard PSS[PSS] which is essentially RTSP streaming with RTP media transport. One way of achieving a unicast TV service with multiple TV channels is to set up a new RTSP session to start to receive a new TV channel. Another is to control a server node in the network to switch content channel inside one RTSP session by switching content source and change the media packets to achieve continuous RTP streams. The latter has the advantage of fewer signalling round trips, but cannot be done with standard RTSP alone. Einarsson, et al. Expires June 24, 2007 [Page 3] Internet-Draft Multi-aggregated URIs for RTSP December 2006 However, there are also much efforts on providing broadcasted TV over IP to mobile devices. Two of the main standardization efforts are MBMS in 3GPP [MBMS] and DVB-H [DVB-H]. MBMS uses the cellular network in a special broadcasting mode. In doing so, a number of TV channels can be broadcasted, but given the relatively small sizes of the cells, it is only economically feasible to broadcast the most popular programs that have many viewers, while less popular programs are better delivered using unicast transport. DVB-H, on the other hand is a pure broadcast network, but even here it might be necessary to compliment with unicast delivery of less common channels or in cases where the broadcast coverage is not sufficient. In the 3GPP Release 7 work on MBMS, one has started to look into how to extend PSS to make fast content channel switching possible. Another issue is how to combine the extended PSS service with the broadcast TV service. The purpose of this document is to suggest an extension to RTSP which handles both these cases. 3. Use cases and requirements In this section we give a number of use cases and list the requirements they lead to. 3.1. Content switch in unicast only network In this use case, a unicast client has access to a number of content channels, and wants to be able to switch between the channels in as short time as possible. In the back end, some of the channels are provided from multicast sources and some from unicast sources. ----------- ----------- ------- | Unicast |<----- RTSP ---->| RTSP | |<------ RTP UC --| Ch1 | | Client |<-\ | FE | | ------- ----------- \ |------| |<---\ ------- \- RTP UC----| Switch |<-\ \- RTP MC --| Ch2 | ----------- \ ------- \ ------- \- RTP MC --| Ch3 | ------- Figure 1: Unicast client having access to 3 content channels using RTSP over Unicast Figure 1 depicts a unicast client with access to 3 channels. In the back end, channels 2 and 3 are sent via Multicast (MC) while channel 1 is a Unicast (UC) flow. RTSP is used to control the RTP Unicast sessions between the client and the server (switch). Einarsson, et al. Expires June 24, 2007 [Page 4] Internet-Draft Multi-aggregated URIs for RTSP December 2006 For cellular networks with rather long round-trip delays, two requirements that arise from this use case are: R1) Short channel switching time in terms of signalling round trips. R2) Obtain synchronization information for audio and video as early as possible after a channel switch. 3.2. Unicast and Broadcast clients As a first step of introducing broadcast distribution of content channels, the broadcast and unicast clients are separated. This was the case in Release 6 of MBMS. The unicast client has only access to unicast traffic due to e.g. roaming in another operator's network. ----------- ----------- | Unicast |<----- RTSP ---->| RTSP | | | Client |<-\ | FE | | ----------- \ |------| |<---\ ------- \- RTP UC----| Switch |<-\ \- RTP MC --| Ch1 | ------------- ----------- \ / ------- | Broadcast |<----------------------------/\ ------- | Client |<------------------------------\- RTP MC --| Ch2 | ------------- ------- Figure 2: Clients with multicast access session directly, while the first client uses RTSP over unicast In Figure 2 we have one broadcast client and one unicast client which can both view the same channels. For the Unicast (UC) case, RTSP is used to control the streams, while the broadcast client tunes in to different broadcast channels with different IP MC streams. This use case leads to no extra requirement since the broadcast and unicast clients are separated. 3.3. Hybrid unicast-broadcast scenario In this case, the most popular channel (Ch3) is only available via broadcast, the least popular channel (Ch1) is only available via unicast and the mid popular channel (Ch2) is available over broadcast or unicast depending on the number of viewers, or the popularity of the program that is currently sent. Einarsson, et al. Expires June 24, 2007 [Page 5] Internet-Draft Multi-aggregated URIs for RTSP December 2006 ----------- ----------- ------- | Hybrid |<----- RTSP ---->| RTSP | |<------ RTP UC --| Ch1 | | |<-\ | FE | | ------- | UC / BC | \ |------| | ------- | | \- RTP UC----| Switch |<----?- RTP MC --| Ch2 | | Client | ----------- / ------- | |<------------------------------/ ------- | |<--------------------------------- RTP MC --| Ch3 | ----------- ------- Figure 3: Hybrid Client accessing both RTSP over Unicast and Multicast session directly Figure 3 depicts a more optimized case where the distribution channels are different depending on the viewing patterns. The least popular channel (Ch1) is only available via UC, the mid popular Ch2 is sometimes available via UC and sometimes via BC, and the most popular Ch3 is only available via BC. Channels 1 and 3 imply no extra requirements, but Ch2 with its dynamic distribution mode poses the following requirements: R3) Possibility of seamless transition between broadcast and unicast. R4) Possibility of using the same media (RTP) encryption scheme for both broadcast and unicast. 4. Proposed solution An observation from the use cases above is that the transport settings can often be the same for all the content channels. Therefore, it would be enough to set up the transport via RTSP setup once, and then change the content channel without renegotiating the transport. 4.1. Design choices The requirements above lead to the following design choices for controlling the UC sessions: D1) Avoid full RTSP setup to minimize the signalling round trips (R1). Einarsson, et al. Expires June 24, 2007 [Page 6] Internet-Draft Multi-aggregated URIs for RTSP December 2006 D2) Do not use use a packet-modifying switch (R3 and R4). D3) Try to use the RTSP PLAY request since its response includes synchronization information via rtptime in the RTP-Info header (R2), and we need new synchronization information since we cannot modify the RTP header information according to D2. 4.2. Channel selection signalling The proposed design is to use RTSP PLAY requests inside an RTSP session to request a new TV channel (content source) via the RTSP front end in the switch, without renegotiating the transport. RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] section 11.4, states that a new PLAY request shall replace another, which fits nicely with our needs. The switch then starts sending the RTP streams for the new content channel and provides synchronization information including new SSRC values in the RTSP PLAY response to the client. The possibility to send SSRC in the RTP-Info header is another new feature of RTSP 2.0. To distinguish different channels, one can either introduce a new header or use different aggregated control URIs for each channel. Among these two, we propose to use multiple aggregated control URIs (AC URIs) since URIs have a well-defined syntax and it is easy to extend SDP or other session descriptions to include multiple URIs. Although more inline with the RTSP 2.0 framework, this can mechanism can be implemented on top of RTSP 1.0[RFC2326], since its presence can be signalled via a new feature tag "switch-on-play". This feature tag can be in the Supported header in the RTSP SETUP to interrogate the server capabilities, and then set in the Require header in the PLAY request when actually requesting a new content channel. If an RTSP resource has the common media control URIs: rtsp://example.com/videoTrack and rtsp://example.com/audioTrack, and the two channel-specific AC URIs rtsp://example.com/channel1 and rtsp://example.com/channel2, then a session might look like: Einarsson, et al. Expires June 24, 2007 [Page 7] Internet-Draft Multi-aggregated URIs for RTSP December 2006 C->S: SETUP rtsp://example.com/videoTrack RTSP/2.0 Supported: switch-on-play C->S: SETUP rtsp://example.com/audioTrack RTSP/2.0 Supported: switch-on-play C->S: PLAY rtsp://example.com/channel1 RTSP/2.0 Supported: switch-on-play followed by: C->S: PLAY rtsp://example.com/channel2 RTSP/2.0 Require: switch-on-play at a later point in time to change channel. The client will know already from the supported header in the server response for the first SETUP request whether the server supports this in-session switch of content channel. When switching to a broadcasted channel, the RTSP session may be paused by using any AC URI C-> S: PAUSE rtsp://example.com/channel2 RTSP/2.0 Going back to receiving any unicast channel is then simply accomplished by sending the request C->S: PLAY rtsp://example.com/channel1 RTSP/2.0 Require: switch-on-play A seamless transition between unicast and broadcast reception of the same channel can be achieved by receiving both streams during a short period to avoid missing packets, and then continue listening to the new distribution channel, while closing down the old. To be backwards compatible with clients not supporting multiple AC URIs, a default AC URI SHALL be available and otherwise the session description should be fully understandable for receiving the default content. However, this situation should only occur rarely, since sessions with multiple aggregated control URIs should only be offered from servers supporting this extension. 4.3. SDP syntax The most common way of defining the session is via an SDP description that can be fetched via an RTSP DESCRIBE request or provided by other means. The SDP syntax is described in the RTSP specifications. Einarsson, et al. Expires June 24, 2007 [Page 8] Internet-Draft Multi-aggregated URIs for RTSP December 2006 Often, the codec settings, e.g. defined by media sections in an SDP description, are the same for all channels. If that is the case, it should be possible to use one single SDP description for all the content channels. If the different channels have different encoding settings a slightly more complex setup with one joint SDP description with multiple RTP PT values for each media can be used. Finally, for more flexibility, one can consider individual SDP descriptions for each content channel. We propose two ways of using SDP descriptions, to signal the possibility of content channel switching using MAC URIs. The first is by using individual standard SDP descriptions, but with identical absolute media control URIs (MC URIs) together with different aggregated control URIs (AC URIs). The second is to use one single common SDP description but with a set of alternative AC URIs described via a new SDP attribute. 4.3.1. Traditional SDP with identical MC URIs The ordinary description of an RTSP resource (with aggregated control) contains one AC URI in the session part, as well as one MC URI for each media. These are all defined with an a=control line. The MC URIs are used for the transport setup, while the AC URI is used to control the (aggregated) session. An implicit straight-forward way of introducing the content channel switching within an RTSP session is to define that if two SDP descriptions have the same absolute MC URIs, then they can be switched between without a new setup. The different content channel shall then have different MAC URIs, and the client can request a switch to the second content channel by issuing a PLAY REQUEST with the MAC URI from the second SDP description. To be able to tell already from the first SDP that it can be used in a content channel context, a new SDP attribute "switch-context-id" SHOULD be used. Similar to the Session-Id, it should be random and at least 8 characters long. As an example, we could have two SDPs channel1.sdp and channel2.sdp whose control URIs would look like: Einarsson, et al. Expires June 24, 2007 [Page 9] Internet-Draft Multi-aggregated URIs for RTSP December 2006 channel1.sdp ... a=control:rtsp://server.com/channel1 a=switch-context-id:JIJljl3465 ... m=video 0 RTP/AVP 96 a=control:rtsp//server.com/videotrack ... m=audio 0 RTP/AVP 97 a=control:rtsp://server.com/audiotrack ... and channel2.sdp ... a=control:rtsp://server.com/channel2 a=switch-context-id:JIJljl3465 ... m=video 0 RTP/AVP 96 a=control:rtsp//server.com/videotrack ... m=audio 0 RTP/AVP 98 a=control:rtsp://server.com/audiotrack ... The ABNF [RFC4234] for this new SDP attribute is the following: switch-context-line = "a=switch-context-id:" switch-context-id switch-context-id = 8*( ALPHA / DIGIT ) Even though the actual encoding settings can be different and/or have different PT values in the two SDP descriptions above, the important thing is that the MC URIs are the same, so that it absolutely clear for the client that has both the SDP-descriptions that no new setup of the transport is needed. Since the SDP descriptions are fully backward compatible, current RTSP clients can simply follow the ordinary RTSP behaviour and do a new RTSP session setup when switching content channel. A potential problem is overlap in time of different SDPs. An old SDP may seem to give a possible alternative content channel, but is no longer valid. To avoid this, it is RECOMMENDED to signal the time of availability via the "t=" field in the SDP. Einarsson, et al. Expires June 24, 2007 [Page 10] Internet-Draft Multi-aggregated URIs for RTSP December 2006 4.3.2. One common SDP description with multiple AC URIs An ordinary SDP description for an RTSP resource with aggregated control contains exactly one AC URI, specified in the session part of SDP as: a=control: To ensure backwards compatible with non-extended clients, we propose to keep this unique control line, but add a new attribute "altcontrol", which can occur multiple times. The content channel that is associated with a specific alternative control URI is specified by other means, for example inside an Electronic Service Guide. In many cases, like time-limited TV channels, it is too restrictive to have a list of fixed AC URIs specified in an SDP description. Therefore, a mechanism that can tell that the possible control URIs are available by other means, and/or can be dynamic, is needed. To handle that case, an indicator value "dynamic" SHALL be used to signal that the possible altcontrol values are found by other means and may be dynamic. The ABNF [RFC4234] for this new SDP attribute is the following: altcontrol-line = "a=altcontrol:" control-type [sp rtsp-URI] control-type = "list" / "dynamic" / token rtsp-URI = The attributes on the session level in SDP may therefore look either as a=control:defaultchannel a=altcontrol:list channel1 a=altcontrol:list channel2 a=altcontrol:list channel3 or a=control:defaultchannel a=altcontrol:dynamic 4.3.3. Comparison of the two SDP schemes The advantages of the first scheme is a the flexibility of using a specific SDP description for each content channel, and that no change is needed in the SDP description at all. Therefore it is fully backwards compatible on the client side. Another advantage is that Einarsson, et al. Expires June 24, 2007 [Page 11] Internet-Draft Multi-aggregated URIs for RTSP December 2006 no extra parameters are needed to describe each content channel except its SDP description. The disadvantages is the overhead of having multiple SDP descriptions, and the extra round trip needed if the SDP description is not available at the time when the new content channel is desired. The second scheme has the advantage of necessitating only one SDP description and thereby having very little overhead. On the other hand, it is less flexible in that it cannot handle channels with new codec settings which were not known at start. Furthermore, if multiple codec settings are used for the same media, the client cannot know which codec setting is used for what channels. Finally, the description of each content channel may need both a common SDP description, and a specific MAC URI, which may add extra entries to an electronic service guide. Since there are pros and cons of both SDP schemes, we suggest that both are considered. 4.4. More complex use cases Two more complex use cases have been considered. One is the case where only some media are changed, e.g. the video for a different viewing angle is chosen. A second is the case where there are different number of media for different channels. 4.4.1. Partial switch In the partial switch case, a subset of media is switched, while the other media are typically kept continuous. This can be handled with the approach suggested here by simply having different AC URIs for each combination. When the client requests a change, the server will keep the unchanged media continuous (same SSRC), while the changed media might either come with a new SSRC (and even new PT according to the media settings) or be continuously inserted by the server. In the latter case SSRC is not changed, and it is preferrable that an CSRC value is used instead. In the case of a single SDP description with altcontrol parameters, the different combinations of media can simply be signalled by a AC URI pattern are built up by keys for the different media, like rtsp://server.com/ch1_video2_audio3. In the other case, with one SDP description per AC URI, it may happen that the number of combinations gets prohibitively large. If that is so, it might be better to use separate sessions for the different media. Einarsson, et al. Expires June 24, 2007 [Page 12] Internet-Draft Multi-aggregated URIs for RTSP December 2006 4.4.2. Different number of media for different content channels If multiple SDP descriptions are used, it may happen that some of them have more media than others. For example, there might be some sessions with audio and video, and some with audio, video, and subtitling. If the client has access to all the SDP descriptions, it is recommended to scan through them all and setup the maximum number of media. In case a new content channel provides a new SDP description with additional media compared to what is currently setup, the client may try to add another media transport channel by an additional RTSP SETUP before or after issuing a PLAY request for the new content channel. If the server replies with error code 455 "Method Not Valid In This State", the client must send a PAUSE request before trying again. 5. IANA Considerations The SDP attribute "altcontrol" with its special value "dynamic" as well as the feature tag "multiple-control-uris" need to be registered with IANA. 6. Security Considerations The security issues listed in RTSP [RFC2326], [I-D.ietf-mmusic-rfc2326bis] will apply also for this solution. There are a few additional issues with using multiple aggregated URIs. First, if using multiple SDP files it may be easier for an attacker to introduce a SDP file that results in a failure as clients may use only the media URIs in the SDP as sign on the availability of the functionality. To prevent this attack the SDP needs to be integrity protected and source authenticated. 7. Acknowledgements 8. References 8.1. Normative References [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., "Real Time Streaming Protocol 2.0 Einarsson, et al. Expires June 24, 2007 [Page 13] Internet-Draft Multi-aggregated URIs for RTSP December 2006 (RTSP)", draft-ietf-mmusic-rfc2326bis-13 (work in progress), June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 8.2. Informative References [DVB-H] DVB, "DVB-Handheld", 2006. [MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 6.4.0, 2006. [PSS] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and Codecs", 3GPP TS 26.234 6.7.0, 2006. Authors' Addresses Torbjorn Einarsson Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Email: torbjorn.einarsson@ericsson.com Magnus Westerlund Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Email: magnus.westerlund@ericsson.com Einarsson, et al. Expires June 24, 2007 [Page 14] Internet-Draft Multi-aggregated URIs for RTSP December 2006 Thorsten Lohmar Ericsson Ericsson Allee 1 Herzogenrath, D-52134 Germany Phone: +49-2407-5757816 Email: thorsten.lohmar@ericsson.com Ingemar Johansson Ericsson Laboratoriegrand 11 Lulea, SE-97128 Sweden Phone: +46-8-7190000 Email: ingemar.s.johansson@ericsson.com Einarsson, et al. Expires June 24, 2007 [Page 15] Internet-Draft Multi-aggregated URIs for RTSP December 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Einarsson, et al. Expires June 24, 2007 [Page 16]