Subject: [SPIRITS] Parlay vs SPIRITS

From: "Simon Barber" <[email-masked]>
Date: Wed, 21 Feb 2001 16:22:56 -0800

Parlay have defined/are defining an API to control telecom services, SPIRITS
is defining a protocol to do the same thing. Does anyone have any comments
on the relationship between these two efforts and approaches, and the
differences between them? What are the strong reasons for and against the
SPIRITS approach, and the Parlay approach.

Simon Barber

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: "Glauco Bigini" <[email-masked]>
Date: Thu, 22 Feb 2001 09:17:13 +0100

I studied the SPIRITS architecture for the last two months ando found that
the threated arguments ar important but the one of SPIRITS is a useless
fight.

All the IT Majors are spending their money on software APIs like Parlay and
JCC/JCAT and the future of convergent services like those addressed from
SPIRITS is in these APIs.

In my personal opinion the SPIRITS WG must provide a framework for the
deployment of Telephony APIs (based on the SIP protocol), and forget the
idea of a new protocol

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Simon Barber
Sent: Thursday, February 22, 2001 1:23 AM
To: [email-masked]
Subject: [SPIRITS] Parlay vs SPIRITS

Simon Barber

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 21 Feb 2001 20:04:43 -0500

Simon Barber wrote:
> differences between them? 

Indeed! Lawrence Conroy, Frans Haerens, and I talked about that after
the last SPIRITS meeting, and I am personally very glad to see the
discussion moving to the list (I hope that esteemed chairmen share my
enthusiasm.) 

Typicaly, an API specificiation defines a programmer's interface (e.g.,
set of procedure calls) for invoking services from a process on a
particular machine. A protocol specification defines the messages that
carry data from one IP host to another. If a protocol 1) carries exactly
same data as available at the API specficiation and 2) does so in a
sequence compatible with the API specification, then the protocol and
API applications are compatible.  

I am not following Parlay, but it looks to me that the Parlay indeed
defines API for the same services as PINT and SPIRITS protocols must
support. Then, of course, it is important to ensure that the Parlay and
SPIRITS specifications are compatible!

Now is the best time to start working on that.  I think sequencing in
this case is an almost trivial subject (although SUBSCRIBE/NOTIFY may
require special attention), but parameter specification is where most of
the job of ensuring the compatibility lies.

If someone who knows Parlay (you, Simon?) could write a draft listing
the INAP parameters Parlay found essential, that would be an essential
input to the SPIRITS activities. The WG could accept all such
parameters--to make the protocol and API fully compatible--or a subset
of them, with an awareness of what would and would not work together.

Again, I am glad Simon brought the subject to broad attention. 

> What are the strong reasons for and against the

These approaches are orthogonal, but they may or may not interwork. I am
for making them interwork.

Igor

---

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 22 Feb 2001 09:49:04 -0600

Well that was a pretty blunt statement...
I do think that this debate is going into somewhat disastrous area of API's vs.
Protocols, which might be a totally different mail list all together. Instead,
let's focus on more productive area of defining SPIRITS protocol, according to
our Charter and making Parlay and SPIRITS compatible, as Simon and Igor
suggested earlier.

Regards,
Alec

---

From: "Glauco Bigini" <[email-masked]>
Date: Thu, 22 Feb 2001 17:36:26 +0100

I agree with you, Alec; with "framework for the APIs" I meant a network
architecture and a support protocol, but with a hard look at the
compatibility with Parlay and other APIs

I thinh a step ahead will be considering the use of SoftSwitch technology
for the communications between SPIRITS Server (SIP Client) and SCP over the
SS7 network. In this case, SPIRITS services will only need some minimal
update for the SIP protocol in order to work correctly

My future studies will surely focus on SIP/PINT/SPIRITS/Parlay interworking,
even if it's very hard to get specific informations from the Parlay group
(seems like the ITU-T....)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alec Brusilovsky
Sent: Thursday, February 22, 2001 4:49 PM
To: [email-masked]
Subject: Re: [SPIRITS] Parlay vs SPIRITS

Well that was a pretty blunt statement...
I do think that this debate is going into somewhat disastrous area of API's
vs.
Protocols, which might be a totally different mail list all together.
Instead,
let's focus on more productive area of defining SPIRITS protocol, according
to
our Charter and making Parlay and SPIRITS compatible, as Simon and Igor
suggested earlier.

Regards,
Alec

---

From: 황진경 <[email-masked]>
Date: Fri, 23 Feb 2001 10:23:49 +0900

With my small knowledge about Parlay, I can say that Parlay is a 'superset' of the
SPIRITS.

I agree with your comment that much of the Parlay features are almost same to the
PINT and SPIRITS,

but Parlay has more operations such as charging, call gapping, getting call
information, call leg control etc. only in the GCCS(Generic Call Control Service)
as well as RRBE and CONNECT equivalents.

So more general call control is possible, in which several CONNECTs could be
delivered when ICW subscriber is no_answer or busy cases..(Is it possible with
double INVITEs in SPIRITS ?..)

I've been one of the confused people struggling with the same problem "PINT or
Parlay for IN-IP interworking ?", and now I summarized myself as the above  ^_^.

And we choose both approaches one(SPIRITS) for commercial services and the
other(Parlay) for research.

Does it happen to the same case with you (your company in this mailing group) ?

Sincerely,

Hwang Jinkyung
Intelligent Network Team
Korea Telecom

---

From: 황진경 <[email-masked]>
Date: Fri, 23 Feb 2001 10:59:57 +0900

I fully agree with you..

Parlay feasibility is not as clear as PINT/SPIRITS.

Jinkyung Hwang

Igor Faynberg wrote:

> 황진경 wrote:
> I think they should all be examined on the subject of their
> applicability.
>
> >
> I think so. Why not?

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 22 Feb 2001 20:38:31 -0500

I think so. Why not?

Igor

---

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 23 Feb 2001 10:04:19 -0600

Group,

Thanks everyone for the wonderful and high-spirited discussion! Let us, however, turn
it into somewhat more pragmatic area:

Protocol requirements are published and currently available from:
http://www.ietf.org/internet-drafts/draft-ietf-spirits-reqs-00.txt

Now is the time to focus on the SPIRITS protocol development. Also, now would be the
right time to open a discussion on the ways to make SPIRITS and PARLAY compatible, if
possible. (I've heard this idea initially from Frans Haerens (Alcatel Telecom) during
our meeting in San Diego.)

Kind regards
Alec

Igor Faynberg wrote:

> х╡аЬ°Ф wrote:

---

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 23 Feb 2001 10:25:41 -0600

Glauco,
Please see my comments inline.
-Alec

Glauco Bigini wrote:

> ...

> update for the SIP protocol in order to work correctly

Good idea. This might be quite close to the SIN Design Team work led by Hui-Lan
Lu. SIN DT Home Page:
http://www.bell-labs.com/mailing-lists/ietf-sin/

> (seems like the ITU-T....)

SPIRITS has an official liaison with ITU-T and never had any problems with
obtaining ITU-T information.