Subject: [IPTEL] CPL: Timezone issues

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Jul 2000 18:04:52 -0400 (EDT)

I think I've mentioned this before on the list, but I'll mention it now as a
follow-up to my two earlier messages.

The scheme for timezones I came up with in the CPL -01 draft doesn't work.
Timezones are, unfortunately, much more complicated than can be described by
the simple scheme I came up with.  Politicians over the years have come up
with *amazingly* bizarre timezone rules and transitions.

The best reference for all things timezone related is the Olson TZ database
and its mailing list archive: <http://www.twinsun.com/tz/tz-link.htm>.

This problem has already been confronted by an IETF working group: CalSch
had to deal with what timezone scheduled events take place in.  Therefore,
one thought for timezones would be to deal with them simply by referencing
section 4.8.3.5 of RFC 2445; the grammar for the CPL <timezone> tag would
become simply

  Tag:         timezone
  Parameters:  name      Name of this timezone
               tzurl     Valid RFC 2445 TZURL
  Outputs:     none

The problem with this, however, is that as far as I know no one actually has
any TZURLs deployed anywhere.  There's been some talk about defining a
standard repository for these, but it doesn't seem to have come to anything.
Additionally, putting this in the CPL spec means that any CPL implementor
also has to build most of an RFC 2445 parser, which seems like a bad idea.

Another possibility would be to reference the names used in the Olson TZ
database directly; this is liberally-licensed open-source code, and it's
already the database used for system timezone information on a wide variety
of Unix systems.  However, it's not a standard of any kind, so citing it
normatively would probably be bad.

A third possibility would be (again referencing RFC 2445) to use their TZID
parameter, from section 4.8.3.1.  This is defined as follows:

   Description: This is the label by which a time zone calendar
   component is referenced by any iCalendar properties whose data type
   is either DATE-TIME or TIME and not intended to specify a UTC or a
   "floating" time. The presence of the SOLIDUS character (US-ASCII
   decimal 47) as a prefix, indicates that this TZID represents an
   unique ID in a globally defined time zone registry (when such
   registry is defined).

        Note: This document does not define a naming convention for time
        zone identifiers. Implementers may want to use the naming
        conventions defined in existing time zone specifications such as
        the public-domain Olson database [TZ]. The specification of
        globally unique time zone identifiers is not addressed by this
        document and is left for future study.

This is more-or-less the same solution I came up with in CPL draft -00, which
everyone hated, except better explained; that is, timezone names are
entirely locally-defined at the server.

Probably the best compromise would be to combine cases 1 and 3; a <timezone>
tag has either the parameter "tzid" or "tzurl", both as specified in RFC
2445, and the script server SHOULD either handle them or complain about them
at script upload time.  Hopefully, sometime in the future someone will build
an actual normative globally-unique timezone registry, and we can reference
it then.

Any thoughts on all this?

-- 
Jonathan Lennox
[email-masked]

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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Jul 2000 18:17:18 -0400 (EDT)

The primary area still missing in the CPL spec is H.323 work.  I'm
unfortunately not very knowlegeable about this, so if some H.323 experts
could assist with this it would be very helpful.

Here are the general issues that I feel need to be addressed:

1.  I understand that work is in progress to define an H.323 url as an annex
of the H.323 specification.  What is the status of this?  Are copies of
available?  Will these URLs be appropriate to use in CPL <location> and
<address-switch> tags?

2.  Is the unpacking of H.323 addresses as specified for CPL's
<address-switch> address subfield matching correct, and complete for at
least a useful subset of H.323 addresses?

3.  What free-form strings does H.323 signalling carry that a CPL should be
able to match?  I understand H.225 has a "data" string, but it's not clear
to me what it's for.

4.  Is there some H.323 counterpart to SIP caller preferences and callee
capabilities that should either be used or mapped into CPL, for <lookup> and
<remove-location>?

Since Our Esteemed Working Group Chair has expressed a strong interest in
moving CPL along to Proposed Standard soon, these points *need* to be
addressed.  If no one else comments on them, I'll have to guess based on my
own (very limited) understanding of H.323, which will probably mean a much
weaker CPL specification all around.

-- 
Jonathan Lennox
[email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Jul 2000 07:01:30 -0700

Hi,

I guess the question is, do SIP user agents and proxies executing CPL 
scripts really care about the timezone *name*?

If each proxy or user agent simply knows their own current UTC-offset, is 
this good enough?

thanks,
-rohan

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 9 Jul 2000 07:09:52 -0400

Jonathan,

> available?  Will these URLs be appropriate to use in CPL <location> and

Currently, the URL is specified in the body of the H.323v4 document (section
7.1.4), which is currently in draft form.  You can get a copy here:
http://www.packetizer.com/iptel/h323/drafts/h323v4-white.zip

I believe everyone is pretty much in agreement on the syntax of the URL,
though there may be a few minor changes before decision in November.  I
expect such changes to be truly technical errors or minor editorial errors.

The URLs are certainly suitable in the <location> and <address-switch> tags.
As you'll see, the H323 URL is very similar in form to the SIP URL.

> least a useful subset of H.323 addresses?

In section 4.1.2 of the CPL draft, you reference the "e164" as the field
name containing a telephone number.  In H.323 version 4, that field name is
changing to "dialedDigits", so I would recommend changing the name in the
CPL document if possible.  However, the telephone number for the caller and
called party may be found in the Q.931 information elements
"callingPartyNumber" and "calledPartyNumber", respectively.  When trying to
match a telephone number, both the "dialedDigits" alias type should be
checked, as well as these Q.931 information elements.

For the "user" tag, it is currently specified to be set to h323-ID.
However, since H.323 has an email-ID alias, I would recommend that for
H.323, the "user" tag be set to the user part of the e-mail address
specified in the email-ID field.  It is unfortunate, but h323-ID is fairly
opaque and may not relate to a "user" at all.

For "host", I would recommend allowing what you have currently + adding the
text "or the host element of the H.323 URI".  Also, allow the port be
specified similarly-- this would be in line with the same description you
have for the SIP URI and will take advantage of similar syntax in the H.323
URL.

Currently, the display subfield is not specified to be used for H.323,
however there is a "display" information element in the H.225.0 Setup
message.  It is found in the Q.931 portion of the message, not in the ASN.1
that is defined.  I would suggest allowing that display information element
to be used here.

You allow the specification of other types as "textually encoded ASN.1" by
using the keyword "asn1".  Many protocols use ASN.1 and there may be a name
collision at some point in the future with a new protocol definition.  This
type definitely needed to allow one to handle address types such as
PartyNumber, etc.  I would recommend changing the name from "asn1" to
"H.225.0 AliasAddress" (long, eh?) or "h323-alias".  The description could
then be:
``a H.225.0 AliasAddress structure encoded using Packed Encoding Rules (PER)
and then encoded in UTF-8''

This sounds a bit awkward as I read it, but it's important to indicate that
the AliasAddress structure is first encoded using encoding rules defined for
ASN.1 (which is PER for H.323).  Encoding that binary data as UTF-8 simply
solidifies *exactly* how the textual representation shall appear.  Feel free
to pick your favorite, though :-)

There is also a statement in H.323 that states "both destination and
original-destination correspond to the destinationAddress field, as H.323
has no indication of original destination."  There is one exception to this
rule.  If a call is placed from the PSTN to an H.323 device through a
Gateway (or vice versa) and then the call is redirected to another H.323
device (because the user had "call forward" enabled, etc.), the call may
arrive with the "Redirected Number" information element, indicating the
address of the original destination (this field is most likely present only
when calling PSTN -> H.323).  So, for H.323, I would allow the usage of the
Redirected Number information element here.

> able to match?  I understand H.225 has a "data" string, but it's not clear

