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
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit