Re: SCCP

[Christoph Reichert <[e-mail]>]

On Thu, Oct 12, 2000 at 02:57:13PM +0300, 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?

No. The degree of control is not the topic.
The problem is a topological one.
SCCP is based on multicast because of the usual scaling issues, ie.
when central conference bridges or full meshes are no longer feasable.
Setting up trees or rings is possible, but hard, and have a great
overhead when changes in membership are frequent.

When application sessions are all multicast based, why should an associated
control session not also be multicast based? This would make much
things easier.

cheers, chris

> 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