Subject: [IPTEL] [CPL] The Liaison Statement from ITU-T SG16

From: "Orit Levin" <[email-masked]>
Date: Fri, 1 Sep 2000 10:55:07 -0400

Hello!
As the result of the last SG16 meeting and on behalf of SG16, I am attaching the "The Liaison Statement" on CPL for your review and response.
Best Regards,
Orit Levin
RADVision Inc.
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 529 3516
www.radvision.com
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 22:45:48 -0400

For the benefit of this list, enclosed is the text of this liaison
statement in ASCII form.

Comments?

ITU - Telecommunication Standardization Sector 	TD -44c
STUDY GROUP 16

Portland, 25 August, 2000

QUESTIONS:	Q.22/11 (for action) 
SOURCE:	Q13/16
TITLE:	COMMENTS ON CPL DRAFT
LIAISON STATEMENT TO:	IETF IPTEL  WG on CPL
APPROVAL:	Agreed to at Q.13/16 Rapporteurs meeting (Portland, 21-25
August 2000)
FOR:	ACTION required response by 1st November 2000
CONTACTS: 	Mr. Dale Skran, Rapporteur for Q.13/16	
                Tel: +1 732 625 3003 x202
                Sonus Networks,
                4400 Route 9 South, Suite 3500,	
                Freehold, NJ 07728, USA	
                Email:	[email-masked]

Abstract: This contribution discusses possible use of CPL in the
context of H.323 and provides remarks for the current CPL
specification.

1	Trying to apply CPL to H.323 

According to our understanding, one of the original CPL goals was to
make the definition independent from the specific underlying Call
Signaling Protocol. It can be seemed as an "abstract" API definition
for a specific Application, allowing for different protocols to
actually implement it.  The CPL, as it is defined today, can be used
to describe the behavior of an H.323 Server. Nevertheless, the main
concern is that the CPL specification is not structured in a way
allowing a separation of the "abstract" concepts from their mapping
into a specific system or into specific protocol fields. Moreover,
many of the CPL "abstracts" are defined by providing examples or
pointers to SIP-related IETF documents. This forces the writer of the
CPL script to become familiar with the details and considerations
behind the SIP design.  This situation led for the inclusion of a
limiting H.323 interpretation into the body of the CPL definition. In
some cases, this interpretation is inconsistent with the SIP
interpretation of the CPL.  2 The Proposed "Roadmap" Based on the
"advanced" CPL standardization stage within the IETF, the following is
proposed for the consideration:

For the current CPL version, it is proposed to correct the "editorial"
errors, described in the following chapter, within the CPL document.

H.323 community will define a more flexible interpretation of H.323
behavior being expressed by the CPL. New "features" may be introduced
by expanding the CPL definitions. (This "extension" practice, in some
cases, is allowed by the CPL specification.) The output of this work
will be included into H.323 "Annex O" and will be published as an
Informational RFC.

CPL nodes differ in their "abstraction level". A certain group of the
CPL nodes (such as dealing with the time conditions) is naturally not
dependent on the Call Signaling Protocol. Another group, such as
"address-resolution" look-ups, is dependent on the System
definition. In addition, the CPL "address-processing" and
"string-processing" nodes define a "lower-level" logic, binding the
CPL definitions with the certain fields of the Call Signaling
messages.

Therefore, for the next CPL version, It is proposed to re-arrange the
CPL Specification by grouping the nodes, based on their "abstraction
level".  
- For the "low level" nodes, it is proposed to split between
their "abstract description" and the actual mapping into a specific
Signaling protocol
- For the benefit of the CPL user (i.e. the CPL script writer), it is
also proposed to define the meaning of each "node" and provide its
"design considerations" from the application point of view, without
referencing to the SIP details. 

3 Specific H.323 Comments 

3.1 Thedefinition of "incoming" and "outgoing" 

From the [CPL]: "Two top-level action names are defined: incoming, the
action performed when a call arrives whose destination is the owner of
the script; and outgoing, the action performed when a call arrives
whose originator is the owner of the script."

In H.323, there is no explicit concept of the "intermediate Call
Signaling Server" and the CPL "destination" field will NOT usually
hold the address of the Call Signaling Server itself. Therefore, it is
proposed to revise the quoted above definition.

3.2 Mapping of ASN.1 structures into ABNF

Various H.323 ASN.1 definitions should be mapped to ABNF in order to
be used within text based languages and protocols. Examples include
H.225.0 AliasAddress definitions for PartyNumber and mobileUIM; and
the TransportAddress definition. It is proposed to introduce such
definitions in H.323 "Annex O" and reference them (or reproduce them
till the "Annex O" is decided).

3.3	CPL "Address Switch"

Current CPL definition has a concept of two, applicable to H.323,
"address" field definitions: "origin" and "original-destination". On
the contrary, H.323 defines many address fields that may be of
interest of the CPL user. Moreover, more then one alias may exist in a
single H.323 message. Mandating of choosing one single alias out of a
number of possibilities is limiting for H.323 systems.

The current CPL version allows for an expression like that: "If one of
the alias fields of different types matches, the specified for it,
condition, then ...". Unfortunately, this option is left out of the
CPL Specification.

Based on the remarks above, it is proposed that the current CPL
specification will state that the "Address switch mapping for H.323"
Chapter is "an illustration only" for how the CPL fields can be mapped
into the H.323 fields.

The third CPL "address" definition is called "destination". It
reflects the SIP concept of intermediate Call Signaling
Server. Therefore, the current mapping of H.225.0 redirectingNumberIE
into the CPL "destination" concept is inconsistent with the SIP
interpretation of the same field. For example, in case of the
"incoming call", the H.225.0 destCallSignalAddress field fits the
concept of CPL "destination" more closely. (This redirectingNumberIE
element is, by mistake, called a "redirectedNumber" by the CPL)

3.4	Location Lookup

The "Lookup" CPL node is a Call Signaling-independent concept. It fits
both the H.323 and the SIP architectures. Nevertheless, bounding of
the "location lookup" itself with the further operations to be applied
to its results (such as capabilities filtering), seems to be a
limiting design consideration. It is proposed to define these two
actions (i.e. the lookup and the filtering on the output) as two
separate CPL nodes.

3.4.1	"Caller Preferences and Callee Capabilities"

As a part of CPL "Location Lookup" Switch, a filtering capability on
"caller preferences" is defined. These CPL parameters are based solely
on the "caller preferences" specified by one of the SIP extensions
["Caller Preferences and Callee Capabilities"].

The "Generic Framework", lately introduced into H.323, has essentially
the same concept. Although, the following difference exists: CPL is
limited to the scope of a Call. The "Generic Framework" of H.323
addresses both the Registration and the Call Establishment stages.
H.323 Community will work to apply the "Generic Framework" to the CPL
work.

3.5	"Location"

A significant problem is that CPL generates outbound call signaling
based on a Location element which currently can only be a URL.  Some
significant data that should be used in the outgoing signaling, e.g,
redirection reason, are not available in current H.323 URL and may not
naturally fit into such URLs.  It would be desirable to have a more
flexible way to set such parameters, but this may require more study
than can be accomplished for the current version of CPL.

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

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