Dwight, Timothy M (Tim) wrote:
> Paul,
>
>>> Are you saying that use of tel:+4085551212 as opposed to
>>> sip:+4085551212;user=phone makes it more likely that the call will
> be
>>> routed to the PSTN? If so, why would that be?
>> IMO if I give you sip:[EMAIL PROTECTED], with or without user=phone,
>> then a call back to that URI MUST be via sip, and the 3263 rules say
>> that it MUST be routed to domain sp.com before making any
>> decision about how to reach something associated with the user part.
>
> OK, I'm fine with that.
>
>
>> If I give you tel:+4085551212, then you have total freedom regarding
>> what protocol to use to reach me, and the path taken. You may just use
>
>> an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip
>> service, or whatever.
>
> I see your point. In the networks with which I am familiar there is not
> such cleverness, though. They only know SIP and PSTN, and only use PSTN
> as a fallback. So in my limited world, the type of URI (sip vs. tel)
> does not impact the liklihood that the call will be transported via SIP.
>
>
>>>> If the devices are half way smart, even if they only show the
> number
>>>> they will keep the entire URI in their call log, so that if I
> attempt a
>>>> callback via the call log it will use the whole URI. But I expect
> some
>>>> devices will be dumber than that.
>>> When you say "use the whole URI" do you mean in the R-URI?
>> I was thinking of a device that keeps a log of *incoming*
>> calls, so the From-URI would be appropriate.
>
> Yes, I understand that. I was asking if you meant that the device would
> put the value it extracted from the From-URI into the Request-URI of the
> callback. As opposed for example to putting it in the To-URI and maybe
> constructing a R-URI with the same user part ("dialed digits") but a
> different host part (identifying the network serving the calling party).
> I guess such a thing would be legal.
Section 8.1.1.1 of 3261 applies here:
The initial Request-URI of the message SHOULD be set to the value of
the URI in the To field. One notable exception is the REGISTER
method; behavior for setting the Request-URI of REGISTER is given in
Section 10. It may also be undesirable for privacy reasons or
convenience to set these fields to the same value (especially if the
originating UA expects that the Request-URI will be changed during
transit).
In some special circumstances, the presence of a pre-existing route
set can affect the Request-URI of the message. A pre-existing route
set is an ordered set of URIs that identify a chain of servers, to
which a UAC will send outgoing requests that are outside of a dialog.
Commonly, they are configured on the UA by a user or service provider
manually, or through some other non-SIP mechanism. When a provider
wishes to configure a UA with an outbound proxy, it is RECOMMENDED
that this be done by providing it with a pre-existing route set with
a single URI, that of the outbound proxy.
When a pre-existing route set is present, the procedures for
populating the Request-URI and Route header field detailed in Section
12.2.1.1 MUST be followed (even though there is no dialog), using the
desired Request-URI as the remote target URI.
The only case in which R-URI won't equal the To-URI is if there is a
preexisting route set and the first route in that set is a
strict-router. In that case the To-URI will end up as the last value of
the Route header.
Loose routing has been defined for five years or so now. It generally
ought to be supported. So in general the R-URI should equal the To-URI.
In my example they would both equal what was in the From-URI of the
incoming call that is now being returned.
>>> I'm not sure
>>> this would be desirable behavior. If the host part of the R-URI
> does
>>> not identify a domain for which the network serving the calling
> party is
>>> authoritative, then as I understand it the network serving the
> calling
>>> party should simply proxy the INVITE per 3263. But then how does
> the
>>> network serving the calling party provide originating services to
> its
>>> subscriber?
>>>
>>> As a practical matter I'll note that in some networks with which I
> am
>>> familiar, the value to be used in the host part of the R-URI is
> dictated
>>> by the network.
>> If you are originating a call from a dial string, not a URI, then I
>> guess you can formulate the R-URI any way you want. But if the calling
>> party is supplying a URI (e.g. one it has saved from a prior received
>> call) then it should be used as-is.
>
> Well as I noted, such a call will fail in some networks with which I am
> familiar. In some cases it may succeed because the network ignores or
> its dreaded SBCs overwrite, the host part of the R-URI. I doubt you'll
> find many public networks willing to allow their proxies to be used but
> their call servers bypassed.
Their proxies don't have to be bypassed. Those proxies just become part
of a preexisting route set known to the UAC and populated into the Route
header.
>> If you want some server on the originating end to do something for the
>> outbound call, then you should put a Route header in the request
>> identifying the server.
>
> I see how that could work, yes. Except for the issue that many
> currently deployed devices do not support Route headers.
Its about time they got with the program.
>> As a practical matter, suppose you receive a call from
>> sip:[EMAIL PROTECTED] If you want to return that call, you
>> have little choice but to use that as the R-URI. You can't very well
>> send it to sip:[EMAIL PROTECTED] and expect the right
>> thing to happen.
>
> Of course. But I believe the issue here is specific to URIs that have
> telephone numbers as the user part.
>
> I think the issue we're wrestling with is whether the semantics of the
> relationship between user and host part of such URIs is the same as that
> of "email style" URIs. I believe that it is not.
It should be the same until you get to the target domain.
But I just posted another message on a closely related point that goes
into this more. You might want to reply to that.
And I don't see how treating them differently helps you. Won't your SP
still want to provide originating services when I'm calling
sip:[EMAIL PROTECTED] How will it do so?
> In an email style URI (one whose user part is not a telephone number)
> the domain in the host part provides service to the user identified in
> the user part. In a URI whose user part is a telephone number, the
> domain in the host part may or may not (i.e., cannot be assumed to)
> provide service to the user identified in the user part.
I think we can/should assume that it is *claiming* responsibility, at
least to the extent that return calls to this URI should pass through
it, perhaps after passing through other servers. It may decide to relay
the call on elsewhere, but initially it is to be assumed to be the
responsible domain. As I note in my other post, proxies MUST treat it
that way.
> By identifying
> "foo.com" in the host part of a URI whose user part contains a telephone
> number, I am giving the network authoritative for foo.com the right to
> examine for purposes of routing, the user part of the URI. I am not
> implying that that network provides service to the user identified by
> the URI's user part. It might, but if it did that would be
> coincidental.
That is really true for any URI. When the request reaches a server
authoritative for the domain of the URI it is some sense has reached its
destination - the place the stated in the URI. It is up to that server
to decide if it really wants to respond, or to forward it on to some
*other* *more* responsible server.
There is no law that says how a server responsible for a domain is to
interpret the user part. Even if the URI looks like a phone number and
there is a user=phone param, it is not *obligated* to deliver the
request to some place that the *caller* thinks owns that phone number.
It can make its own decision.
Now this may all still work, swapping domain names while leaving the
user part alone. But only if it is done amongst a bunch of "consenting
adult" servers that have a consistent policy about the handling of the
user part.
>> So, if you received a call from sip:[EMAIL PROTECTED];user=phone,
>> then IMO the caller had an expectation that callbacks would be
> delivered
>> there, not to sip:[EMAIL PROTECTED] But in fact that is
> exactly
>> what a lot of systems are doing.
>
> This has nothing to do with where the call is delivered. If we're
> talking about global public telephone numbers, then +12125551234
> uniquely identifies an endpoint. In the absence of erroroneous
> configuration both calls will complete to that endpoint. The only
> practical difference is how they get there.
*You* may think that +12125551234 uniquely identifies the endpoint. But
that doesn't mean that foo.com agrees with you. foo.com minted the URI
with the expectation that requests would be delivered to it.
You may sent it to your-sp.com *first*, but ultimately you ought to be
getting it to the foo.com server with sip:[EMAIL PROTECTED] as the R-URI.
A key difference in this regard is that if you are obligated to get it
to sip:[EMAIL PROTECTED] then you won't be able to route it via the
PSTN. That may be exactly what foo.com intended.
>>>> I don't know that we can do anything about it, except perhaps
> publish
>>>> some best practices drafts. But I expect it may be a problem for a
> long
>>>> time.
>>> A "best practice" promoting the behavior described above, seems
>>> problematic. Maybe if there are networks somehow fundamentally
> unlike
>>> that described above (e.g., where there is no concept of originating
>>> services), it could be scoped to be applicable to them? I suppose
> this
>>> is a general problem with best practices - few are universally
> "best".
>> I think as a community we are far from agreeing on what "best
>> practices"
>> are. Hopefully it will eventually be sorted out. But it seems that
>> there is a fair chance that we will never all agree on what best
>> practices are in this regard, and will continue to be
>> partitioned into a
>> bunch of warring feudal communities, with tax collectors on
>> every road.
>
> Frankly I'm missing why this is such a big deal. If a network changes
> sip:[EMAIL PROTECTED];user=phone to sip:[EMAIL PROTECTED], but
> the session anyway terminates to the device at which +12125551234 is
> registered, so what?
Getting an e2e sip connection can be a big deal. It means I can
potentially use a variety of media, rather than just voice, and I can
use various call control primitives that wouldn't otherwise be available.
What you want can easily be achieved if the caller starts out with a tel
uri in the r-uri field. But then it has the latitude to decide which it
wants to do.
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
