Subject: [SIP] Multimedia Conferencing using SIP

From: "Vakil, Mohammad" <[email-masked]>
Date: Wed, 17 May 2000 12:22:00 -0400

I read in RFC2543bis, "SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols." This is a little confusing because in Abstract of RFC2543bis I read that these sessions(which are created, modified, and terminated using SIP), could also be Internet multimedia conferences.....

I skimmed through the document "Distributed Multipoint Conferences using SIP"(draft-mark-sip-dmcs-00). I've a situation where a central server does all the conferencing and I'd like SIP UACs to be able to estabilish a multimedia conference session on that server. e.g. for a conference call, they can specify hostname or IP address of the Conferencing Sever in the SDP and establish the session. 
Do we have an extension or something, which explains Conferencing on a central server? Any pointers, explanations, or directions would very appreciated.
Thanks,
Mohammad Vakil

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Wed, 17 May 2000 10:28:00 -0700

Mohammad,

The now expired call control draft (draft-ietf-mmusic-sip-cc-01) describes
a SIP bridge which would accomplish the goals you wish describing how a
UAC could establish a connection to a centralized conference server
without any SIP extensions.  See section 4.3 of the draft.  Here's a link:

http://www.softarmor.com/sipwg/drafts/draft-ietf-mmusic-sip-cc-01.txt

It's also important to note the last 2 paragraphs of this section describe
a mechanism for one participant in the bridged conference to INVITE
another to the conference.  This mechanism is still up in the air and is
work in progress.

-Jeff

--
Jeff Mark                               Intel Dialogic Division
Software Engineer                       201 Mentor Dr, Suite 100
mailto:[email-masked]           Santa Barbara, CA 93111
http://www.dialogic.com                 (805) 879-3640
                                        (805) 967-1395 fax

> -----Original Message-----
> From: Vakil, Mohammad [mailto:[email-masked]]
> Sent: Wednesday, May 17, 2000 9:22 AM
> To: [email-masked]
> Cc: [email-masked]'
> Subject: [SIP] Multimedia Conferencing using SIP
>
>
>
> I read in RFC2543bis, "SIP does not offer conference control
> services such as floor control or voting and does not
> prescribe how a conference is to be managed, but SIP can be
> used to introduce conference control protocols." This is a
> little confusing because in Abstract of RFC2543bis I read
> that these sessions(which are created, modified, and
> terminated using SIP), could also be Internet multimedia
> conferences.....
>
> I skimmed through the document "Distributed Multipoint
> Conferences using SIP"(draft-mark-sip-dmcs-00). I've a
> situation where a central server does all the conferencing
> and I'd like SIP UACs to be able to estabilish a multimedia
> conference session on that server. e.g. for a conference
> call, they can specify hostname or IP address of the
> Conferencing Sever in the SDP and establish the session.
> Do we have an extension or something, which explains
> Conferencing on a central server? Any pointers, explanations,
> or directions would very appreciated.
> Thanks,
> Mohammad Vakil
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2000 01:41:11 -0400

> I read in RFC2543bis, "SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conf…

Don't confuse multimedia conferences (i.e., voice plus video muliparty
things) and conference control services. The latter include, as the bis
draft states, floor control (who can talk now), and voting. SIP doesn't
do conference control, but it can certainly initiate multimedia
multiparty sessions.

> Do we have an extension or something, which explains Conferencing on a central server? Any pointers, explanations, or directions would very appreciated.

No extensions needed for central conference servers. It works just like
it does in the PSTN - you dial a number which corresponds to a port on a
bridge. In the case of SIP, you would INVITE to a URL corresponding to a
port on the conference server, like sip:[email-masked]. The
result appears as a point to point SIP call as far as  your UA is
concerned, but the server is mixing media and sending the mixed media to
your UA. You will learn the identity of the other participants through
RTCP CSRC.

How do you know the right URL to send an INVITE to? Well, how do you
know what number to dial for a conference in PSTN? You're told out of
band. URLs can be included in emails, web pages, whatever.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Hyong Sop Shim <[email-masked]>
Date: Fri, 19 May 2000 15:03:27 -0400

