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.
> > 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.
> 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.
>
> 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.
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. 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.
> 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.
>
> >> 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?
Tim
_______________________________________________
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