In addition to field values "origin", "destination", etc., it might be good
to add "language".  H.323 allows a caller to specify his preferred languages
as defined in RFC 1766.  This might be useful for call centers that handle
calls internationally.

I can't really think of anything else that might be interesting to key off
of.  Certainly, there are other fields that are useful for dynamic call
routing, but nothing I think it appropriate for CPL.  For example, the
conference identifier (CID) is something that an entity may want to key off
of for routing calls, but since those are very dynamic, I don't think it's
suitable for CPL.

> capabilities that should either be used or mapped into CPL, for <lookup>
and

H.323 cannot specify a list for <remove-location>, but the CPL-capable
Gatekeeper or other entity that holds the user's CPL script could still
process this list against either the source or destination address of an
H.323 call.  However, I'm actually puzzled why this needs to be present for
SIP since SIP can specify this when it places a call.  I suppose it's there
so that a SIP UA would not have to transmit this list on each call.  In any
event, I think that this tool could be used by both SIP and H.323 entities.

To be honest, the <lookup> description confuses me.  I may need to see an
example to be able to draw some parallels.  However, if I understand this at
all, this might be the proper place for the "language" preference that H.323
can indicate.  H.323 also has the ability to indicate that a called should
supports certain protocols, such as T.120 or T.38 fax.  H.323v4 also adds a
new generic feature negotiation mechanism, but the feature negotiation is
fairly abstract.  Currently, there are no features defined that use to
mechanism, but the framework was placed in V4 so that we can specify such
features in the future without having to make revisions to the base H.323
document.  Trying to map this to CPL will be a challenge, to say the least.
However, I would invite you to read the section in H.323 on the "generic
extensibility framework".  It's not real helpful without also seeing the
ASN.1 for it.  I placed a draft version of that ASN.1 here:
http://www.packetizer.com/iptel/h323/drafts/generic_data.txt

For brevity, I just put in the fields that are most applicable here.  You'll
see that there is a field in the root of the H.323 messages called
"genericData" which is intended to carry some type of opaque data.  In the
Setup message, there are these fields:
  neededFeatures
  desiredFeatures
  supportedFeatures

Certainly, it would be nice if these features could somehow be conveyed by
the CPL-capable routing entity, rather than the endpoint. However, about the
only way I can see to do this cleanly (so that the user or entity creating
the script does not have to encode a bunch of ASN.1 PER data) is to extend
the XML DTD to include these ASN.1 structures.  That would definitely be the
cleaner approach, but I suppose providing a means of allowing the encoding
of the GenericData structure would be better than nothing at all.

> weaker CPL specification all around.

I'd be more than happy to work with you to help resolve some of the issues.
I think there's a lot of value in CPL, so feel free to send me questions on
H.323.

Best Regards,
Paul E. Jones
Editor, Recommendation H.323
http://www.packetizer.com/people/paulej

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jul 2000 12:48:24 -0400

"Paul E. Jones" wrote:

> as defined in RFC 1766.  This might be useful for call centers that handle

This might be more appropriate for the string-switch node, where this
would also be appropriate for the Accept-Language parameter in SIP.
Thus, it might be worth adding this to the list of field names.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Jul 2000 14:25:42 -0400 (EDT)

> If each proxy or user agent simply knows their own current UTC-offset, is 

They don't care about timezone names.  They do, however, care about a
timezone's daylight-savings transition rules, because a script to do
something between 9 am and 5 pm shouldn't suddenly become a script to do
something between 8 am and 4 pm in late autumn.

Unfortunately, there are hundreds of different DST transition rules around
the world, and politicians muck with them on a regular basis.  This is the
problem we're trying to solve here, or alternately defer to someone else.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Jul 2000 17:54:27 -0400 (EDT)

> Thus, it might be worth adding this to the list of field names.

I agree this is useful, but it's not clear to me that string-switch is the
right way to handle this.  The semantics we really want is "is this language
included among the languages the caller wanted."  A custom switch type could
do it, but I'm not crazy about adding another one.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Jul 2000 00:29:13 -0400

