RFC3966 gives some use-case of tel URI. 9. Use of "tel" URIs with SIP (Informative)
SIP can use the "tel" URI anywhere a URI is allowed, for example as a Request-URI, along with "sip" and "sips" URIs. For brevity, we will imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP URIs can contain telephone numbers. In SIP URIs, they appear as the user part, i.e., before the @ symbol (section 19.1.6 in [RFC3261]). Unless a SIP UA connects directly to a PSTN gateway, one of the SIP proxy servers has to translate the "tel" URI to a SIP URI, with the host part of that URI pointing to a gateway. Typically, the outbound proxy server, as the first proxy server visited by a call request, performs this translation. A proxy server can translate all "tel" URIs to the same SIP host name or select a different gateway for different "tel" prefixes, based, for example, on information learned from TRIP [RFC3219]. However, a proxy server could also delegate this translation task to any other proxy server, as proxy servers are free to apply whatever routing logic they desire. For local numbers, the proxy MUST NOT translate "tel" URIs whose contexts it does not understand. [Rockson] this paragraph is most enlightening to me. I think it shows several points, 1) UA can use tel URI directly. 2) PSTN GW can understand tel URI, i.e, a SIP UA connects directly to a PSTN gateway 3) One of SIP proxy need to translate the "tel" URI to a SIP URI, I do not see the necessity for FROM/TO header, I think only Req-uri or top route, which has impact to SIP routing defined in RFC3261, need apply this rule. As noted earlier, all phone numbers MUST use the global form unless they cannot be represented as such. If the local-number format is used, it MUST be qualified by the 'phone-context' parameter. Effectively, the combination of local number and phone context makes the "tel" URI globally unique. [Rockson] Local number is strongly discouraged. Also as Paul says, there need a mechanism for dialstring to tel uri translation. This can be done either in UA or proxy. My 2 cents. -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Monday, July 07, 2008 12:10 PM To: Iñaki Baz Castillo Cc: [email protected] Subject: Re: [Sip-implementors] Using "tel" URI in P-Asserted-Identity with ; phone-context parameter Iñaki Baz Castillo wrote: > 2008/7/6 Paul Kyzivat <[EMAIL PROTECTED]>: > >> 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. > > Hi, my first aim was this and this is what I did in outgoing calls to > PSTN (I set P-Asserted-Identity as E164 complete number). But > unfortunatelly it seems that common mobil phones and fixed phones > render the entire number even if it's national/local, and people don't > like it, the prefer to see 944990011 than +34944990011. :( > > Thanks a lot for your comment. In the current world there has not been sufficient standardization. Or perhaps I should say there hasn't been sufficient implementation of the standards we have. Or maybe it is simply that the carriers have failed to enable the implementations of the existing standards that are already present in the equipment they have. In any case, it is sad but true that when connecting to carriers you may have to fix up the numbers to the form they can deal with. Or, if you were a big enough fish, then they might do the fixing up of the numbers you provide to the form they want. There are really only two ways to do this: - each domain has its own way of representing numbers. whenever it connects to another domain it has to know the (likely different) way that the other domain represents numbers, and convert to that. - each domain uses a common representation of numbers (E.164) when talking to others. Whatever it uses internally, it always converts to this standard form for talking to others. The former seems to be the norm, and it sucks. But it is consistent with the carrier world view that peering relationships are all privately negotiated on a 1:1 basis, and are a "big deal". It means that only a small number of peers are feasible. The latter makes it much more feasible to have open peering relationships. Maybe that is why it isn't widely supported. Within your domain, you can fix up however you wish. If there was wide agreement on use of E.164, then it would be worthwhile for phones to support it too. Then PBXs could be replaced with simply proxies. It is not *hard* for the phone to convert to E.164 format. For any one locale the configuration of the dial plan to do so is relatively trivial, and not taxing on the phone to do. There just hasn't been any motivation to do it. Thanks, Paul _______________________________________________ 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
