Subject: Re: Few comments on requirements for CPL

From: Jonathan Lennox <[email-masked]>
Date: Thu, 5 Nov 1998 16:00:15 -0500 (EST)

Apologies for not replying to this sooner.

On Fri, October 9 1998, "Claudio Catania" wrote to "[email-masked]" saying:

> 1)
> One of the things that could be achieved by CPL is the definition of a
> controlled environment to create services on a "network device". This
> seems to be very similar to the approach taken by IN community when they
> tried to define SCEs for IN components.
> *Does anyone have an opinion on how CPL could be related to those
> efforts?

The services defined by CPLs are conceptually very similar to what's created
by an SCE, and in fact the existence of SCEs was one of my major motivations
for deciding that a directed acyclic graph is powerful enough to define most
of the services we want to define.  Many of the specifics are quite
different, of course, because of the differences in IN and IP architectures.

Unfortunately I haven't been able to find much public information on actual
technical details of commercial IN SCE's, as opposed to marketing
information or broad overviews.  If anyone has any good references to this
I'd be very interested.
 
> 2)
> I think that, after having spent several years trying to define good
> controlled service creation environments for basic reliable services,
> the IN community is struggling to enhance their simple model to add
> distribution, flexibility and efficient
> communication between network elements. Services for VoIP may have
> completely different requirements but, at the end of the day,  we are
> talking about server based call processing languages, therefore there
> may be  a lot of similarities.
> *Is CPL in a better position to address the issue of combining
> flexibility with controlled environment for service creation?

I'm not quite sure what you're getting at here.  Designing the language to
be smoothly extensible is a very important architectural consideration, of
course, and the flexibility of the IP telephony architectural model should
help (as opposed to IN, which started with the basic call model and layered
additional services on top of it).  Is this what you're asking?
 
> 3)
> My understanding is that CPL proposes to run up to four different
> scripts every time a service  is invoked (user and administrator scripts
> for both originating  and destination party).

My example may have used four, but it should really be considered to be
"arbitrarily many".  Because of the flexibility of the IP telephony
architecture, every server and client has to expect that other servers can
engage in certain kinds of behaviors -- forking proxies, surprising message
forwarding, etc -- and take these things into account in its own behavior;
this is true whether any given server or client is controlled by a CPL, some
other CPL-like mechanism, or an arbitrary hard-coded behavior.

> VoIP client and server
> providers will have to ensure compatibility between them all. Now it is
> very likely that the former will try to sell their own administrative
> tools to configure and remote administer their clients while the latter
> will probably be reluctant  to share a common service environment (I
> could be wrong, but I think that this is exactly what happened to  IN
> SCEs and service languages).
> *Who would really benefit from a standardized way of writing services in
> CPL?

I'd be interested in hearing from people developing clients and servers as
to whether a standardized CPL is something they'd be interested in
implementing.  I'd imagine that the more-open Internet process would
encourage people to be more inclined to have this be standardized.

> *How will VoIP client and server providers deal with potential conflicts
> between scripts running on different environment? (I guess that the
> draft identifies these problems and calls them server to server
> interactions;  I could not figure out how the problem is solved.)

Every script inputs and outputs data equivalent to a SIP or H.323 message
(if you have multiple scripts running in the same server these messages may
not actually ever exist on a wire, but the high-level informational content
is there).  So, the problem we have to consider isn't "script interaction"
per se but rather the broader "iptel interaction", some of which has been
solved in the standards and some of which we will come to understand with
further implementation experience.

> 4)
> According to the draft, CPL can be implemented in several languages (see
> the requirements), but I got the impression that the adopted one will be
> XML.
> *Why? Is there a compelling reason for which XML should be used? Are the
> reasons mentioned in the draft good enough?
> *What is good in using XML for services?

It's what I'm currently favoring, yes, though if there's a strong proposal
in favor of something else, I'd be glad to go with that instead.

My initial motivation for using XML was to have an existing syntax which
maps naturally onto the sort of directed acyclic graphs we see in service
creation environments.  It also has the advantage that it can be
*completely* understood by creation tools, unlike more complicated
languages.
 
> 6)
> My understanding is that approaches based on a expressively-complete
> languages (TAPI, old TSAPI...) successfully hide the call processing
> coming from different signalling stacks. There had been several attempts
> to standardize those solutions but no one reached global consensus. I
> guess that this happened  mainly because vendors did not want to open
> their platforms thus providing the aprropriate drivers for standardized
> environments.
> *If  CPL has the same requirements, will VoIP server vendors behave in a
> different way and open up their APIs to CPL?

Again, comments from vendors are very welcome.

-- 
Jonathan Lennox
[email-masked]
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 Nov 1998 22:06:07 -0500 (EST)

On Thu, October 29 1998, "Karen Goettler" wrote to "lennox, [email-masked]" saying:

> I teach an 'IN Networks and Services' class at a local university and have
> been wondering, since you are talking about VoIP Services and the VoIP CLP,
> 'How are VoIP services triggered?'.
> 
> It seems like the services should be triggered as part of the CPL, but does
> the CPL for VoIP have defined states where services could be triggered?

In my current conception of it, a CPL script would be triggered by the
establishment of a IPtel transaction -- e.g., for SIP, the arrival of an
INVITE request at a server.  While it would in principle be possible to have
scripts triggered by later events in the transaction (the equivalent of
later points in the IN 'basic call model') it seems to me that it would
complicate matters, and it would be easier just to have a CPL script start
off with an instruction with the semantic meaning "do the default action,"
and then cut in with the specialized behavior at a later point.

> Also, where will the CPL run, on the end device or at a centralized location
> on the network?  Is the idea to use a model like wireless telephony where
> all of a users' service information is stored in a central network location
> (the HLR)?

Some CPL scripts could run on an end device, but many of the simple useful
services will run on a network device.  So in this sense it's similar to
your description, but given the distributed nature of Internet services
calling it "centralized" is somewhat of a misnomer.  In the SIP model it
would be a proxy server.