Subject: RE: [IPTEL] CPL-03 Comments and Questions

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 9 Nov 2000 10:20:46 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2000 10:22 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> 
> > -----Original Message-----
> > From: EXT Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Monday, November 06, 2000 11:39 PM
> > To: [email-masked]'; [email-masked]
> > Subject: RE: [IPTEL] CPL-03 Comments and Questions
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Monday, November 06, 2000 4:16 PM
> > > To: [email-masked]
> > > Subject: [IPTEL] CPL-03 Comments and Questions
> > > 
> [snipped]
> > > 
> > > Section 6: I don't suppose you'll want to be adding any new 
> > > features, but
> > > here is one that I think would fit in quite well: the 
> > > ability to add a
> > > location by modifying an address. Specifically, given an 
> > > address in a
> > > particular domain, create a new location which is the same 
> > > address in a
> > > different domain. For numeric phone numbers, this means 
> > > stripping a prefix
> > > and adding a new prefix.
> > 
> > Remember the application space here - we are talking about 
> scripts to
> > describe primarily end user customized/described features.
> > Modification/stripping of prefixes in phone numbers is very 
> > useful, but
> > primarily to guide system level routing in a proxy, for which 
> > CPL is not a
> > good match. 
> 
> RFC 2824 talks about administrative scripts (sections 7.2 and 
> 9.2). They
> seem like a good idea; I hadn't realized that this idea had 
> been downgraded.
> Why wouldn't CPL be a good match for guiding system-level routing?

Nothing stops administators from writing CPLs. But, its a different problem
space, and URI manipulations are just one of the issues. 

> > In any case, I'd suggest we update the text here to indicate 
> > that the CPL
> > server append some query strings to the HTTP request 
> containing these
> > parameters. Thus, in the example above, the actual HTTP 
> > request would be:
> > 
> > GET
> > http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&F
> > rom=sip:caller
> > 
> @u.edu&Call-ID=[email-masked]&To=sip:user@host HTTP/1.1
> > 
> > Sound reasonable?
> 
> Sounds good. However, in your example you've used SIP fields 
> rather than CPL
> fields. Would Call ID really be useful? 

You are correct - they should be the generic versions, not the SIP versions.

Is Call-ID useful? Most definitely. This would allow me to write an apps
that require complex, call-stateful operations.

I have come to realize recently the tremendous power of the ability to fetch
CPL scripts from a remote server using http. It allows me to write fairly
complex applications through CGI or servlet scripts on the remote http
server, with the results of those scripts being the primitive call control
operations that the server should execute, in the form of CPLs. 

This model is identical to the model for VoiceXML, whereby a voiceXML
interpreter can fetch VoiceXML scripts from a web server. You can create
very dynamic IVR apps by dynamically generating the voiceXML as a result of
the HTTP queries. This allows for a very appealing model of having
applicating execution providers that run the scripts, and these scripts are
generated by their customers, who are application providers that run the web
servers that receive the http queries. I know a few companies with this
model in the VoiceXML space.

As an example, consider a really customized call screening app, that depends
on checking the identity of the caller amongst a set of known criminals
stored in some globally accessible data repository (lets assume its acessed
using HTTP). If the person is a criminal, the call is rejected, else its
proxied to wherever I am write now. CPL has no support for complex database
queries like that. However, what I can do is fetch the CPL when the INVITE
comes, using http. The web server executes a servlet that checks this
database, and if they are on the list, generates this CPL:

<cpl>
  <reject/>
</cpl>

otherwise, generates this one:

<cpl>
  <lookup source="registration">
    <success>
      <proxy/>
    </success>
  </lookup>
</cpl>

Very nice and easy. 

Now, I've also recently come to realize that what is missing from this model
is the ability to, at some point in the execution of a CPL script, go and
fetch another one and continue from there. This is needed when more complex
processing is needed after the results of a call control operation. Consider
an application whereby I do a call forward, and if the person is busy, I
update a web page with a call log, and then forward the response upstream.
This application requires a complex piece of code to be invoked after the
<busy> output of the proxy, to update this web page. So, what I would
ideally like is that the initial INVITE fetches the following CPL:

<cpl>
  <location url="sip:[email-masked]">
    <proxy>
      <busy>
        <fetch url="http://www.dynamicsoft.com/jdrosen/myscript.pl"/>
      </busy>
    </proxy>
  </location>
</cpl>

Now, if the call returns busy, the CPL interpreter would fetch that URL,
which would return another script, which the CPL server continues processing
as if it were in the original CPL instead of the "fetch" tag.

I think its probably too late to add this kind of support to CPL; its
something I'd be interested in pursuing in an extension once CPL goes to
RFC.

Comments welcome.

> 
> So the CPL server would always automatically add the parameters to the
> source URL. In the example in Figure 26, there is already one 
> parameter; how
> would that be handled?

Parameters already there would probably not be replaced.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Nov 2000 15:08:38 -0500 (EST)

On Thursday, November 9 2000, "Jonathan Rosenberg" wrote to "[email-masked]', Jonathan Rosenberg, [email-masked]" saying:

[JR Writes:]
> > > In any case, I'd suggest we update the text here to indicate that the CPL
> > > server append some query strings to the HTTP request containing these
> > > GET http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&From=sip:[email-masked]&Call-ID=[email-masked]&To=sip:user@host HTTP/1.1
> > > 
> > > Sound reasonable?

[CH Writes:]
> > rather than CPL fields. Would Call ID really be useful? 

[JR Writes:]
> that require complex, call-stateful operations.

This seems to me like a very big change to make at this point.  The
intention of the current draft is "send a GET request containing the URI in
the location parameter, verbatim."  Changing that is a fairly big deal -- it
requires a serious chunk of thought as to exactly what parameters go into
the request.

One counter-argument is that a bit of experimentation shows that HTTP
servers (or at least Apache) seem to ignore spurious parameters in a GET
request, so in the unlikely event that anyone is using the HTTP location
lookup already, this probably wouldn't break anything.

Do you have a proposal for these headers here?  And do you think that if we
change this, we should do another WG last-call?

-- 
Jonathan Lennox
[email-masked]