RE: SCCP

[[e-mail]]

Hi,

I agree with your statement about admission control in terms of
preventing conference participants from joining a conference
to receive particular transmitted data. Furthermore, it's hard
to implement a forced leave (disband) in conference environments.
You could use appropriate security features (group key) for that
but this is currently not integrated in the draft (and the question
is whether is should be).

The current draft of SCCP provides membership control in terms
of maintaining a membership list and providing new members
with the appropriate information. Furthermore, a floor control 
service is provided.

Best regards



Dirk

> -----Original Message-----
> From: EXT Henning Schulzrinne [mailto:[e-mail]]
> Sent: Thursday, October 12, 2000 5:15 PM
> To: Gonzalo Camarillo
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: SCCP
> 
> 
> 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-transf
> er-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
>