Subject: Re: CPL Features

From: Tom Gray <[email-masked]>
Date: Fri, 4 Jun 1999 05:00:49 -0700 (PDT)

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

> Tom Gray wrote:
> > --- Jonathan Rosenberg

> > >
> > > 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.
> 
> Call forward no answer only takes place when the
> user is *not* present.

I was thinking of the case when the user is present but is preoccupied
by more important business such as a visitor. He can glance at the call
display and know that it is a colleague who he can contact later and so
lets the call go to voice mail. 

It still looks to me as if CPL is being used when 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.
> 
> 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.
> 

I will try to emphasize a point that I see as fundamental. Feature
Interaction is a **good** thing. Advanced services are created by the
judicious interworking of existing services. The feature interaction
problem is not about preventing interactions but creating systems in
which features can interact without, among other things, creating
indeterministic behavior and user confusion. Feature interaction
management is therefore central to any form of call processing and is
not something that can be handled casually. Indeed one of the main
advantages of an Internet based telephony system is that it provides us
with new and practical means of handling feature interaction so that
the operation of features can be managed in much more subtle and useful
ways than were possible in the old PSTN systems.

To this point, it is a good thing that call back, camp on and call
forwardings interact. This is an example of interaction that provides
the basis for creating systems which can function to the best interests
of the callers at the time of the call. To put it rather grandly, the
features can adapt to the  users' interests. having a system which
simply prevents them from interacting is creating a system that by this
fact is much less useful to the users. 

The example of the interaction between Call Back, Camp On (queuing) and
CF Busy is apposite here. It is something that has to be resolved at
run time given the knowledge of how the system is operating. Preference
tables, at least as I see them operating, cannot do this. Every call is
different.

Feature interaction management is the central feature of any call
processing system. It must be given the central place in the
architecture of the system. If this is not done the system created will
not be able to provide enough feature management to be useful to a real
user and/or not be able to evolve with the addition of new features.

_________________________________________________________
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.