Greg (gregv@lucent.com)
Thu, 21 Jun 2001 08:31:01 -0600
Thanks for the updated draft. I have a number of comments.
First, this is a very restricted draft limited to enterprise or residential
integrations. Such service provider features as reply by phone call to
blocked caller-ID can't be supported using this standard. While a solution
to this problem is a bit more "interesting", I would like to see us explore
some options. Also we dismiss the other signaling information that may be
of great use in unified communications applications including called number
and originally called number... Is the idea we can add these in the future
as additional header lines?
I would like to see an explicit value for a caller-ID blocked message. It
is useful to distinguish between unavailable and blocked in presenting this
information to the end-user.
I would prefer the character set for calling name be explicitly defined as
ISO 8859-1. It appears from the description in the draft that all
calling-name standards are proper subsets of that character set. This
avoids use of the encoded word for character sets beyond ASCII-like or IA5
sets.
Truncated caller-ID is a real problem that I would like to see better
addressed. Is the truncation a specific problem of a specific PBX? In my
service, International caller-ID is either fully available or not available.
The truncated to ten digits is dangerous and there is seemingly no way to
automatically detect that failure mode.
My preference is to define the caller-ID field to be explicitly labeled as
E-164. Internal extension numbers aren't "caller-ID" and in many cases will
present numbers that can't be represented in E.164. I suggest private dial
plan stuff be a private matter.... Maybe using an explicitly defined
extension value in the syntax.
Greg V.
This archive was generated by hypermail 2.0b3 on Thu Jun 21 2001 - 17:31:14 IDT