I agree with your sentiment. I don't see how the access network is in the calling path at all unless it's an IMS-like system where that is the agreement. In that case, by definition, the access network has a relationship with the calling network. Normally, the UA's proxy discovery mechanism leads it to its calling network, not anything in the access network.
I think if it happened accidently, it would work; no matter who routes it, the PSAP URI leads to the right place. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 10:29 AM > To: Brian Rosen > Cc: 'Richard Barnes'; 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT' > Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > > Brian, > > I agree that there will be implementations that break whatever rules we > make. But does that mean we should make no rules? > > In this case it isn't even a matter of making a new rule - it is an old > one I am talking about. > > But the key here is to ensure that when we develop use cases, examples, > etc. they don't break this rule. If a practical system will require > breaking the rule then IMO another mechanism is needed. > > The case that concerns me most here is when a UA is connected through an > access network that is different from its home network. Then the access > network preemptively decides that a particular R-URI looks like an > emergency number in its domain, and acts accordingly, even though the > R-URI isn't within the domain of the access network. > > The point here of course is that there are no universal standards for > the user part of SIP URIs. So there is no way that a proxy not > responsible for the domain of the URI to decide that the user part is a > dial string at all, and not something else. (Well, user=dialstring *is* > a standard for the user part, but it *explicitly* is intended only for > use within the responsible domain.) > > In such a case, either the UA should be using the domain of the access > network when constructing dial strings, or else the access network > should have a business relationship with the home network that is > sufficient for the access network to claim responsibility for the domain > of the R-URI. > > Paul > > Brian Rosen wrote: > > I think that if you look, you can find proxies that will break anything > we > > can define. No matter what we specify, there is sure to be a proxy out > > there that breaks it. For example, there are proxies that strip any > header > > they don't recognize. They aren't supposed to, but they do. > > > > It's futile to try and define any new behavior based on what non > standard > > existing proxies will do. In this case, they will have to recognize > > emergency calls and do the appropriate processing of them. > > > > The test function would find these things, of course. > > > > Brian > > > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:[EMAIL PROTECTED] > >> Sent: Monday, September 10, 2007 8:42 AM > >> To: Hannes Tschofenig > >> Cc: IETF SIP List; ECRIT > >> Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > >> > >> Hannes, > >> > >> I'm still worried that because we're using the routing fields for > >> marking, there's a risk that proxies will do things to those headers > >> that will remove the marking and cause the emergency call to fail. > >> > >> For instance, I've heard tell that some proxies like to strip all Route > >> headers from INVITE messages passing through them. In your example > >> below, that would cause the call to need another LoST lookup, which may > >> be impossible if no subsequent proxy supports LoST, or if there's no > >> proxy-readable location in the INVITE. Moreover, if a proxy changes > the > >> To field or the Request URI, then downstream proxies might not even > >> recognize that a LoST lookup is required and thus would cause the call > >> to fail. > >> > >> I don't disagree with the three abstract states you've defined > >> (unrecognized, recognized but not routed, and routed), but I would > >> prefer that (1) The Service URN were carried in an explicit marking > >> field even if a new one has to be created (say, Requested-Service), and > >> that (2) after routing (LoST) a call looks like any other call to a > PSAP > >> URI, but with an explicit marking. I think this would be much more in > >> the spirit of minimal surprise. > >> > >> --Richard > >> > >> > >> > >> Hannes Tschofenig wrote: > >>> Hi all, > >>> > >>> after some discussions on the usage of the Service URN it seems that > >>> most people in ECRIT agreed to move forward with the initially planned > >>> approach. Below, you can find a description of how the Service URN > would > >>> be used in various scenarios. > >>> > >>> Are there any objections? > >>> > >>> Ciao > >>> Hannes > >>> > >>> --------------------- > >>> > >>> == End Host Procedures == > >>> > >>> * UA does not recognize the emergency call. > >>> > >>> To: Dial String > >>> Request URI: Dial String > >>> No Route header > >>> > >>> * UA runs LoST and determines the PSAP URI: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * UA does not run LoST but recognizes the emergency call. > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> > >>> == Proxy Procedures == > >>> > >>> * Incoming request contains Service URN; Proxy runs LoST > >>> > >>> and determines the PSAP URI > >>> > >>> --- Input: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * Incoming request contains Dial String; Proxy runs LoST > >>> > >>> and determines the PSAP URI: > >>> > >>> --- Input: > >>> > >>> Request URI: Dial String > >>> To: Dial String > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Dial String > >>> Route Header: PSAP URI > >>> > >>> > >>> > >>> Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> [EMAIL PROTECTED] > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.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 > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.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 > > _______________________________________________ Sip mailing list https://www1.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
