1. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 1 SIP for Xcast SIP for the establishment of xcast-based multiparty conferences <draft-van-doorselaer-sip-xcast-00.txt> Mmusic Working Group 48th IETF, Pittsburgh

2. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 2 Two-party and multiparty conferences  Starting point: w Two-party calls / conferences rather well known l Major focus of SIP WG w For multiparty conferences, the situation is less clear l Which conferencing scheme to use  multicast, bridge, mesh / distributed l Should we use SIP or SAP? l Or should we use email? Or WWW? l How to manage conference?  Therefor, the draft will introduce a scheme for small group multiparty conferences, based on w xcast w SIP

3. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 3 Overview of SIP-based multiparty conferencing schemes  Three schemes currently known that are supported by SIP: w Conference bridge  Additional element  SPOF l Special case: local bridge function  SPOF  Additional processing burden w Distributed multiparty conferencing  Bandwidth efficiency w Classical multicast conference  Complexity of classical mcast (mcast address allocation, …)  State info in the network  This draft introduces a fourth type of multiparty conference scheme to be supported by SIP: w xcast conference

4. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 4 Some words on xcast  Different proposals (CLM, MDO6, SGM)  Explicit list of destinations in packet header  Forwarding uses unicast route table A B C B A C A B C B C

5. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 5 Simple xcast and UDP-enhanced 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. w Simple xcast  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. w UDP-enhanced xcast

6. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 6 Block scheme of SIP/xcast User Agent Socket interface Host SIP UA SIP UAC SIP UAS Conferencing Application IP Stack (xcast enabled) Router IP forwarder (xcast enabled)

7. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 7 3-party call setup procedure  User 1 invites User 2  User 1 sets User 2 on hold  User 1 invites User 3  User 1 re-invites User 2 (also User 3)  User 2 invites User 3  All 5 steps comprise the well-known INVITE & 200 OK message exchanges  These INVITE & 200 OK messages carry SDP

8. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 8 SDP usage rules  Two types of SDP usage rules defined in annex B of SIP rfc w SDP usage rules for unicast w SDP usage rules for mcast  Proposal: apply SDP usage rules for unicast in case of xcast w Reason: receiver may not be aware whether unicast or xcast is used

9. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 9 Issues with use of UDP port numbers within RTP and SDP / SIP [1]  RTP does not use a fixed UDP port number w port numbers have to be exchanged between participants before data (media) can be sent w this is one of the features of SIP/SDP  A sender sending RTP packets to different destinations, needs to use the same UDP port numbers for all its destinations if the simple xcast scheme were to be used. w Otherwise, the sender will have to rely on the UDP-enhanced xcast scheme  To what extent can UDP port numbers be negotiated between participants using SIP/SDP, so that this condition can be fulfilled?

10. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 10 Issues with use of UDP port numbers within RTP and SDP / SIP [2] INVITE c=IN IP4 A1.B1.C1.D1 m=audio DP2 RTP/AVP 0 200 OK c=IN IP4 A2.B2.C2.D2 m=audio DP1 RTP/AVP 0 User Agent 1 IP A1.B1.C1.D1 User Agent 2 IP A2.B2.C2.D2

11. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 11 Issues with use of UDP port numbers within RTP and SDP / SIP [3] Backward RTP session Forward RTP session Destination Address A2.B2.C2.D2 Source Address A1.B1.C1.D1 Source port SP1 Destination port DP1 Destination Address A1.B1.C1.D1 Source Address A2.B2.C2.D2 Source port SP2 Destination port DP2 User Agent 1 IP A1.B1.C1.D1 User Agent 2 IP A2.B2.C2.D2

12. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 12 Issues with use of UDP port numbers within RTP and SDP / SIP [4]  Possible solutions w keep SIP/SDP as it is and use UDP-enhanced xcast w change semantics but not syntax of SIP/SDP so that in a SIP interaction invited party chooses the same destination UDP port number l invited party (callee) UA2 chooses DP1 such that DP1 = DP2 and use simple xcast w change semantics and syntax of SIP/SDP so that l inviting party (caller) UA1 chooses / proposes its destination UDP port (DP1) l invited party (callee) UA2 chooses / proposes its destination UDP port (DP2) and use simple xcast

13. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 13 Conclusion [1]  For relatively small conferences / multiparty calls, xcast is a very attractive scheme that does not suffer from w the (bandwidth) inefficiencies of the distributed full-mesh conferencing scheme w the Single-Point-Of-Failure risk of the conference bridge- based schemes w the inherent drawbacks of the network state-oriented classical multicast schemes  xcast already works together with SIP/SDP

14. All rights reserved © 1999, Alcatel, Paris. Bart.Van_Doorselaer@alcatel.be, page n° 14 Conclusion [2]  However w Use of current RTP and SIP/SDP forces us to use the UDP- enhanced xcast scheme. w When we are allowed to extend SIP/SDP with UDP port negotiation mechanisms (preferably) 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.