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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 6 Nov 2000 23:38:50 -0500

> -----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
> 
> 
> A few miscellaneous comments and questions on draft-ietf-iptel-cpl-03:
> 
> In Figures 2, 19, and 29, why doesn't the "location" node in 
> the "voicemail"
> subaction have a clear="yes" attribute? Without it, won't 
> there often be two
> locations in the location set when "redirect" is invoked?

No. From 7.1:

   Once a proxy action completes, if control is passed on to other
   actions, all locations which have been used are cleared from the
   location set. That is, the location set is emptied of proxyable
   locations if the ordering was parallel or sequential; the highest-
   priority item in the set is removed from the set if ordering was
   first-only.  (In all cases, non-proxyable locations such as "http"
   URIs remain.)  In the case of a redirection output, the new addresses
   to which the call was redirected are then added to the location set.

> 
> Section 5.1.1: This section makes it sound like visual separators are
> stripped from the tel subfield for tel URLs but not for sip 
> URLs. Is that
> the intention? 

No. Separators should be stripped from sip URLs as well. Good catch.

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

> 
> Section 6.1: Should a default priority be defined?

Yes. I believe the default is 1.0.

> 
> Section 6.2: How does the source URL work? Is HTTP used to 
> retrieve the
> location URL from the source URL?

Yes.

> How does the source URL get the
> information that it needs to determine the location URL (does 
> the CPL script
> pass the addresses to the source URL)?

Right now, there is an assumption that the source URL points to static
content that contains the location URL. Thus:

<lookup source="http://www.foo.com/mylocation.txt">

where mylocation.txt contains:

sip:[email-masked]

In reality, thats far less useful that having a cgi script or servlet on the
web server automatically generate this URL as a result of the http query.
Doing that effectively is going to require the servlet to have additional
information about the incoming call, such as the caller, called party,
request URI, and Call-ID. Is that what you mean?

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&From=sip:caller
@u.edu&Call-ID=[email-masked]&To=sip:user@host HTTP/1.1

Sound reasonable?

> 
> Section 6.3: "[Location removal] is primarily useful 
> following a lookup
> node": Could you provide an example of how this works?
> 
> Section 8.1.1, item (3): Why would the SIP From header of an incoming
> message be used as the basis of the Reply-To URI?

Because the point is to be able to get back to the caller. You want to be
able to reply to the email that comes, and it gets sent to the person who
called you.

> 
> Section 9: Should it say whether subaction names are case-sensitive?
>
> Figure 29: Uses "address contains", but according to figure 
> 4, "contains"
> can only be used with the "display" subfield. Also, this 
> script doesn't take
> care of the "failure" case.
> 
> - Cliff Harris
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

---
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: [email-masked]
Date: Tue, 7 Nov 2000 09:22:10 -0600

> 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
> 
> 
[snipped]
> primarily to guide system level routing in a proxy, for which 

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?

[ snipped ]
> sip:[email-masked]

Figure 26 in cpl-03 has the following: 
<lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
               timeout="8">

> request URI, and Call-ID. Is that what you mean?

Yes, that is exactly what I mean.

> @u.edu&Call-ID=[email-masked]&To=sip:user@host HTTP/1.1

Sounds good. However, in your example you've used SIP fields rather than CPL
fields. Would Call ID really be useful? 

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?

> > node": Could you provide an example of how this works?
[snipped]
> > care of the "failure" case.

BTW, I'm not sure why the restriction was placed on the use of "contains";
the script in Figure 29 looks quite reasonable to me.

---

From: [email-masked]
Date: Mon, 13 Nov 2000 15:22:17 -0600

This appears to be a very powerful idea.

A couple of potential drawbacks:
1. Reduced performance: scripts can't be entirely pre-parsed, since a
different fragment may come back from the Perl script every single call;
2. There could be compatibility problems; namely, the Perl script might
return a fragment using a namespace not supported by the CPL server.

In some cases, there may be simpler ways of achieving the same goal. For
example, consider the following as a way of addressing your "criminals"
example:

<lookup source="http://www.criminals.com/locate.pl" timeout=5">
  <success>
    <reject/>
  </success>
  <notfound>
    <lookup source="registration">
      <success>
        <proxy/>
      </success>
    </lookup>    
  </notfound>
</lookup>

It just uses existing CPL syntax (but it assumes that the originator's URL
will be passed to the Perl script, which passes back the originator's URL if
and only if it is the URL of a criminal).

Another possibility would be to add an action to invoke a script that
returns an arbitrary string, and to add a new string-switch field to look at
the result of the script. Then you could do something like this:

<fetch-string source="http://www.phonenumbers.com/classify.pl" timeout=5">
  <success>
    <string-switch field="script-result">
      <string contains="criminal">
        <reject/>
      </string>
      <string contains="telemarketer">
        <reject/>
      </string>
    </string-switch>
  </success>
  <notfound>
    <lookup source="registration">
      <success>
        <proxy/>
      </success>
    </lookup>    
  </notfound>
</lookup>

Another thing that might be useful is a generalized non-signalling action;
i.e., invoking a script that runs in parallel to the CPL script and that
does not return a result:

<busy>
  <spawn url="http://www.example.com/busy_counter.pl">
    <!-- The following has nothing to do with the perl script -->
    <location url="sip:[email-masked]">
       <redirect/>
    </location>
  </spawn>
</busy>

- Cliff Harris

> Sent: Thursday, November 09, 2000 10:21 AM
> To: [email-masked]'; Jonathan Rosenberg;
> [email-masked]
. . . 
> 
> 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.
> 
> 
> -Jonathan R.
> ---