Subject: [IPTEL] CPL features

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Aug 2000 02:27:16 +0200

Hi,

some questions on CPL:

1) making string-switch more general
   - Why are values of parameter 'field' limited to an 
     enumeration of a couple of well-known elements? 
     Though the advantage of the well-known elements is
     they may be easily interpreted for different
     call signaling protocols, I do not see a reason why 
     to prohibit arbitrary values. This would allow CPL 
     script writers to refer to any new fields.
   - Would not it be helpful to support regular expression
     matching in addition to 'contains' and 'is'?

Example: 
 <string-switch field="Payment"> 
    <string matches ".*penn(y|ies).*"> ...

2) authentication support
   - Could call processing logic depend on the authentication
     status? E.g., a CPL script installed at a SIP proxy may want 
     to deny calls from unathenticated users to PSTN. 

Example:
 <address-switch field="original-destination" subfield="address-type">
	<address is="tel">
		<authenticated-switch>
			<authenticated status=no_authentication>
				<reject status="401" reason="..." />
			</authenticated>
		</authenticated-switch>
	</address>
  </address-switch>

Jiri

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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 11 Aug 2000 15:13:15 -0400 (EDT)

>      script writers to refer to any new fields.

This was intended; notice that the DTD attribute list for string-switch is 

<!ATTLIST string-switch
   field         CDATA    #REQUIRED

I.e., the value of the "field" parameter can be arbitrary character data.  I
will clarify that this is intended.  (Of course, if you upload a CPL with a
switch field the server doesn't support, it will reject it.)

>      matching in addition to 'contains' and 'is'?

Version -00 of the CPL had glob matching (similar to, though weaker than,
regex matching) for string switches.  It seemed to be the consensus of the
working group that this was too complicated for a language designed to be
created by naive users, as globs and regular expressions are notoriously
hard to express in GUI form.  It seemed that most of the uses for pattern
matching were covered by the way that address matches now split up addresses
into subfields, since I didn't think that any of the non-address forms of
pattern matches were particularly useful.

>      to deny calls from unathenticated users to PSTN. 

This is reasonable.  However, I think it should (at least at first) be
defined as an extension to the CPL, as I don't want to get into the
complexities of "who authenticated this, how was it authenticated, how do I
know I can trust the signer", etc.  Just a binary yes/no for authentication
seems too weak for general purposes, though it'd be fine for some specific
instances.

If this is found to be generally useful and these isues are worked out, I
think it could be folded into a future version of the CPL.  There's enough
push to get CPL finished and sent to last call now, though, that I don't
want to get into it.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Aug 2000 17:11:59 -0400

> switch field the server doesn't support, it will reject it.)

Seems like a recipe for interoperability problems. How can the script
writer know what
fields are supported by the server? Write a script, submit, see if its
rejected, and if so,
try a different field?

I would much prefer to specify specific fields. 

> push to get CPL finished and sent to last call now, though, that I don't

I agree. We have been playing around here far too long. Let us FINISH
CPL, based on the current
functionality, and then see what our implementation and deployment
experience show.

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 15 Aug 2000 03:01:13 +0200

> I would much prefer to specify specific fields.

Checking the scripts by servers does not seem so helpful to me:
1) support for arbitrary headers accomplishes dealing with fields unknown
   at the time of writing specification and implementation;
   checking header fields if they are well-known beats this purpose;
2) the rejection mechanism may be difficult if you use, for example,
   FTP to upload the CPL scripts.
It is responsibility of users and/or their programming tools to
write meaningful header names. The server may process both
known and unknown header fields.

It's a trade-off between CPL's ability to adapt to new SIP extensions 
and the built-in language ability to eliminate unwanted bugs. I personally 
prefer the former given SIP development pace. Unwanted bugs may be still 
prevented by tools used for generating CPL scripts.

Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Aug 2000 00:02:35 -0400

Allowing checking for arbitrary headers and values impacts the ability
of a script to work meaningfully for both SIP and H.323.

It also makes development of tools to build these things more complex. 

Remember the objective - a simple tool for building services, aimed
primarily at service creation and customization by end users. If you
want real flexibility, you need servlets or something like that.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 19 Aug 2000 03:56:37 +0200

draft-ietf-iptel-cpl-02 states "Implementations of CPL are expected
to take place both in ... servers and in ... clients" ...
"This document primarily addresses the usage in servers".

Does it mean that CPL usage in end-devices is not documented in
this I-D but CPL could be used so as is? Or are any
CPL extensions anticipated for such usage?

-Jiri

--
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Aug 2000 01:13:12 -0400

Jiri Kuthan wrote:
> this I-D but CPL could be used so as is?

Yes.

 Or are any
> CPL extensions anticipated for such usage?

There are additional things that might make sense in end devices
(distinctive ring, for example), but are not covered in CPL as CPL is
meant for servers. Currently, there has been no discussion of adding
such things to CPL.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 21 Aug 2000 14:44:36 +0200

[...]
> meant for servers. Currently, there has been no discussion of adding

If we wanted to deploy CPL in end-devices, the missing piece would be
a kind of 'ring' command, most likely loosely coupled with user 
interface. For example: 

<address is="jane">
  <ring UI_profile="flesh_and_play_some_music_if_friends_call" timeout=10>
	<noanswer>
		<sub ref="voicemail"/>
	</noanswer>
  </ring>
  <otherwise>
	<reject status="Reject" reason="DnD"/>
  </otherwise>
</address>

An alternative would be to define ringing as default action 
in end-devices. Drawback: cannot be parameterized.

Reasons for running CPL in end-devices:
- call processing logic works even if signaling does not go
  through proxies;
- call processing overhead distributed to end-devices

Jiri

-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Aug 2000 01:06:29 -0400

I'm sure there are other things too besides distinctive ring. In any
case, we agreed to not worry about that right now. The objective at the
moment is to complete the CPL spec along the model and requirements we
have defined. 

-Jonathan R.