I think there are a bunch of implementation issues here, which are
outside the scope of what ietf deals with, but which are important.
Pretty much having to do with what is rendered is out of scope for ietf.
All we can do is identify information which is carried in the protocol
and which is *available* to be rendered.
Unfortunately, we have an embarrassing surplus of identifying
information, most of which is of questionable reliablility. And the
devices typically have a limited ability to display this. Even if they
*could* display it all, that would simply confuse most users.
On most phones in the US, one calling number and one calling name can be
displayed. I'm not certain of the exact maximum length that can be
handled by each. I think the number is sufficient for most typical e164
numbers in use, and I think it can handle the leading plus and some
other punctuation. (Maybe you can put arbitrary text in there.)
IMO there is an *expectation* that these values are reliable, and not
something that the caller is free to manipulate arbitrarily, they way
email From addresses are. I think we all know that expectation is
violated on a regular basis, but still the expectation is there, perhaps
based on past history where it was harder to forge.
If a "phone number" arrived as the "calling name" I would expect that
the phone would display it as such. Then the callee would see two
"numbers" and would try to make some sense of it. Whether that is a good
thing or not is open to discussion.
The problem that is most easily dealt with, that doesn't require any
added standardization, is "user friendly" display of numbers. IMO
attempts by the *caller* to make the calling *number* more user friendly
(by omitting presumably undesired parts of the number) are misguided.
Such attempts assume that the caller can anticipate how the recipient
would like to see the number, and that all possible recipients of a
particular call will prefer to see it the same way.
Instead, I think the caller should be providing the calling number as an
E.164 number, when it is in fact possible to represent it that way. This
will make it universally unambiguous, and meaningful the the maximum
number of possible receiving devices. The receiving device should then
take responsibility for rendering this the receiving user in a way that
is maximally useful and friendly for the receiving user.
The skill with which the receiving device does this can be an area of
competition between devices. The simplest way would be to directly
render the E.164 number, including the leading +. There are a class of
users (including a lot of people active in the IETF) that might prefer
this approach. But that is probably not the preferred rendering for
"grandma". A better default would, IMO, be a dial string that would
reach the E.164 number. If there are multiple dial strings that would
achieve that result, then perhaps the shortest one is preferred.
I have said "receiving *device*" here. But it could just be "receiving
*agent*" - one that represents the receiving user. E.g. a "pbx". So such
rendering decisions don't necessarily require smart phones.
The E.164 numbers above could be carried either in TEL URIs or in SIP
URIs. That is a different discussion - that should be kept distinct.
Thanks,
Paul
Johansson Olle E wrote:
> 6 jul 2008 kl. 16.09 skrev Iñaki Baz Castillo:
>
>> Also, I've tested sending INVITE to some softswitches with a From or
>> PAI like this:
>> "999000111" <sip:[EMAIL PROTECTED]>
>> And when those softswitches convert the call to PSTN the CallerID
>> number is 999000222, never 999000111.
>
> I can't say much about your softswitch, but in Asterisk we clearly
> have separate data field for both Caller ID name, which we use as
> display name
> in SIP, and caller ID number (which is alphanumeric). If the softswitch
> uses ISDN on the other side, it could in theory handle both caller ID
> number
> and name. But it depends on the implementation, as always. European
> equipment are not very used to caller ID names.
>
> My comment just indicated that I think the proposed solution was a good
> way forward, as I've spent hours of work with the same issues as you do,
> moving away and adding +46 or other country codes.
>
> The way forward depends on the implementors. You and I can work on
> OpenSER and Asterisk. :-)
>
> /O
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
