Subject: Re: [SPIRITS] Parlay vs SPIRITS

From: [email-masked]
Date: Fri, 23 Feb 2001 15:30:53 +0100

Hi all,

I also agree it is a good idea to bring this issue to the mailing list.

I think Igor has explained quite well what the relationship between an API
and a network protocol is.  Besides the technical aspects, Parlay has many
business implications, since it opens the IN-like service development and
service offering to new actors (small companies and independent
Applications Service Providers). It is also true that Parlay is gaining
support in the industry (in my opinion because the OSA API specified by the
3GPP is based on it).

But, going back to the technical side, the Parlay API would allow an IP
application (without a specific protocol) to receive and send INAP messages
to an Intelligent Network. Thus it can be seen as a competitor to SPIRITS.

SPIRITS will specify a protocol for the same purpose (an IP applicaction)
can receive and send INAP messages to the IN.

I guess that there are some advantages and disavantages for each option
(let us think of big scale networks and not entreprise networks). Probably
someone can add light into this comparison?.

I do not think it makes sense Parlay API to be extended to support SPIRITS
protocol (it would mean using an API to convert to a protocol -SPIRITS-
which is converted to another -INAP-), but I may be wrong. Any opinions ??.

Best Regards,

Jorge Gató

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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 23 Feb 2001 22:23:04 -0500

[email-masked] wrote:
> 
>...
>... the Parlay API would allow an IP

I would word this just a bit differently: "The Parlay API would allow an
IP apllication to SPECIFY [rather than allow] the IN-related information
to be exchanged with PSTN."

> can receive and send INAP messages to the IN.

Exactly, although, instead of the "INAP messages," I would refer to a
subset of INAP parameters. In addition, SPIRITS would need to take care
of registration, call disposition, security and other things.

> someone can add light into this comparison?.

The rules of top-down design dictate that the API be specified ahead of
any protocol that would support it.

> which is converted to another -INAP-), but I may be wrong. Any opinions ??.

I completely agree with Jorge (as should be clear by now). And it would
make sense to ensure that SPIRITS support Parlay (and, as we may hope,
any similar API that may come later). One protocol can support many APIs
(and, conversely, one API can be supported by many protocols). In
effect, an interesting outcome of the SPIRITS work would be
demonstration of SIP's (or rather a SIP subset) support of PARLAY.

I also think that Alec called on us today to do just that. Could someone
who knows Parlay write and I-D bringing the specifics to
SPIRITS--scenarios, parameters, etc.?

Igor