> band. URLs can be included in emails, web pages, whatever.

In "SIP Call Control Services," the underlying model for establishing a conference seems to be that it is the responsibility of the invited user to send INVITE requests to the existing conference participants.  That is, in a conference that is comprised of User A, B, and C, say A wishes to add D to the conference.  According to the "SIP Call Control Services," A invites D, who, in turn, sends INVITE requests to B and C.
Why is this model preferred over another model, in which the existing conference participants send INVITE requests to the invited?

--Hyong Shim

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 16:44:51 -0400

Hyong Sop Shim wrote:
> In "SIP Call Control Services," the underlying model for establishing a conference seems to be that it is the responsibility of the invited user to send INVITE requests to the existing conference participants.

That is one model, but not the only one SIP provides. SIP has four ways
to do multiparty conferencing:

1. dialup conference bridge: call the bridge just like you call a
person. Conference is identified by request URI. Works with rfc2543 - no
extensions needed. 
2. distributed multiparty conferencing - no server. Fully distributed.
This is what is described in the now-expired draft, and is work in
progress.
3. multicast conferences - you can run your conference on multicast.
Simply INVITE the person to join the multicast session. Works with
baseline SIP. In fact, this was the initial purpose of SIP. In this
case, there is not a full mesh of SIP signaling.
4. 3-way with local MC/MP function: A and B are talking. A wishes to add
C to the call. A can simply call C, but also act as a mixer, so that the
media it sends to B contains the A+C media, and the media to C is the
A+B media. RTCP CSRC indicate who is in the conference. This also works
with baseline SIP. It imposes additional burden on the UA, but otherwise
provides this standard feature in a simple way. 

There is no preferred way. It depends on the particular application. 

-Jonathan R.

---

From: Hyong Sop Shim <[email-masked]>
Date: Mon, 22 May 2000 12:24:47 -0400

In the case of the conferences based on "dial-up" bridges, the current model is that
the invited user contacts the dial-up bridge as a result of receving an INVITE message with an Also header sent by an existing conference participant.  Instead, why not have
the dial-up bridge directly invite the invited user?  That is, why not have the existing
conference member send the same INVITE with an Also header to the dial-up bridge
and have the bridge "relay" the INVITE to the user specified in the Also header?
This approach would eliminate the need for the dial-up bridge having to subsume call
legs and provide more a means for allerting the invited user of the current membership
of the conference than RCTP.

Thanks,

--Hyong

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 May 2000 23:12:27 -0400

Hyong Sop Shim wrote:
> the invited user contacts the dial-up bridge as a result of receving an INVITE message with an Also header sent by an existing conference participant. 

Not neccesarily. The most common model for dial-up bridges is that you
simply know the conference ID ahead of time, and call in. Just like in
the PSTN today. This doesn't require any SIP extensions, Also or
anything else.

 Instead, why not have
> of the conference than RCTP.

Either works. One is more of a consultation feature (call the user, then
transfer to the bridge), the other is a third party mechanism (call the
bridge, transfer to the user).

-Jonathan R.

---

From: Hyong Sop Shim <[email-masked]>
Date: Thu, 25 May 2000 17:47:33 -0400

In Figure 4 in 8.3 Add Party during Add Party, D, acting on the untriggered INVITE
message from B, sends an INVITE message to A, "INV A Also:A, B."  But, shouldn't
this INVITE message from D be "INV A Also:B ReqBy:B" instead?

--Hyong

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 26 May 2000 10:18:49 -0500 (CDT)

>this INVITE message from D be "INV A Also:B ReqBy:B" instead?

This draft has expired; I don't beleive a new version will be issued.

The way forward with call-control which will probably be adopted
is outlined in draft-campbell-sip-cc-framework-00.txt (which
is being updated to bring it in line with 
draft-rosenberg-sip-guidelines-00.txt). An example of the modular
approach espoused in this draft is presented in 
draft-sparks-sip-cc-transfer-00.txt (which will probably be changing 
to be more general in its next release).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA