Re: SCCP

[Henning Schulzrinne <[e-mail]>]

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
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