Subject: SCCP

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Oct 2000 17:30:44 +0300

Hi,

I would like to know the status of SCCP (Simple Conference Control
Protocol).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Christoph Reichert <[email-masked]>
Date: Wed, 11 Oct 2000 17:28:52 +0200

> I would like to know the status of SCCP (Simple Conference Control

Gonzalo, Group

as far as I know, there was no further development of SCCP since I
stopped working on it in 1997.

Although I believe the services SCCP provides are still those needed
for more controlled sessions (membership-, application-, floor control,
capability exchange), I discourage from following the approach taken by
SCCP.

The biggest disadvantage is that it depends heavily on a reliable, totally
ordered N to N multicast transport. Such a thing is currently "not
on the radar", and unlikly to be scalable anyway.

If and when more "tighly controlled" sessions should scale up to some
hundreds or even thousands of members, and ALF based approach like
those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.

I do not know the reason why SCCP is still mentioned on the MMUSIC charter.

cheers, chris

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Oct 2000 20:03:07 +0200 (MET DST)

> stopped working on it in 1997.

Actually, there is renewed interest, and we know of at least one
person working on a followup version.  I'll leave it to him to make
that work known to this group when he decides to do so.

> those taken in the LBNL whiteboard (SRM) or UCL NTE should be taken.

In the version of SCCP we actually implemented, we used that transport
because we had it available to us (separation of concern).  Old hands
of this WG remember that there were earlier attempts on the more
politically correct peer-to-peer basis (agreement protocol, anyone?),
which unfortunately never really worked out.  I continue to believe
the role-based approach of SCCP (use a coordinator for consistency, a
receptionist for generating refreshes, etc.) is exactly the right way
to do this.  The transport below that doesn't matter too much (we
would be using NORM these days, which would mean moving up the
coordinator function to SCCP).  SSM maybe changes the picture to make
the coordinator role even more appealing...

> I do not know the reason why SCCP is still mentioned on the MMUSIC charter.

Wild guess: Because it's still needed.

Gruesse, Carsten