Re: SCCP

[Christoph Reichert <[e-mail]>]

On Thu, Oct 12, 2000 at 11:14:49AM -0400, Henning Schulzrinne wrote:
> It might be helpful to specify more closely what "control" really means
> in an Internet environment where you can't prevent people from sending
> data. I can understand floor control, but I've never understood the

The same what it means in an ITU world, where T.124 (Generic Conference
Control) specifies things like opening and closing (application)
channels, floor control, the role of a conductor, what the conductor is
allowed to do, what other members are allowed to do (policies),
capability exchange and so on DURING the conference, ie. AFTER the
members have been invited and AFTER they have been admitted.

Or the same that has been tried with CCCP, the agreement protocol proposal
and what various commercial systems tried to do.

cheers, chris

> point of admission control in multicast (and with explicit invitations
> to either an MCU or a multicast group, SIP provides about as much
> control as you can reasonably expect). Maybe a more precise definition
> would be helpful, taking into account that the world has moved along
> since the original SCCP papers when SAP/SDP was the only Internet
> approach to conferencing...
> 
> Gonzalo Camarillo wrote:
> > 
> > Hi,
> > 
> > SIP is not meant for tightly-coupled sessions. However, there are some
> > drafts that provide certain call control using SIP. For example these
> > two:
> > 
> > http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-cc-transfer-01.txt
> > http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> > 
> > I assume that the difference between a protocol for tightly-coupled
> > sessions such as SCCP and SIP with these call control extensions is that
> > SCCP provides a much higher degree of control. Am I right?
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > [e-mail] wrote:
> > >
> > > Hi all,
> > >
> > > I agree with your reliability point. It covers mainly what I meant to say.
> > >
> > > I guess that the policy issue goes into the direction of implementing
> > > some kind of access control or application state synchronization.
> > > I strongly agree that this is much harder to provide in a scalable manner
> > > if you do not accept temporary inconsistencies of the associated state.
> > > This is basically one of the tasks in the revision of the SCCP draft by
> > > providing a scalable (whatever number this might be) floor control service.
> > >
> > > Regards
> > >
> > > Dirk
> > >
> > > > -----Original Message-----
> > > > From: EXT Dr. Carsten Bormann [mailto:[e-mail]]
> > > > Sent: Thursday, October 12, 2000 1:14 PM
> > > > To: [e-mail]; [e-mail]
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]
> > > > Subject: RE: SCCP
> > > >
> > > >
> > > > > Concerning the term 'tightly-coupled', you're right that there is
> > > > > some kind of misunderstanding. It does not imply that reliable
> > > > > transport or even unicast transport is a must to be used, e.g. as in
> > > > > the H.323.
> > > >
> > > > Of course tightly-coupled implies a reliability protocol,
> > > > otherwise you have
> > > > little assurance that the state of the participants
> > > > converges.  Whether
> > > > reliability is a transport function or a property of the application
> > > > protocol, and whether it is achived by saturation (endless
> > > > repetition),
> > > > forward error correction, or retransmissions, does not really make a
> > > > difference (and I think this is what you are addressing).
> > > >
> > > > Of course, there are various aspects that together could be
> > > > called tightly
> > > > coupled.  State convergence is one.  Another requirement in
> > > > many conferences
> > > > is the execution of a common policy with respect to member
> > > > requirements and
> > > > requests -- this is much harder to scale.
> > > >
> > > > Gruesse, Carsten
> > > >
> > 
> > --
> > Gonzalo Camarillo         Phone :  [phone]
> > Oy L M Ericsson Ab        Mobile:  [phone]
> > Telecom R&D               Fax   :  [phone]
> > FIN-02420 Jorvas          Email :  [e-mail]
> > Finland                   http://www.hut.fi/~gonzalo