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
