Conferencing Models [Rosenberg 2002]

Commercial conference bridges authenticate the users joining the conference.

Type of Conference	Description	Scale
Endpoint mixing	One end point acts as a mixer for all the other end points	small
SIP Server and distributed media	Central SIP server establishes a full mesh between all participants - each participant does their own mixing	medium
Dial-in conference	All participants connect to a conference bridge which does the mixing for each participant	medium
Ad hoc centralized conference	Two users transition to a multiparty conference, by one of them using third-party signaling to move the call to a conference bridge	medium
Large multicast conference	user join the multicast based on the multicast address (which they got via •announcement on the web •e-mail •Session Announcement Protocol (SAP) [RFC 2974]	small to very large

Slide Notes

J. Rosenberg and H. Schulzrinne, “Models for Multi Party Conferencing in SIP”, Internet Draft, July 1, 2002, {expired January 2003} http://www.ietf.org/internet-drafts/draft-ietf-sipping-confeencing-models-01.txt Links to an external site.

M. Handley, C. Perkins, and E. Whelan, “Session Announcement Protocol”, IETF RFC 2974, October 2000 http://www.ietf.org/rfc/rfc2974.txt Links to an external site.

Transcript

[slide444] So Rosenberg gave some examples of different sorts of conferencing models. conference. Why do you need to do that? Well, at the small conference we can let the endpoints get each of the media streams and simply mix them locally. But if there are N participants, I get N streams. But as N increases, what happens? Well, I don't want to have to do all of that processing locally, and I may not have enough bandwidth for all of those streams to arrive directly at me. So what do I want to do? I want to put the mixing somewhere else. So I'm going to take those multiple streams, mix them together, and that way I only get one audio stream, and perhaps one video stream coming to me, which reduces the burden on my system. But it means I have to have some way to set up and control the mixing elsewhere. And most importantly, I need to make sure I never mix my audio back into that stream, or I'm going to get feedback. So as we scale up, we go from a small group with N mixing, to a central SIP server with distributed media, to now a dial-in conference. In this approach, we use something called a conference bridge. And a conference bridge is nothing more than a server that mixes all the media together, and it gives you your audio from everyone else, but leaves your particular stream out. So it delivers to each of the participants the stream, but makes sure that they don't get theirs mixed into it. You can also have ad hoc centralized conferencing, and you can have large multicast conferences. And we talked yesterday about the session announcement protocol. It makes it easy to announce one of these big multicast conferences. Well, commercial conference bridges, if you've ever experienced them, they authenticate the user when you join. You need to know the passcode to be able to join the conference. But we saw in SIP, we could actually identify the real users. So we could have them provide their identity information, rather than simply providing four digits.