Iñaki Baz Castillo wrote:
> Hi, I understand that the use of "tel" URI could be cool when the
> INVITE is received by a PSTN gateway (so an URI domain makes no sense
> at all) but I wonder who should create this tel URI.
>
> For example, I consider very very difficult that a phone could handle
> "tel" URI's since it cannot know when the call is for a PSTN number, a
> private extension or an outbound call to other SIP domain, so IMHO a
> final UA should always use SIP/SIPS URI's and not "tel".
> But when the UA sends an INVITE to its proxy like:
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
> the proxy can detect that it's a PSTN number and convert it to "tel"
> URI before forward it to a PSTN gateway:
> INVITE tel:0034999000111 SIP/2.0
In the above, how did the phone get the URI in the first place?
Did it *derive* it from a string of dialed digits?
If so, how does it know what domain to use? Certainly that might not be
the actual domain serving the number. If all it knows is "this is a
phone number", then the tel URI is actually a more accurate
representation of the facts. As long as there will be an outbound proxy
to figure out what to do with it, that should be fine.
However that does assume that the phone knows how to convert the dial
string into an E.164 number. Some phones may not know that, and may
depend on the outbound proxy to understand that. If so, an E.164 number
isn't appropriate. In that case something like:
sip:[EMAIL PROTECTED];;user=dialstring
would be more appropriate. It is then an expectation that some server
for caller-domain.com will translate this to an appropriate globally
unique form. This could be an E.164 form, or any sort of sip URI.
> Is it correct? Note that I'm trying to imagine a real and feasible
> bahaviour. Please, don't suggest me that the phone could handle "tel"
> URI's since it's just an impossible dream, isn't?
The example above is outbound. Is that what you are concerned with? Or
inbound?
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
