Remember that not all phones are "normal phones", and that not all sip
devices are phones at all. For some, generating a full URL, and
displaying one, may be quite natural. So you should not be surprised, or
function poorly, if you get a call from such a device, or call one.
I wrote a spec for configuring "digit map" capability for phones, as
part of a spec for a large class of providers. It had full capability to
turn dial strings into E.164 numbers, either as TEL: or SIP:. It also
had the capability to turn them into most any other form that a provider
might provide. I left the project before it was deployed, so I am not
certain if it was adopted as I wrote it or not. But there is at least a
good chance that there will be a bunch of phones with this capability.
The cruel fact is that phones are built to support what the bulk buyers
of those phones want. So the best way to get the support in the phones
is to get the bulk buyers to want it. This *will* evolve over time. In
the meantime any limitations of the phones need to be fixed up by some
device along the path that is in a position to understand the
configuration of the phone and the policies that apply to the user of
the phone.
Paul
Iñaki Baz Castillo wrote:
> 2008/7/7 Paul Kyzivat <[EMAIL PROTECTED]>:
>> See RFC 4967 re user=dialstring.
>>
>> dial strings are different from phone numbers. the point of that rfc is to
>> make it clear which is being conveyed.
>
> Thanks a lot, I didn't know that RFC.
>
>
>>> * If the user calls to 944990011 (spanish number with no +34), which
>>> RURI should generate the UA?
>>> * Is there any SIP device in the world with the behaviour of the first
>>> two questions?
>> We are really talking two different things. I am promoting how I think
>> things *ought* to work - a behavior that would make the ultimate user
>> experience better. I am first to admit that you aren't going to find a lot
>> of phones out there that are capable of doing it. (But I think there are
>> some phones that hare highly configurable, and might be able to do it.)
>>
>> The limitations of what phones currently do leads to a need for B2BUAs to
>> fix it up. If you are building a "pbx" as a B2BUA then you are already in
>> the middle of making such fixups.
>>
>> In the real world, where such B2BUAs already exist, then I would expect them
>> to make up for the limitations of the phones. But where the pbxs meet each
>> other as peers, it again makes sense to exchange numbers in E.164 form. In
>> this kind of scenario, you will have to use configuration of the PBX to know
>> what to expect from the phones, and what sorts of transformations are needed
>> to get into E.164 form.
>
> Well, you are right. But sometimes I wonder if it's not too late to
> "redefine" SIP and phones behaviour. Adding so many extensions make
> that only private enviroments work properly instead of help in
> interoperability (IMHO).
>
>
>>> PD: Also note that basically it's impossible to determine if a number
>>> is a PSTN number or a local extension.. For example in Spain there are
>>> various kind of short numbers (1XXX, 0XX, 1XX...).
>> This is precisely why it is important to get these things converted to
>> globally unique form as soon as possible - while still in a place that knows
>> the context of the caller.
>>
>> As soon as you let such a number slip beyond the originating context it
>> becomes completely ambiguous. (1xxx means something to my phone too, but not
>> the same as it means to you or your phone.)
>
> Ok, it makes sense. Maybe forcing the users to also type the
> international prefix? (of course since normal phones have no "+" key
> they should type "00"). Any other way?
>
> Thanks a lot for your comments.
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
