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

[Hannes Tschofenig <[e-mail]>]

Hi Keith,

I think in ECRIT we essentially came to the conclusion that we want to 
use the procedure described in
http://www1.ietf.org/mail-archive/web/ecrit/current/msg04297.html

I believe Brian has added the description already to the most recently 
submitted Phone BCP draft, see
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt

For dealing with emergency call marking within a PSAP operator network 
the RPH header may be fine.
I was asked by James whether 
draft-polk-ecrit-local-emergency-rph-namespace-01.txt can become a 
working group item of ECRIT and after interacting with our ADs they 
suggested to postpone such a question to the group after we finished our 
current items. That's fine with me as well given that our progress

Ciao
Hannes

DRAGE, Keith (Keith) wrote:
> 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
>   


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