RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt

["DRAGE, Keith \(Keith\)" <[e-mail]>]

I think this is a case of horses for courses. People have said we should
not overload headers, and we seem to have two separate functions - the
routing function and the processing treatment function where emergency
calls need to be recognised for special handling.

Where emergency calls in the network require special processing
treatment, then I also consider the RPH header is appropriate. Note that
this is not a case of treating emergency calls first, more a matter of
making sure that they are not precluded by other heavy traffic.

I (now) understand the need to retain the service URN once a candidate
PSAP address has been identified. This is a routeing function.

I think we need two separate solutions covering each problem. Each
solution is inappropriate to cover the other problem.

Regards

Keith

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]] 
> Sent: Wednesday, September 05, 2007 7:29 AM
> To: Henning Schulzrinne; DRAGE, Keith (Keith)
> Cc: ECRIT
> Subject: Re: [Ecrit] Re: [Sip] 
> draft-rosenberg-sip-ua-loose-route-01.txt
> 
> I believe I agree that the RPH shouldn't be relied upon as 
> the (or the only) enduring indication a call is an emergency call.
> 
> I think the sos RPH namespace should be used within emergency 
> networks for resource treatment. 
> draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks 
> about this.
> 
> I also think it should be up to the arrangements between the 
> emergency network to and a service provider, say one with an 
> IMS architecture, to establish trust to a particular server, 
> perhaps each E-CSCF within that provider's network, to 
> appropriate PSAPs.  In this scenario, which should be 
> possible, but not necessarily pushed at this time, the *-CSCF 
> can add the sos RPH to an emergency SIP request.  The SP 
> would be taking on the charge of making sure the RPH wouldn't 
> cause harm within their network to the emergency services network.
> 
> At 02:08 PM 9/4/2007, Henning Schulzrinne wrote:
> >As for Brian, my preferred solution is the loose-route proposal.
> >
> >If we want an explicit marking, I think an explicit header would be 
> >clearest, as in
> >
> >Service: urn:service:sos.fire
> >
> >(I don't want this to be conflated with the service 
> discussion in SIP; 
> >this has nothing to do with what's been discussed there. I 
> don't care 
> >about the header label.)
> >
> >Resource priority is, in my opinion, not appropriate for marking the 
> >service requested since such calls may not actually get resource 
> >priority and since it is unlikely that fire calls will get a 
> different 
> >priority from police calls. Conversely, the RPH header is dangerous 
> >outside carefully controlled environments, since it can be a 
> DOS tool. 
> >In particular, RPH requires strong client authentication, which is 
> >generally not available in emergency calls. Within the
> >(trusted) ESN, this isn't a major problem, but letting end users or 
> >VSPs set that header field is asking for trouble unless 
> other entities 
> >can verify that the call is indeed an emergency call. If they can do 
> >that, then you don't need the header.
> >
> >Overloading headers just because they are available doesn't 
> strike me 
> >as architecturally appropriate.
> >
> >Henning
> >
> >On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote:
> >
> >>(Removing parties from the original list distribution)
> >>
> >>The situation in 3GPP is that we have so far failed to agree any 
> >>marking or other carriage of other information (with a significant 
> >>number of the objections coming from the organisation 
> Christer works 
> >>for), not that we have agreed we don't want one.
> >>
> >>I believe the appropriate way forward on marking for 
> special handling 
> >>is actually the Resource-Priority header solution identified by
> >>
> >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-
> >>emergency-rph-namespace-01.txt
> >>
> >>In terms of special handling, this makes a lot of sense for 
> those SIP 
> >>entities that already have to implement RFC 4412 for other 
> regulatory 
> >>reasons.
> >>
> >>As already indicated, the 3GPP E-CSCF (the emergency routeing
> >>proxy) changes the Request-URI to the PSAP URI, and the original 
> >>Reuqest-URI is lost. Once we have reached the E-CSCF, is 
> the original 
> >>Request-URI (the service URN) still important for any issue 
> apart from 
> >>special handling?
> >>
> >>Regards
> >>
> >>Keith
> 

_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit