Glenn Parsons (gparsons@nortelnetworks.com)
Thu, 21 Jun 2001 11:39:40 -0400
Greg,
Thanks for reading this so quickly!
The original intent (that is still valid I believe) was to provide an RFC822
header field to store the calling number/name for a call answer voice
message without 'forcing' it into the 'To:' field. This could then be
displayed by the UM client. The goal was to keep it simple, so the
restriction of only storing what you'd get on the end of an analog line
makes sense. Further, the intent is that the user would be able to see
these header lines (from their UM desktop) so storing network information
(like the caller's number and the fact that it is to be blocked) does not
make sense. I would suggest that we would want additional headers or some
other mechanism to store this info...
As for the charset, this is a sticky issue. The network charset depends on
whether you are using ISDN, TCAP, etc. But the defined charset to the
analog line is ASCII. I think this is most appropriate.
As for truncated numbers to 10-digits -- c'est la vie on this side of the
pond. We can better explain the situation if you like, though vendor
specific details would take some digging. But the fact is that the NA
standard to send the digits to an analog line was originally for only 10
digits. Of course the current edition of the standard indicates that longer
numbers may be sent, but there's a lot of 10-digit equipment in NA... I
doubt if this is an issue anywhere else...
As for the field syntax, it was defined minimally previously -- but the
overwhelming opinion when it was reviewed by the VPIM WG was to make it
unstructured . I suppose we could push back and add some additional
structure to it (e.g., revert back to structured and use parameters to
indicate what is known about the number), but I would like to maintain the
simple baseline as it is now as the default.
For example, the original authors had been toying with:
Caller-ID: 6137684087 - the
default for analog line delivery
Caller-ID: 6137684087; type=NANP - tagged values if
you know the type from ISUP, etc.
Caller-ID: 16137684087; type=E164
Caller-ID: 84087; type=private
But this is the start of a slippery slope towards defining syntax for all
the complexity of the messages defined in T1.625 et al...
Cheers,
Glenn.
> ----------
> From: Vaudreuil, Greg M (Greg)
> Sent: Thursday, June 21, 2001 10:31 am
> To: Parsons, Glenn [NORSE:6L81:EXCH]; Maruszak, Janusz [TOR:9T73:EXCH]
> Cc: 'IETF VPIM List'
> Subject: Calling ID Draft Comments
>
> 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 - 18:40:45 IDT