Paul, > Dwight, Timothy M (Tim) wrote: > > 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. > > IMS *does* use Route headers for this, at least in-dialog. Its been > quite awhile since I looked at IMS and I'm starting to forget. As I > recall they were a bit inconsistent about whether the P-CSCF > is listed > in the Route header, or if the request is just sent there > without. If I > remember correctly the Route header isn't used for the > REGISTER, But it > is used subsequently.
I guess I'm forgetting too :-) Anyway you're right, IMS does use Route headers (except in REGISTER, which is sent to the P-CSCF learned during "P-CSCF discovery"). Basically the UE gets a route list in the Service-Route header appended to the 200OK received in response to the REGISTER, and uses that list in to populate the Route header in subsequent dialog-initiating requests. > > 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, > > It just means the foo.com itself created the URI. Which > indicates that > it at least *believes* it can process the user part. > > > but hopefully it doesn't involve foo.com generating > > calls whose From-URI imbeds a telephone number for which > foo.com is not > > responsible. > > AFAIK foo.com is permitted to populate the user portion of > the uri with > anything it wants that is syntactically valid. I don't disagree that IETF may permit this. But appropriate use of numbering resources is not up to the IETF. I think it is at least bad practice to identify a session originator with a URI whose structure implies that the user part is a telephone number (user part is numeric, preceded by '+', "user=phone" parameter appended, etc.,), unless the originating network has some legitimate right to assign that number. The only reason I can think of to allow this, would be to facilitate the sort of mischief (spoofing of caller ID etc.,) that currently plagues the PSTN, and has been rightly criticized on this list. I understand that such a policy is difficult to enforce via protocol mechanisms. "appropriate use" policies, often are. Still documenting them can be of use, for example because they legitimize the punishment :-) And certainly if this discussion vectors into definition of a BCP we would want to take care that the IETF not endorse or promote antisocial practices. 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
