Most carriers have pretty closed systems. They only route within their own domain. Some are now doing inter-carrier routing, but generally that is with gateway nodes within the domain which connect to some kind of peering system. It's not really clear how they will modify this for emergency calls. IMS has a separate proxy (E-CSCF) that would handle it. Others may make it a function of their gateway proxies.
The Route stripping can happen in a couple of places. The most common is the SBC that protects the network from wayward user devices. The way most SBCs are set up, I think they will have to be changed for any emergency call processing; they often don't pass anything that isn't a TN in the R-URI, and that's where headers not understood in the network are often dropped. I think the SBC issues are pretty straightforward; some changes are going to be needed, and if there is a spec, the spec can be accommodated. Then it depends on how the network is configured. In my experience, the next hop routing proxy does most of the work; from there, it's mostly special processing the nhrp invokes, or the call is on a gateway node next. Most routing proxies don't drop Route headers, but some that I know of don't pay any attention to them. I'd worry a little about those. The SBC can preroute (which may be a good idea anyway), or the nhrp element may need an update. The call is then probably on some kind of gateway element, which also can be an SBC. Again, I don't think any of these drop Route headers, but some may ignore them. Whatever it is, it will need at least some configuration work to get the call out of the carrier domain into the emergency services domain. I guess my bottom line is that the networks are going to need some set of changes to deal with emergency calls at all, and when those changes are done, the whole thing will work. I suspect most of this really is configuration, but if there are code updates needed, I think they will be needed regardless of which solution we choose. Brian > -----Original Message----- > From: Richard Barnes [mailto:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 9:36 AM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT' > Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > > > I think that if you look, you can find proxies that will break anything > we > > can define. ... For example, there are proxies that strip any header > > they don't recognize. They aren't supposed to, but they do. > > Sure, but we should try to look at likely failure modes and mitigate > their impact on emergency calls. It's in the interest of VSPs to route > calls to the correct destination (so that their service actually works), > but it's often not in their interest to route it via the path specified > in the Route header fields. > > So if the PSAP URI were carried in the R-URI/To, and the Service URN > were carried in another header (even Route), then even a proxy that > stripped out every header it doesn't like or recognize would still get > the call to the PSAP (even if the PSAP wouldn't know which service was > requested). > > I thought that this was the point of keeping emergency calling as close > as possible to normal calling -- that in spite of whatever pathological > things proxies might do, the call would get through. > > > The test function would find these things, of course. > > That's true of whatever we define. For that argument to be applicable > to a given emergency call, you also need to assume that the UA does > tests every time the proxy path between it and the PSAP changes. Of > course, this could happen without the UA knowing it, so the UA would > have to be frequently testing. > > --Richard > > > > > > > > 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
