Iñaki,

Of course if you have a provider that works a certain way, then at least 
in the short term you just do what you must to get the results you want. 
But that's pragmatics, not standards.

If we can make the right standards, and there is compelling value in 
them, then hopefully they will eventually be used.

This screwing around with the way numbers are represented is one of the 
reasons there are SBCs at every boundary - to change from one set of 
arbitrary conventions to another.

Re phone number in the display name: certainly there is no guarantee if 
or how it will be displayed. I suppose it would typically be displayed 
as the "calling name" rather than calling number. Not bad if you had 
nothing else to put there. But not so good if you also want to include 
the name.

        Paul

Iñaki Baz Castillo wrote:
> El Wednesday 02 July 2008 14:51:08 Paul Kyzivat escribió:
> 
>>> If the call is national (Spain = +34) I don't add the international
>>> prefix (it's ugly to see it in national calls):
>>>
>>>   P-Asserted-Identity: <sip:[EMAIL PROTECTED]>
>>>
>>> And if the call is international then I add the +34 prefix:
>>>
>>>   P-Asserted-Identity: <sip:[EMAIL PROTECTED]>
>> Note that these are *not* syntactically phone numbers at all. They are
>> just names that happen to contain digits. If it works for you then I
>> guess its ok, but if you attempt to interoperate with somebody else all
>> bets are off.
> 
> Yes, I know that. That's why I want to use "tel".
> 
> 
>> Regarding the E164 syntax being ugly - isn't the @domain.com ugly too?
>> I presume you don't think so because it isn't being displayed. There is
>> no law that says the number part has to be displayed as received either.
> 
> In my case I deliver calls to PSTN via a carrier. This carrier has a 
> softswitch supporting PAI. I can't know *what* the carrier do with the PAI 
> uri and how it passes it to SS7 network, but by experience I've realized of 
> this behaviour when calling to a Spanish number (+34):
> 
> P-Asserted-Identity: <sip:[EMAIL PROTECTED]>
> => the called PSTN phone will see 999000111.
> 
> P-Asserted-Identity: <sip:[EMAIL PROTECTED]>
> => the called PSTN phone will see +34999000111 (ugly and not neccesary).
> 
> P-Asserted-Identity: <tel:999000111>
> => the called PSTN phone will see 999000111.
> 
> P-Asserted-Identity: <tel:+34999000111>
> => the called PSTN phone will see +34999000111 (ugly and not neccesary).
> 
> P-Asserted-Identity: "999000111" <tel:+34999000111>
> => the called PSTN phone will see +34999000111 (Display Name is not rendered 
> at all).
> 
> So even if <tel:999000111> is not correct it is the working solution in my 
> case.
> 
> 
> 
>> If the E164 number begins with +34 and the phone displaying it serves
>> the +34 area, then it could display the number without the +34. This is 
>> much more robust.
> 
> But when I deliver the call to PSTN I cannot control how the final PSTN 
> provider will handle the number.
> 
> 
> 
>>> It works ok but I prefer to use "tel" URI.
>> Good! For a long time I've been on a (so far unsuccessful) campaign to
>> get TEL used for phone numbers. One key advantage is that there is no
>> question that it is a phone number. Another is that sip URIs containing
>> phone numbers are embroiled in the ongoing controversy about whether the
>> domain name matters, and if it is authoritative for the number.
> 
> Agree :)
> 
> 
> 
>> If you read 3966 closely you will see that
>>        tel:999000111;phone-context=+34
>>    and tel:+34999000111
>>
>> are *not* equivalent. And in fact the local format is not to be used for
>> addresses that have a global format. It is only intended to be used for
>> those that don't - e.g. private extensions without DID. So it makes
>> sense that the callerID is not as you hoped.
> 
> True, thanks.
> 
> 
>> So again, IMO you should use the E164 format, and the recipient should
>> make the display nice.
> 
> But I can't contorl the recipient. It's the whole PSTN network.
> 
> 
>> If that doesn't work, I have also seen:
>>
>>      P-Asserted-Identity: "990-00111" <tel:+34999000111>
> 
> As I said before it doesn't work in my case. But, should it work???
> I've never read that the DisplayName should be rendered as CallerID number.
> 
> 
> Thanks for all. Regards.
> 
> 
> 
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to