inline...
Iñaki Baz Castillo wrote:
> 2008/7/6 Paul Kyzivat <[EMAIL PROTECTED]>:
>
>> In the above, how did the phone get the URI in the first place?
>> Did it *derive* it from a string of dialed digits?
>
> A person can type 201 or 944990011 in its phone, being 201 a local
> extension and 944990011 a national Spanish extension. I see no
> difference.
>
>
>> If so, how does it know what domain to use?
>
> AFAIK *any** SIP UA assumes the proxy it's configured to as the
> default SIP domain. If a UA is configured with:
> - user: bob
> - domain: sipdomain.com
> I expect that, by default, calls will be sent to "sipdomain.com"
> except if a different domain is also typed by the user.
>
> IMHO any other apporach makes all complex and unfeasible, I'm
> describing the way all the phones I know work.
>
>
>
>> 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.
>
> But what about when the user typed "201" to call a local extension?
>
>
>
>> 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.
>
> Sorry but I don't understand what you mean here, also I really don't
> know if your suggestion would do the SIP life easier or more complex
> than already is. I just can't imagine a server that receives a non
> official parameter "user=dialstring" in order to route properly a call
> to PSTN, and of course I just can't imagine existing real SIP devices
> adding that parameter to the RURI.
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.
> So I just do 3 questions:
>
> If a SIP phone is configured with data:
> - user: 200
> - domain: sipdomain.com
>
> * If the user calls to 201, which RURI should generate the UA?
You have given far too little information to say.
And you are well beyond what is standardized.
> * 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.
> Thanks a lot.
>
>
>>> 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?
>
> I speak about outbound.
>
>
> 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.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
