MMUSIC Working Group B. Van Doorselaer Internet Draft D. Ooms Document: Alcatel Category: Informational July 2000 SIP for the establishment of xcast-based multiparty conferences Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract Explicit Multicast (xcast) is a multicast scheme that uses an explicit list of destinations instead of one logical multicast address. Explicit Multicast complements the existing multicast schemes in that it can efficiently support very large numbers of distinct (small) multicast groups and thus can play an important role in making multicast practical for applications such as multiparty IP telephony, various conferencing & collaborative applications, multiparty networked games, etc... This document explains how multiparty IP telephony conferences making use of xcast can be established by SIP carrying SDP. Some open issues will be identified and discussed. Possible extensions to SIP and SDP to streamline the use of xcast will be suggested as well. 2. Conventions used in this document 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 [2]. Van Doorselaer Informational - Expires January 2001 1 July 2000 3. Introduction Explicit Multicast (xcast) [3] is a group of multicast schemes (CLM [4], MDO6 [5], SGM [6]) that use an explicit list of destinations instead of one logical multicast address. This approach should be complementary to the current multicast schemes. While today's multicast schemes are scaleable in the sense that they can support very dense multicast groups, they are however pretty expensive when a network needs to support a very large number of those. Explicit Multicast complements the existing multicast schemes in that it can efficiently support very large numbers of distinct (small) multicast groups and thus can play an important role in making multicast practical for applications such as multiparty IP telephony, various conferencing & collaborative applications, multiparty networked games, etc... Multiparty IP telephony is a typical example where very large numbers of distinct and small multicast groups may exist. The number of participants in multiparty IP telephony calls can be qualified as small (typically 3 or 4 participants) and large numbers of these multiparty calls may be independently active at the same time. These multiparty IP telephony calls may be established with SIP (Session Initiation Protocol, RFC 2543 [7]). SIP carrying SDP (Session Description Protocol, RFC 2327 [8]) will convey the necessary address (i.e. IP (RFC 791 [9]) addresses) and transport (i.e. UDP (RFC 768 [10]) port numbers) information to the terminals of the call participants so that these will be able to construct the xcast header information. In the following chapters, it will become clear that SIP and xcast go amazingly well together. The marriage of SIP and xcast introduces the benefits of a simple multicast scheme (that does not suffer from problems that are introduced by the classical multicast schemes) in conjunction with a simple call / conference establishment protocol. 3.1 Overview of SIP-based multiparty conferencing schemes Different types of multiparty conferencing schemes can be supported by SIP, as described also in [11] and [12]. These include: 1. Conference bridge. Every participant in the conference has to dial the conference bridge. The conference is identified by the request Uniform Resource Identifier (URI). Once the conference has been established, every participant will send its media (audio and video) to the conference bridge. The conference bridge will mix the signals and distribute them to the conference participants. This scheme works with baseline SIP; no extensions to SIP are needed. Drawbacks: Van Doorselaer Informational - Expires January 2001 2 July 2000 @ An additional central network element (i.e. the conference bridge) is needed (which will also be the Single Point Of Failure) A special case of this conference bridge scenario is the multiparty conference with a local bridge function. In this scenario, the initiator of the conference will also act as the conference bridge. This also works with baseline SIP. Drawbacks: @ The conference participant acting as the conference bridge remains the Single Point Of Failure @ There will be an additional processing burden (i.e. mixing the audio and video signals from the different sources and redistributing them) for the conference participant acting as the conference bridge. 2. Distributed multiparty conferencing, without use of any central server. This type of conference is fully distributed: a full mesh of RTP (Real-time Transport Protocol, RFC 1889 [13]) sessions is established between the conference participants. Drawbacks: @ Inefficient in terms of network resources (bandwidth), certainly when the uplink bandwidth for the participants is limited. This drawback applies typically when users are connected via asymmetric links to the network (where downlink capacity from the network to the user is abundant, but uplink capacity from the user to the network is limited). 3. Classical multicast conference. The initiator of the conference simply INVITEs the other persons to join the multicast session. This works with baseline SIP, since this was in fact the initial purpose of SIP. However, before the conference can be established, the initiator has to obtain a multicast address that will be used by the conference. Drawbacks: @ Before the conference can be established, the initiator has to obtain a multicast address that will be used by the conference. Multicast address allocation leads to quite complex schemes. @ Multicast introduces additional state information in the network. This draft therefor introduces a fourth type of multiparty conference scheme. 4. Xcast conference. The Xcast conference looks very much like a distributed multiparty conference, but the xcast multicast scheme is used by the participants instead of the unicast scheme. A full mesh of RTP sessions is established, while xcast Van Doorselaer Informational - Expires January 2001 3 July 2000 is used to deliver identical RTP datagrams sent from a single sender to multiple receivers. For the remainder of this document, this last scheme (Xcast conferencing) will be worked out and explained in more detail. 3.2 Use of SDP in xcast SIP defines in annex B the "Usage of the Session Description Protocol (SDP)". A difference is made between the use of SIP/SDP for unicast conferences (as defined in annex B.2 of SIP "Setting SDP Values for Unicast") and the use of SIP/SDP for multicast conferences (as defined in annex B.3 of SIP "Multicast Operation"). Since in the xcast scheme receivers are not aware of the fact that xcast has been used by the sender (*) and that the IP xcast packets have been transformed by the intermediate IP routers in normal IP unicast packets before they are delivered to the receiver, we have to assume that the unicast SDP usage rules apply. (*) Note: Xcast is a new multicast scheme. At this moment we assume that the receivers cannot make a difference between unicast packets and xcast packets and that xcast is hence completely transparent for the receivers. However, with the introduction of IPSEC it could be possible that receivers will see the full xcast header and that this assumption of transparency is not valid any more. We could envisage a separate SDP usage scheme for xcast (next to the SDP usage schemes for unicast and multicast), but this would introduce another dimension of complexity, since for every packet received the receiver should be able to distinguish between a native unicast packet and an originally-created-xcast-but-tranformed-by- the-intermediate-routers-into-a-normal-unicast packet. From now on, we will hence assume that receivers are unable to distinguish between xcast and unicast packets. As a consequence, the unicast SDP usage rules apply. We will further analyse how this impacts the SIP / SDP based xcast conference setup mechanisms. 3.2.1. Use of UDP in xcast @ When the header of the xcast packet contains a list of IP addresses, the same UDP port number needs to be used for all recipients, i.e. the UDP port number is copied along with the payload in each IP packet. In other words, the header of this type of xcast packet will contain all the individual IP addresses of the correspondents that are entitled to receive this packet. The different unicast IP packets generated from such an IP xcast packet only differ in their destination IP address. From now on we will call this the simple xcast scheme. Van Doorselaer Informational - Expires January 2001 4 July 2000 @ When the header of the xcast packet contains a list of pairs of IP addresses and UDP port numbers, different UDP port numbers can be used for the different recipients. In other words, the header of this type of xcast packet will contain all the individual IP address/UDP port number pairs of the correspondents that are entitled to receive this packet. The different unicast IP packets generated from such an IP xcast packet differ in IP address and UDP port number. From now on we will call this the UDP-enhanced xcast scheme. Note that the xcast proposals (CLM, MDO6, SGM) support this UDP-enhanced scheme. 4. SIP/xcast User Agent The following block scheme provides a functional representation of the SIP/xcast User Agent (Figure 1). ********************************* * Host * * +-------------------------+ * * | Application | * * +-------------------------+ * * | ^ * * | | * * | +-------------+ * * | | SIP UA | * * Socket | | +---------+ | * * interface | | | SIP UAC | | * * | | +---------+ | * * | | | SIP UAS | | * * | | +---------+ | * * | +-------------+ * * | * ************************ * V * * Router * * +-------------------------+ * * +------------------+ * * | IP Stack | *---------->* | IP forwarder | * * | (xcast enabled) | * * | (xcast enabled) | * * +-------------------------+ * * +------------------+ * ********************************* ************************ Figure 1 - Block scheme of SIP/xcast User Agent This functional block scheme represents a SIP xcast User Agent that is capable of having xcast based multiparty IP telephony and conference calls with different correspondents, using different media formats. Every participant in a distributed, xcast-based multiparty conference has an instance of such an SIP xcast User Agent. By using SIP carrying SDP, the SIP xcast User Agent establishes a logical view of the multiparty conference. Changes in the conference topology (i.e. when new correspondents are invited or when correspondents leave the conference or are put on hold) are reflected in this logical view of the conference. For each Van Doorselaer Informational - Expires January 2001 5 July 2000 correspondent in the conference, the SIP xcast user Agent maintains which media formats, which UDP ports and which IP addresses to use. Based on this logical view of the multiparty conference and on the knowledge of the media formats, the UDP ports and the IP addresses to use for each correspondent, the IP packets carrying the media payloads are constructed: @ When the same RTP payload has to be sent to multiple correspondents and when different UDP port numbers have to be used for these correspondents, a UDP-enhanced xcast packet will be created. The header of this UDP-enhanced xcast UDP/IP packet will contain all the individual IP address/UDP port number pairs of the correspondents that are entitled to receive this RTP/UDP/IP packet. Hence there will be no common UDP header for all the correspondents. @ When the same RTP payload has to be sent to multiple correspondents and when the same UDP port number may be used for all these correspondents, a simple xcast packet will be created. The header of this simple xcast packet will contain all the individual IP addresses of the correspondents that are entitled to receive this RTP/UDP/IP packet. The UDP header will be common for all the correspondents and hence will be included only once in the xcast IP packet. @ When the RTP payload has to be sent to a single correspondent, a normal unicast IP packet will be created. 5. SIP call flow example for three-party call The call flow diagram introduced hereafter will describe the establishment of a full-meshed three party call. 5.1 Step 1 Van Doorselaer Informational - Expires January 2001 6 July 2000 UA1 UA2 UA3 | | | | | | | INVITE | | |----------------------->| | | | | | 180 RINGING | | |<-----------------------| | | | | | 200 OK | | |<-----------------------| | | | | | ACK | | |----------------------->| | | | | |Both way RTP established| | |<---------------------->| | | | | User Agent 1 invites User Agent 2 to the session. After receipt of the 180 RINGING and 200 OK messages by User Agent 1, the ACK message is sent to User Agent 2 and the RTP sessions in both directions are established. The RTP sessions use native IP unicast. Before | After | | UA1 . . . . . . UA2 | UA1 <---------> UA2 . . | . . . . | . . . . | . . . . | . . UA3 | UA3 | 5.2 Step 2 UA1 UA2 UA3 | | | | | | | INVITE (c=0) | | |----------------------->| | | | | | 200 OK | | |<-----------------------| | | | | | ACK | | |----------------------->| | | | | | No RTP established | | |<---------------------->| | | | | Van Doorselaer Informational - Expires January 2001 7 July 2000 User Agent 1 sets User Agent 2 on hold, by sending an invite message with a null value for the c parameter in the SDP session description. After receipt of the 200 OK messages by User Agent 1, the ACK message is sent to User Agent 2 and the RTP sessions in both directions are removed. Before | After | | UA1 <---------> UA2 | UA1 <.........> UA2 . . | . . . . | . . . . | . . . . | . . UA3 | UA3 | 5.3 Step 3 UA1 UA2 UA3 | | | | | | | INVITE | | |------------------------|----------------------->| | | | | 180 RINGING | | |<-----------------------|------------------------| | | | | 200 OK | | |<-----------------------|------------------------| | | | | ACK | | |------------------------|----------------------->| | | | | Both way RTP established | |<-----------------------|----------------------->| | | | User Agent 1 invites User Agent 3 to the session. After receipt of the 180 RINGING and 200 OK messages by User Agent 1, the ACK message is sent to User Agent 3 and the RTP sessions between User Agent 1 and User Agent 3 in both directions are established. The RTP sessions use native IP unicast. Before | After | | UA1 <..........> UA2 | UA1 <.........> UA2 . . | ^ . . . | \ . . . | \ . . . | v . UA3 | UA3 Van Doorselaer Informational - Expires January 2001 8 July 2000 | 5.4 Step 4 UA1 UA2 UA3 | | | | | | | INVITE | | |----------------------->| | | | | | 200 OK | | |<-----------------------| | | | | | ACK | | |----------------------->| | | | | |Both way RTP established| | |<---------------------->| | | | | User Agent 1 invites User Agent 2 to the session by sending a SIP INVITE message. This INVITE message will contain the Also header, indicating that User Agent 1 wants User Agent 2 to INVITE User Agent 3. After receipt of the 200 OK message by User Agent 1, the ACK message is sent to User Agent 2 and the RTP sessions between User Agent 1 and User Agent 2 in both directions are established. From now on, the RTP sessions for which User Agent 1 is the sender can use IP xcast. Before | After | | UA1 <..........> UA2 | UA1 <---------> UA2 ^ . | ^ . \ . | \ . \ . | \ . v . | v . UA3 | UA3 | Van Doorselaer Informational - Expires January 2001 9 July 2000 5.5 Step 5 UA1 UA2 UA3 | | | | | | | | INVITE | | |----------------------->| | | | | | 200 OK | | |<-----------------------| | | | | | ACK | | |----------------------->| | | | | |Both way RTP established| | |<---------------------->| | | | User Agent 2 invites User Agent 3 to the session by sending a SIP INVITE message. This INVITE message will contain the Requested-by header, indicating that the invitation was triggered by User Agent 1. After receipt of the 200 OK message by User Agent 2, the ACK message is sent to User Agent 3 and the RTP sessions between User Agent 2 and User Agent 3 in both directions are established. From now on, all the RTP sessions for which User Agent 2 and User Agent 3 are the senders can use IP xcast. Before | After | | UA1 <----------> UA2 | UA1 <---------> UA2 ^ . | ^ ^ \ . | \ / \ . | \ / v . | v v UA3 | UA3 | 6. Issues with use of UDP port numbers within RTP and SIP/SDP Simple xcast assumes that the same IP payload will be delivered to all receivers. This IP payload includes the UDP header. If in a conference scheme the simple xcast should be used, one should make sure that within this conference all recipients receiving an identical media stream from a particular sender can receive this stream on the same destination UDP port number. However, making use of native SIP/SDP and RTP does not allow this. First, making use of a fixed UDP port number for RTP is in contradiction with the spirit and the text of RFC 1889 (RTP) and RFC 1890 [14]. Second, SIP syntax and semantics do not allow to fully negotiate or control the port numbers that are used by the different participants in a conference. This will be discussed in more detail Van Doorselaer Informational - Expires January 2001 10 July 2000 in the next paragraphs, and some possible remedies will be suggested. 6.1 Fixed UDP port numbers for RTP No fixed UDP port number is assigned to RTP. If one fixed UDP port number were assigned to RTP, all receivers in a multiparty conference could use this fixed UDP port number, and the simple xcast scheme could be used. It was decided not to foresee a fixed UDP port number for the reasons expressed in RFC 1890. RFC 1890 "RTP Profile for Audio and Video Conferences with Minimal Control" says in Chapter 7: "As specified in the RTP protocol definition, RTP data is to be carried on an even UDP port number and the corresponding RTCP packets are to be carried on the next higher (odd) port number. Applications operating under this profile may use any such UDP port pair. For example, the port pair may be allocated randomly by a session management program. A single fixed port number pair cannot be required because multiple applications using this profile are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses." One could argue that in future versions of RTP, this decision should be changed and that RTP should use a fixed UDP port number. In fact, demultiplexing different RTP streams arriving on the same UDP port is possible, since demultiplexing can be done based on: @ Source IP address - (RTP streams coming from different senders will have different IP source addresses) @ SSRC (Synchronisation Source) - RTP streams coming from one host can be identified by their SSRC. However, this change cannot be implemented overnight. It could have a serious impact on host Operating Systems that do not allow multiple processes to use the same UDP port. 6.2 Negotiating UDP port numbers with SIP/SDP One could think of a signalling scheme in which different participants in a multiparty conference would be able to agree on the UDP port numbers to be used. At a first glance, SIP/SDP messages carry UDP port numbers. But when one looks deeper into SIP/SDP, one will see that SIP/SDP allows the participants in a conference only to express on which port number they will (want to) receive an incoming RTP stream. SIP/SDP does not allow participants in a conference to express to which destination port number they will (want to) send an outgoing RTP stream to. Indeed, Annex B.2 of RFC 2543 (SIP) states: "(à) the port number and address in the session description indicate where the media stream Van Doorselaer Informational - Expires January 2001 11 July 2000 should be sent to by the recipient of the session description, either caller or callee." This is summarised in following figure (Figure 2): +------------------+ +------------------+ | User Agent 1 | | User Agent 2 | | IP A1.B1.C1.D1 |------------------------->| IP A2.B2.C2.D2 | +------------------+ +------------------+ | | | | | +----------------------------------+ | | | c=IN IP4 A1.B1.C1.D1 | | | | m=audio DP2 RTP/AVP 0 | | | +----------------------------------+ | |--------------------------------------------->| | INVITE | | | | +----------------------------------+ | | | c=IN IP4 A2.B2.C2.D2 | | | | m=audio DP1 RTP/AVP 0 | | | +----------------------------------+ | |<---------------------------------------------| | 200 OK | | | | +----------------------------------+ | | | Destination Address A2.B2.C2.D2 | | | | Source Address A1.B1.C1.D1 | | | | Source port SP1 | | | | Destination port DP1 | | | +----------------------------------+ | |--------------------------------------------->| | Forward RTP session | | | | +----------------------------------+ | | | Destination Address A1.B1.C1.D1 | | | | Source Address A2.B2.C2.D2 | | | | Source port SP2 | | | | Destination port DP2 | | | +----------------------------------+ | |<---------------------------------------------| | Backward RTP session | | | Figure 2 - Mapping of SIP/SDP parameters on RTP parameters One could argue that in future versions of SIP and SDP these protocols should be extended in such a way that port numbers (i.e. Van Doorselaer Informational - Expires January 2001 12 July 2000 source port as well as destination port) can be negotiated on a pair basis by the endpoints engaging in a two-party or multiparty conference. If a future version of SIP/SDP would allow this negotiation of destination UDP port numbers on a pair basis (i.e. between calling and callee) than two schemes could be supported: @ Negotiating a single UDP port number for an entire multiparty conference. However, this would again introduce the issues explained in the previous chapter, that is that demultiplexing different RTP streams arriving on the same UDP port must be possible. Again, this change cannot be implemented overnight. It could have a serious impact on host Operating Systems that do not allow multiple processes to use the same UDP port. In addition, this change requires a change of the syntax and semantics of SIP/SDP. @ Negotiating a separate destination UDP port number for each sender in a multiparty conference. In this case, the negotiation procedure should provide the means for every sender to propose a destination UDP port number it will use and for every receiver to accept or refuse this UDP port number (e.g. by proposing another value). With such a scheme, senders will be able to use the same destination UDP port number for all its receivers while receivers will receive different streams from different senders on different UDP ports. This scheme hence has the advantage that it does not impose the problems of demultiplexing different RTP streams arriving on the same UDP, since different UDP port numbers can be used. In such a UDP port numbers negotiation scheme, @ the SIP invite message should contain the destination UDP port number(s) to which the calling party (caller) wants to send its outgoing RTP session(s) and optionally the destination UDP port number(s) on which the calling party wants to receive its incoming RTP session(s) @ the 200 OK message should contain the destination UDP port number(s) to which the called party (callee) wants to send its outgoing RTP session(s) to (and which may be identical as the value(s) optionally proposed by the calling party), and optionally the destination UDP port number(s) on which the called party wants to receive its incoming RTP session(s) (and which may be identical as the value(s) proposed by the calling party) 6.3 Choosing identical port numbers per default One could think of not changing the syntax of the SIP/SDP signalling scheme, in contrast with the solution proposed in the previous chapter. However, the semantics of SDP / SIP should be changed as follows. Different participants in a multiparty conference would Van Doorselaer Informational - Expires January 2001 13 July 2000 still be able to agree on the same UDP port numbers to be used, when for every caller/callee interaction the callee preferentially chooses to use the same UDP port number as the one proposed by the caller. In this case, the callee shows its agreement on the chosen UDP port number by setting the same UDP port number in its 200 OK response message. In case the callee cannot agree on the chosen UDP port number, it can choose itself a new UDP port number by setting this new one in its 200 OK message (or in an error message). The caller, if agreeing with the new value, can then send a new INVITE message to the callee with the new UDP port number. With this scheme, UDP port numbers can be negotiated on a pair basis by the endpoints engaging in a two-party or multiparty conference. In such a way, a single UDP port number could be negotiated for an entire multiparty conference. However, this would again introduce the issues explained in previous chapters, that is that demultiplexing different RTP streams arriving on the same UDP port must be possible. Again, this change cannot be implemented overnight. It could have a serious impact on host Operating Systems that do not allow multiple processes to use the same UDP port. In addition, this change requires a change of the semantics of SDP / SIP. 6.4 Conclusion on use of UDP port numbers within RTP and SDP / SIP One could certainly argue for one of the schemes proposed above. Their main drawback is that they all introduce changes to SIP/SDP and that some may have an impact on the Operating Systems deployed today. If one of the schemes outlined above would be acceptable, then the simple xcast scheme can be used for SIP/SDP established xcast conferences. As long as the current SIP/SDP syntax and semantics are used, one has to rely on the UDP-enhanced version of xcast. 7. Conclusion For relatively small conferences, xcast is a very attractive scheme that does not suffer from @ the (bandwidth) inefficiencies of the distributed full-mesh conferencing scheme @ the Single-Point-Of-Failure risk of the conference bridge-based schemes @ the inherent drawbacks of the network state-oriented classical multicast schemes Use of current RTP and SIP/SDP forces us to use the UDP-enhanced xcast scheme. When we are allowed to extend SIP/SDP with UDP port Van Doorselaer Informational - Expires January 2001 14 July 2000 negotiation mechanisms and / or to multiplex different RTP streams on a single UDP port, we will be able to further improve xcast-based conferencing towards the simple xcast scheme. 8. Security Considerations For further study. The same security issues apply as those that apply to SIP/SDP and those that apply to xcast. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 See at http://www.alcatel.com/xcast 4 D. Ooms, W. Livens, O. Paridaens, "Connectionless Multicast", , April 2000, Work in Progress 5 IMAI Yuji, "Multiple Destination Option on IPv6 (MDO6)", , March 2000, Work in Progress 6 R. Boivie, N. Feldman, "Small Group Multicast", , March 2000, Work in Progress 7 M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 8 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 9 J. Postel, "Internet Protocol", September 1981 10 J. Postel, "User Datagram Protocol", RFC 768, August 1980 11 H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", , Work in Progress (Expired - still available on http://www.softarmor.com/sipwg/drafts/draft- ietf-mmusic-sip-cc-01.txt) 12 J. Mark, K. Kelley, "Distributed Multipoint Conferences using SIP", draft-mark-sip-dmcs-00.txt, March 2000, Work in Progress 13 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 Van Doorselaer Informational - Expires January 2001 15 July 2000 14 H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996 10. Acknowledgments We would like to thank Emmanuel Desmet for his thorough review and helpful comments. 11. Author's Addresses Bart Van Doorselaer Alcatel Francis Wellesplein 1, B-2018 Antwerp, Belgium Phone: +32 3 240 86 41 Email: Bart.Van_Doorselaer@alcatel.be Dirk Ooms Alcatel Francis Wellesplein 1, B-2018 Antwerp, Belgium Phone: +32 3 240 4732 Email: Dirk.Ooms@alcatel.be Van Doorselaer Informational - Expires January 2001 16