Subject: [SIP] CPL, WML, VoiceXML and SIP Features

From: Tom Gray <[email-masked]>
Date: Sun, 13 Aug 2000 06:51:23 -0700 (PDT)

Has tehre been an anaysis done that outlines and
contrasts the areas of competence and teh aims of:

a) CPL, 
b) WML, 
c) VoiceXML and 
d) the call processing features and user preferences
defined for SIP?

Tom Gray

__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

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

---

From: "Kevin Davis" <[email-masked]>
Date: Mon, 14 Aug 2000 09:51:48 -0400

The XTML spec includes a brief comparison with CPL and VoiceXML
(Although this does not thoroughly answer the question.)

---

From: Tom Gray <[email-masked]>
Date: Mon, 14 Aug 2000 18:06:08 -0700 (PDT)

What I see is an endless set of features being added
to protocols which were not designed to handle them.
What was described below of different services to
different classes of users is a type of class of
service. Like most call processing, any one portion of
it is very simple to describe and probably very simple
to implement. Like most call processing, it is only
one small part of a total group of services that are
very difficult to describe and very difficult to
implement. 

What I am really asking for is a discussion that will
delimit the boundaries of what all of these protocols
will do so that we will not have an endless succession
of small features being added to these protocols. By
the time, the exercise of defining all of these small
features would be done, the market would have changed
and an entirely new set of features would be required.
Hence my analogy of painting the Golden Gate Bridge.

Tom Gray

--- Jiri Kuthan <[email-masked]> wrote:
> Tom Gray wrote:
> > An expecially important set of topics would be
> > areas in which it would be undesirable for a
> protocol
> > to be created.
> >
> > There was a suggestion here previously that CPL be
> > extended to encompass switches on authorization.
> This
> > is coming perilously near the use of CPL to handle
> > classes of service. This would be one step on an
> > infinite journey of defining a call processing
> > architecture which could not be finished. it would
> be
> > like painting the Golden Gate Bridge. When it is
> done,
> > it is time to start over.
> 
> The motivation for the CPL authentication extension
> is call 
> processing logic may depend on authentication
> status. 
> Consider, for example, a SIP-2-PSTN gateway.
> Operator of 
> the gateway may want to provide 800 and local calls
> for free 
> to anyone whereas LD calls only to authenticated
> users.
> Using CPL scripts to specify which calls will be
> accepted
> and which not seems the most natural way to me. 
> 
> Note that the CPL extension does not require
> creating 
> a new protocol.
> 
> If you still see some complexity of "painting the
> Golden
> Bridge" grade, please be more specific. (And please
> use the
> iptel mailing list rather than sip.)
> 
> Jiri