all rights reserved © 1999, alcatel, paris. [email protected], page n° 1 sip for...

All rights reserved © 1999, Alcatel, [email protected], page n° 1

SIP for XcastSIP for XcastSIP for the establishment of xcast-basedSIP for the establishment of xcast-based

multiparty conferencesmultiparty conferences

<draft-van-doorselaer-sip-xcast-00.txt><draft-van-doorselaer-sip-xcast-00.txt>

Mmusic Working Group48th IETF, Pittsburgh


Two-party and multiparty conferences

Starting point: Two-party calls / conferences rather well known

Major focus of SIP WG

For multiparty conferences, the situation is less clear Which conferencing scheme to use

multicast, bridge, mesh / distributed Should we use SIP or SAP? Or should we use email? Or WWW? How to manage conference?

Therefor, the draft will introduce a scheme for small group multiparty conferences, based on

xcast SIP


Overview of SIP-based multiparty conferencing schemes

Three schemes currently known that are supported by SIP: Conference bridge

Additional element SPOF

Special case: local bridge function SPOF Additional processing burden

Distributed multiparty conferencing Bandwidth efficiency

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:

xcast conference


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 CB

C


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.

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.

UDP-enhanced xcast


Block scheme of SIP/xcast User Agent

Socketinterface

Host

SIP UA

SIP UAC

SIP UAS

Conferencing Application

IP Stack(xcast enabled)

Router

IP forwarder(xcast enabled)


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


SDP usage rules

Two types of SDP usage rules defined in annex B of SIP rfc SDP usage rules for unicast SDP usage rules for mcast

Proposal: apply SDP usage rules for unicast in case of xcast Reason: receiver may not be aware whether unicast or xcast

is used


Issues with use of UDP port numberswithin RTP and SDP / SIP [1]

RTP does not use a fixed UDP port number port numbers have to be exchanged between participants before

data (media) can be sent 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.

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?



INVITEc=IN IP4 A1.B1.C1.D1

m=audio DP2 RTP/AVP 0

200 OKc=IN IP4 A2.B2.C2.D2

m=audio DP1 RTP/AVP 0

User Agent 1IP A1.B1.C1.D1




Backward RTP session

Forward RTP session

Destination Address A2.B2.C2.D2Source Address A1.B1.C1.D1

Source port SP1Destination port DP1

Destination Address A1.B1.C1.D1Source Address A2.B2.C2.D2

Source port SP2Destination port DP2





Possible solutions keep SIP/SDP as it is and use UDP-enhanced xcast change semantics but not syntax of SIP/SDP so that in a SIP

interaction invited party chooses the same destination UDP port number

invited party (callee) UA2 chooses DP1 such that DP1 = DP2

and use simple xcast change semantics and syntax of SIP/SDP so that

inviting party (caller) UA1 chooses / proposes its destination UDP port (DP1)

invited party (callee) UA2 chooses / proposes its destination UDP port (DP2)

and use simple xcast


Conclusion [1]

For relatively small conferences / multiparty calls, 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

xcast already works together with SIP/SDP


Conclusion [2]

However 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

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.

all rights reserved © 1999, alcatel, paris. [email protected], page n° 1 sip for...

Documents