> event, I think that this tool could be used by both SIP and H.323 entities.

No, the idea is that the *called UA* can specify that they do not wish
to be reached at certain locations. Thus, the information cannot be
carried in an INVITE, since an INVITE represents the *callers*
preferences.

> the CPL-capable routing entity, rather than the endpoint. 

This doesn't make sense. The CPL-capable routing entity is the
gatekeeper. What does it mean for it to "convey" that information? To
whom? Why?

> However, about the

If you put some kind of ASN.1 stuff into the DTD, then the user creating
the script
does need to know about it, so I don't follow what you are proposing.

-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: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jul 2000 18:21:16 -0400

> do it, but I'm not crazy about adding another one.

"contains" is already a suitable matching operator that should work for
most "speaks X" tests. Can't handle things like "if the first preference
language is Spanish, go there", if that's what you're after, though.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 11 Jul 2000 01:38:54 -0400

Jonathan,

> carried in an INVITE, since an INVITE represents the *callers*

Ah, yes.  That makes much more sense :-)

> gatekeeper. What does it mean for it to "convey" that information? To

I was up all night that night, so I'm surprised that my response was
coherent at all.

As noted above, I was narrowly thinking that this applied only to the
calling entity.  My thinking was that the CPL entity that processed the
incoming Setup/INVITE would supplement the feature information found in that
message with additional feature information.  For example, with H.323 it is
possible for the H.323 Gatekeeper to provide services on behalf of the
endpoint.  This allows the endpoint to have a simpler design that is less
expensive to design, build, and maintain.  The "thin" endpoint may indicate
only a very limited (or zero) features.  However, the Gatekeeper supplement
the lack of features by providing actually providing those features on
behalf of the endpoint.  As the call is processed, the CPL script processing
could result in the addition of features advertised in the outgoing Setup
message.

> does need to know about it, so I don't follow what you are proposing.

One of the ideas behind CPL is that the user can specify how messages are
processed using some GUI tool that is simple to use.  Ideally, such a tool
does not have to be too tightly coupled to either SIP or H.323.  It would be
ideal if we could express constructs more generically and without requiring
the use of ASN.1.  ASN.1 PER is quite appropriate for messages on the wire,
but I do not see a good reason to use ASN.1 PER within something like CPL.
We had the one case of the "AliasAddress" and I'm not even fond of that.
However, to get around it we would have to represent the binary data in
another form.  That's doable, but perhaps not worth the effort since CPL
supports the most basic call routing alias types without ASN.1 PER:
dialedDigits, url-ID, and email-ID.

In order for CPL servers to perform some type of action based on a "desired"
or "needed" feature indicated in an Setup message, for example, we need some
way of representing the Generic Data in H.225.0 within CPL.  I don't think
that ASN.1 PER is the right choice.  It will work, but it requires the tool
to generate such encoded data.  It might be preferabe to abstract this in
some manner, perhaps by extending the CPL DTD to include those constructs or
some other means that does not involve encoding ASN.1 message and storing
that raw data within the script.  A definite plus to having XML is that the
CPL script could make decisions on particular elements of the Generic Data
structure.

Best Regards,
Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 13 Jul 2000 18:55:26 -0400 (EDT)

Thank you for the H.323 information and references; it's been very helpful.
I have a few questions, however:

> http://www.packetizer.com/iptel/h323/drafts/h323v4-white.zip

It seems, from my reading of the H.225.0v4 draft, that the H.323 URL is only
one choice among several for H.323 aliasAddresses.  It can only represent
the url-ID choice of that field, not the dialedDigits, h323-ID, url-ID,
transportID, emailID, partyNumber, or mobileUIM choices.  Is this correct?
If so, do we need any way to put these types of addresses into the location
set, or will H.323 urls be sufficient?

> However, the telephone number for the caller and

