Subject: Re: CPL Features

From: Tom Gray <[email-masked]>
Date: Fri, 14 May 1999 10:42:45 -0700 (PDT)

--- Jonathan Rosenberg <[email-masked]> wrote:

> 
> CPL definitely does not handle certain features -
> call waiting, for
> example. In particular, features which require user
> input after the call
> is established, or features which require call
> state, are not possible.
> In an IP telephony context, many, if not all, of
> these features are most
> easily supported in end systems. CPL is best at
> providing call routing
> related services; the infinite flavors of
> forwarding, follow-me,
> screening, and so on. These are services which
> require network support,
> often since the user may not be logged in or
> otherwise available. I
> don't think we can enumerate them all. If we could,
> may as well number
> them, do away with CPL, and have users select a
> service by number. But,
> after all, CPL is a scripting language of sorts, and
> the point is we can
> use it to develop new services (at least those
> supportable within the
> primitives CPL provides. Its not Turing complete, so
> everything is not
> possible).
> 
> This more restricted scope helps mitigate many
> feature interaction
> problems. There are some we know of (the call
> forward/call screening
> interaction), and these are documented in the
> framework. If you know of
> any other interactions you see, please post them.
> 
> It would also be helpful if you could point out
> particular features you
> feel are useful yet not supported by CPL.
> 

The CPL documents describe features like Call Forward Busy, Call
Forward No Answer and the refusal of anonymous calls. These certainly
are features that have meaning only if the user is present.
Additionally a useful feature to have is the ability to set an
automatic call back on a user who is not registered or present and
another is to camp on to a busy line (ie queue till the user becomes
free.  These are features that would interact with the call forwarding
features. The resolution of these interactions is  something that a
user would like to decide upon during a call with the knowledge that he
has at the time. It is not something that he could set up in a
preference table.

_________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 May 1999 02:46:54 -0400

Sorry for the very late reply... forgot I didn't respond to this.

> are features that have meaning only if the user is present.

Call forward no answer only takes place when the user is *not* present.

> free.

The first one (callback) is not one I think CPL is good at doing. The
problem is that in the callback case, the called party calls back the
calling party when available. This is easily done in a user agent
(assuming it has access to call logs when it logs in), but harder in a
SIP server since the SIP server doesn't usually initiate calls or
maintain call state. None of the features we're targeting for CPLv1
require call state or having the server initiate calls, bridge calls,
etc.

The second service is not something I think that we would do in the
first version (it requires call state in the SIP server), but possibly a
later one. In that case, the CPL might look something like:

<proxy>
  <busy>
    <camp-on timeout="1h">
      <failure>
        <respond status="noanswer"/>
      </failure>
    </camp-on>
  </busy>
</proxy>

and for forwarding:

<proxy>
  <busy>
    <location url="sip:[email-masked]">
      <proxy/>
    </location>
  </busy>
</proxy>

So, if the called party specifies the service ala CPL, there would be no
feature interaction between forwarding and camp-on since they CANNOT
represent both at the same time in the same place in CPL. 

Interactions do arise if the called party specifies one of them (say
camp-on on busy) and the calling party tries to specify a different one
(forward on busy). This is not strictly a CPL issue, since somehow there
is here a way for the caller to ask for this feature for this call (the
caller preferences document is the general mechanism for this). In that
document, we mention that there is this generally hard interaction
problem. I don't have an easy answer for how its done, nor do I think
there is one right way.

-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

---------