Subject: [IPTEL] Reply to SG16 liason

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Oct 2000 02:30:02 -0400

Folks,

Below is the response I plan to send to ITU to the liaison they sent
regarding CPL. All of the items that are mentioned as things we will address
are already incorporated into the -03 draft.

Comments are solicited. If none are received, I'll send one week hence -
Nov. 3.

THanks,
Jonathan R.
> -----Original Message-----
> From: Jonathan Rosenberg 
> Sent: Friday, October 20, 2000 2:28 AM
> To: Jonathan Rosenberg
> Subject: test
> 
> 
> 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.

This does not appear to be the case in the most recent version of CPL.
Active steps were taken to define actions in terms of generalizations, and
then define mappings to SIP and H.323. The address-switch is a good example
of this.

> 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 is a side-effect of the expertise of the authors and developers of CPL.
If, as proposed, ITU incorporates an interpretation of CPL for H.323 into
Annex O, this document is better suited to address examples in a more H.323
centric fashion.

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

We welcome, as always, input from all sources.

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

We would urge caution and care in defining these extensions. If they result
in an alternate CPL which is really not compatible with the IETF
specification, end users will need to know which system is in use in order
to prepare the IETF version, or the SIP version. This defeats one of the
stated goals of CPL.

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

It is agreed that there are different levels of abstraction. We will add
text indicating the grouping. The document is more or less already organized
along these lines (switches are primarily call signaling independent).

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

THis is largely done, but it is agreed more work could be done to more
cleanly separate things. 

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

Clarification is needed here. No where in CPL is the term "intermediate call
signaling server" used. Neither is the text indicating that the CPL
destination field will hold the address of the call signaling server.

It can be argued that the incoming actions are taken on originating
gatekeepers, and executed on behalf of the user in the sourceAddress field.
Outgoing actions are taken on terminating gatekeepers, taken on behalf of
the user in the destinationAddress field. Thus, it seems that there is a
straightforward mapping from the general statement in the CPL specification
to H.323.

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

Sounds like a good plan.

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

What is needed is to generalize the definition of origin, destination, and
original-destination, and then let ITU SG16 determine the best way to map
these to H.323. We would thus propose that the H.323 mappings for
address-switch (and indeed, for all tags), be moved to an informational
appendix for example only.

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

Agreed, as above.

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

It is our proposal to define this field in general terms, and then let ITU
SG16 define the mapping it feels is most appropriate.

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

It turns out that doing so eliminates the possibility of the default action
being to apply caller preferences. This is important. These attributes for
lookup can just be ignored on H.323 systems.

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

That would fit into the general proposal of allowing ITU SG16 define the
mapping of the CPL parameters to H.323.

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

We would argue that such things are most definitely suited for URL
parameters, as they have applications in other spaces. 

Thank you for your input.	

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