One document matched: draft-van-doorselaer-sip-xcast-00.txt
MMUSIC Working Group B. Van Doorselaer
Internet Draft D. Ooms
Document: <draft-van-doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
<draft-van_doorselaer-sip-xcast-00.txt> 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",
<draft-ooms-cl-multicast-02.txt>, April 2000, Work in Progress
5 IMAI Yuji, "Multiple Destination Option on IPv6 (MDO6)", <draft-
imai-mdo6-01.txt>, March 2000, Work in Progress
6 R. Boivie, N. Feldman, "Small Group Multicast", <draft-boivie-sgm-
00.txt>, 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",
<draft-ietf-mmusic-sip-cc-01.txt>, 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
<draft-van_doorselaer-sip-xcast-00.txt> 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
| PAFTECH AB 2003-2026 | 2026-04-23 11:46:40 |