I assume the aliasAddress gets priority if both are specified?

> opaque and may not relate to a "user" at all.

Reading section 7.1.3 of H.323v4, I see: 

        The H.323 ID consists of a string of ISO/IEC 10646-1 characters as
        defined in Recommendation H.225.0. It may be a user name, conference
        name, e-mail name, or other identifier.

This seems like it corresponds quite closely to the SIP display-name (a
human-readable name corresponding to the address), which would be the
"display" subfield of the address match.  Is there any reason this shouldn't
be used for that purpose?

> have for the SIP URI and will take advantage of similar syntax in the H.323

Okay.

> that is defined.  I would suggest allowing that display information element

Since this is a message-level information element, not an address-level one,
I think this would be better placed in the string-switch.  What information
is normally placed here?  Caller-ID information, meta-information about the
purpose of the call, or what?  How is it encoded?

> and then encoded in UTF-8''

On reflection, I think that this was a bad idea entirely; putting PER data
into the CPL is very counter to the spirit of the thing.  Since I think all
the important parts of an aliasAddress can be mapped sucessfully into one
subfield or another of the address match, I'll drop the encoded form.

> Redirected Number information element here.

I can't find any reference to this in either H.323v4 or H.225.0v4.  Is it a
Q.931 element?

Thanks.

-- 
Jonathan Lennox
[email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Jul 2000 01:49:08 -0400

Jonathan,

> set, or will H.323 urls be sufficient?

This is correct.  The H323 URL is one type of URL that may be used.  Of
course, there is nothing to prevent the use of other URLs, such as http,
etc., for the purposes of directing an H.323 entitiy to a web page, etc.

Also, you are correct that the H.323 URL is not a replacement for or another
means of expressing other alias types.  What you had proposed before was to
use "asn1" for the location set.  See below.

> I assume the aliasAddress gets priority if both are specified?

Typically, the Q.931 IE gets priority.  However, I suppose it depends on the
application.  H.225.0 says that the Called Party Number IE shall contain the
called number if it a single E.164 address.  However, that does not preclude
the endpoint from also including it in both places.  It does suggest,
though, that the Called Party Number IE has a higher precendence in that one
case-- because it is legal to have a Called Party Number IE without a
destinationAddress field.  What I think an application should do is first
check the Called Party Number IE and, if not present, process the
destinationAddress field-- but that's strictly my opinion.

> be used for that purpose?

I suppose it makes sense to allow it to be used here, but I would also allow
the user part of the URL and e-mail address aliases, too.

> purpose of the call, or what?  How is it encoded?

The Display IE is intended for the purpose of presenting a user's identity.
Q.931 defines this field as:
``The purpose of the Display information element is to supply display
information that may be displayed by the user.''

It is simply an ASCII string that might contain "Paul E. Jones" or something
similar.

> subfield or another of the address match, I'll drop the encoded form.

I agree that best solution would be to not use ASN.1 PER and to allow the
CPL scripting tool to generate scripts that contained identifiers from the
other H.323 alias types.  However, you already address the important ones:
dialedDigits, email-ID, and h323-ID (I believe).  The others alias types are
less common and, unless things change, will probably remain mostly
underutilized.  However, alias types such as PartyNumbers are really useful
and if tools like CPL supported them, perhaps it might even encourage wider
usage.

The biggest problem, of course, is representing the other H.323 aliases in
CPL without having to copy every element within those alias structures into
the CPL document.  This might be an exercise to see just how "extensible"
XML is.  Is it possible to define a base DTD and then create "child" DTDs
that inherit defintions from the parent?  If so, it might be useful to allow
CPL to contain some base functionality and then allow H.323 and other
protocol-specific attributes to be added as extensions.

> I can't find any reference to this in either H.323v4 or H.225.0v4.  Is it
a

Yes, this is defined in Q.931.  We specifically mention it in H.225.0v4
section 7.2.2.24 and is included in the Setup message.

Paul