Thanks, Paul. This has been a useful exchange. I agree with you that we need to be able to provide originating services to the calling party without forcing the R-URI to identify a domain for which the calling party's network is authoritative. And as you note this is mandatory to support "email style" R-URIs. Inclusion of a Route header seems like a good solution, albeit one dependent on supplier implementation. IMS offers another.
On reflection I'm not sure the rule that "if I give you sip:[EMAIL PROTECTED], with or without user=phone, then a call back to that URI MUST be via sip" is advisable. What if there's no VoIP peering agreement between my network and the network authoritative for 'sp.com'? Which would you prefer, that the call fail or that it be routed via the PSTN? Given that there's no practical way to know each caller's preference, networks will have to implement some "reasonable" policy. To me it seems reasonable to expect that someone who identifies himself with a telephone number would not be opposed to receiving calls via the PSTN, if that's the only way they can be delivered. I'm not sure what you mean by "foo.com minted the URI with the expectation that requests would be delivered to it". I'm not sure what "minting" means, but hopefully it doesn't involve foo.com generating calls whose From-URI imbeds a telephone number for which foo.com is not responsible. "Responsibility" is a bit vague, but basically I mean that either the number is assigned to foo.com by the numbering plan authority, the number is ported to foo.com, or use of the number is authorized to foo.com by its legitimate owner (e.g., through a wholesale arrangement). The issue is that there be a "chain of custody" leading to the entity providing service to the number. Implementation of lawful intercept, for example, relies on this. tim > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 10, 2008 6:34 PM > To: Dwight, Timothy M (Tim) > Cc: [email protected]; Francois Audet; Dan Wing > Subject: Re: [Sip] E.164 - who owns it > > > > 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
