Subject: RE: SCCP

From: [email-masked]
Date: Thu, 12 Oct 2000 14:24:33 +0300

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:[email-masked]]
> Sent: Thursday, October 12, 2000 1:14 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> 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
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Oct 2000 14:57:13 +0300

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

-- 
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: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 12 Oct 2000 14:16:57 +0200

> SCCP provides a much higher degree of control. Am I right?

There are a number of differences.

SIP is a session initiation protocol.  It was originally invented to invite
an additional participant into an existing (loosely coupled) conference.
SIP does not provide its own application semantics, this is left to SDP
(which was adequate for loosely coupled conferences).

SCCP was meant to be used within a conference that was established by some
other means.  E.g., you could use SIP to invite people to a conference only
giving a "control" media stream, which would use SCCP as a protocol.  As SDP
is inadequate, SCCP has defined its own application semantics, kind of a
precursor to the SDPng work that is now coming up again.

SCCP is inherently multiparty, with the two-party case as a special case.
SIP does support multicast for search, but does not have multicast
transaction semantics -- all its effects are point-to-point.  (Of course,
SIP is avian-carrier-equivalent, i.e., you can use it to transport anything,
so you can e.g. run IP over it, which allows to do much more grandiose
things.  But SIP does not actually itself help in doing these things...)

Today, SIP is used as a point-to-point replacement for SCCP-style mid-course
control by "initiating" sessions, giving the name of an existing session and
new SDP, and hoping that the two ends will make a smooth transition.  Again,
SDPng will make this much more palatable.  SCCP (minus SDPng) is still
needed to do multiparty sessions, though.

Gruesse, Carsten

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2000 11:14:49 -0400

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

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 12 Oct 2000 17:22:30 +0200

> 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

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 12 Oct 2000 18:27:33 +0200

> 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