Subject: CPL -- Two questions about is future

From: Tom Gray <[email-masked]>
Date: Mon, 22 Mar 1999 06:54:30 -0800 (PST)

Hi

(1)
Reading the CPL documents, I get the impression is that only the first
part of a larger envisaged cpapbility is being described.

(1a)
 What are the currrent features that being planned for specificaiton
in CPL?

(1b)
How do these fit into the larger planned capability?

(2)
In the requirements document, mention is made of the feature
interaction problem of siganlling ambiguity. The example given is the
classic 'call waiting' and 'three way calling' interaction in which
the user may be confused by since the hook switch signal given may
result in two incompatible actions - answering the call waiting party
or going to conference dial tone to add another party to a three way
call. The answer given  in the requirement document is to refer to the
explicit nature of signalling in internet telephony protocols as
resolving this ambiguity.

This seems to miss the  point of the interaction. The interation
problem does not arise here internal to the protocols. There is no
indeterminacy which results in unpredictable system operation. Rather
the interaction occurs because of race condition between the user
becoming aware of call waiting and his actions. The interaction
manifiests itself at the user in his confusion.

We must recall that some people will be using ordinary telephones to
access IPTel servcie and the hook switch ambiguity will still cause
confusion. Secondly even if someone is using a special set which has
more explicit signals, the problem still arises since:

a) keys or soft keys must be provided and controlled which indicate
the possibiliites at any point in the  call. Thus the software which
controls the set must handle the interaction and worse yet must be
aware  of the state of the call in the server. A whole host of new
interaction bugs lie await here.

b) since it is user confusion which is the manisfistation of the
undesired interaction. The user must be trained on the use of the
multiple possibilities presented by such special set so that one cause
of confusion is not subsitituted for another.

In brief, I do no think that the  explicit signalling in IPTEL
protocols has much to add to the solution to this interaction. 

Tom Gray
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 22 Mar 1999 17:26:36 -0500 (EST)

> How do these fit into the larger planned capability?

There are a huge number of things that could, in principle, be controlled by
a CPL: automated voice-response systems, which need mid-call information
about the media stream; complicated call-queueing and call-distribution,
where the distribution point needs to know about end systems' state, and
events in one call trigger behavior in another call; end-system API control,
with distinctive ringing and the like; and so on and so forth.  Some of
these were mentioned in the examples section of Requirements draft, but many
more could be invented.

The number of possibilities is so vast, though, that I thought it would be
better to define the simple, basic functionality -- those behaviors which
can be expressed as "proxy", "reject", and "redirect" of a single call setup
-- in a scheme which would be extensible enough to allow all the other
functionality to be included.  As long as we have a general idea of the
sorts of more complex features we want to add in the future, I think this
will be workable.

In general, I think the additional action nodes would consist of in-call
nodes, which come from an out-arrow of proxy, as mentioned in the current
CPL draft; inter-call nodes, "queue" and "distribute"; and end-system nodes,
such as "alert".  The details of these remain to be worked out, but I think
this is roughly the level of abstraction the CPL should use.
 
> protocols has much to add to the solution to this interaction. 

Well, clearly there is still a potential problem here, but it isn't a
*signalling* problem; it's a *user interface* problem.  Whereas traditional
analog telephones have this one signal, "flash", with which they communicate
to their servers, there's no concept of anything like this with SIP or
H.323.  (I'm not sure what's happening with Megaco, so I won't address that
here.)  Instead, there's no way for an IPTel device to confuse a "change
current call connection" signal with a "begin to add additional party"
signal (not to imply that the actual signals would be precisely like this,
but hopefully you understand the idea).

From the point of view of an IPTel system, a traditional telephone isn't an
end system; the end system is the traditional telephone combined with its
IPTel gateway.  Any ambiguity in the signalling between the different parts
of the end system is entirely the end system's problem.  Similarly, an
Ethernet phone which looks like and emulates a traditional telephone needs
to send the appropriate IPTel signalling information, whether or not it's
trying to use "flash switchhook" as its user interface for these events.

I don't understand your point about the client knowing "the state of the
call in the server".  Server don't, can't, and shouldn't know all the
information about the state of clients; this is inherent in the IPTel
architecture.  Servers have to compensate for this.  What scenario are you
envisioning here?

-- 
Jonathan Lennox
[email-masked]

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Mar 1999 22:41:03 -0500

> > part of a larger envisaged cpapbility is being described.

Yes.

> >  What are the currrent features that being planned for specificaiton

Predominantly call-routing related features, along the lines of
call-redirect based on X, where X can be caller, time of day, and other
call parameters. There is also call reject, call forward, and email
notification, also based on the same parameters. You should check out
the actual CPL document, which describes these in some detail.

> sorts of more complex features we want to add in the future, I think this

KISS (keep it simple stupid) is *THE* primary engineering goal for
CPLv1. This stuff is fairly new, and we need to do some basic, yet
useful stuff first to get operational experience.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------