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

[Henning Schulzrinne <[e-mail]>]

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
>
>> -----Original Message-----
>> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
>> [mailto:[e-mail]]
>> Sent: Tuesday, September 04, 2007 1:06 PM
>> To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig
>> Cc: IETF SIP List; ECRIT; Dean Willis
>> Subject: AW: [Ecrit] Re: [Sip]
>> draft-rosenberg-sip-ua-loose-route-01.txt
>>
>> Hi Christer,
>>
>> Thanks for your quick response.
>> Please find a few comments below:
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ext Christer Holmberg (JO/LMF)
>>> [mailto:[e-mail]]
>>> Gesendet: Dienstag, 4. September 2007 14:00
>>> An: Hannes Tschofenig
>>> Cc: IETF SIP List; ECRIT; Dean Willis
>>> Betreff: RE: [Ecrit] Re: [Sip]
>>> draft-rosenberg-sip-ua-loose-route-01.txt
>>>
>>>
>>> Hi,
>>>
>>>>> In 3GPP, it is true that the UE inserts the service URN into the
>>> Request-URI.
>>>>>
>>>>> But, in the current specification the E-CSCF converts the
>>> URN into a
>>>>> routable PSAP address, i.e. the mechanism in the
>>> loose-route draft is
>>>>> not used.
>>>>>
>>>>>
>>>> Why was this done?
>>>
>>> I don't have all the details, but one reason was that the same
>>> procedures were wanted towards a PSAP and an MGCF, and at
>> least in the
>>> previous 3GPP releases the MGCF does the called party number mapping
>>> based on the Request-URI value.
>>
>> You mean that the MGCF wouldn't know what todo with the Request URI.
>> This sounds like a backwards compatibility aspect.
>>
>>> Also, since this was done a while ago,
>>> the loose-route draft mechanism wasn't even discussed.
>> That's probably true.
>>
>>  Also, since
>>> neither the PSAP or MGCF registers themselves to the E-CSCF, the
>>> loose-route draft mechanism wouldn't be used towards those
>>> entities even
>>> if adopted by IMS.
>>
>> I don't think that the Request URI has anything todo with
>> registrations.
>>
>>>
>>>> Do you expect that the call uses a different emergency call marking
>>> technique went it enters the PSAP operator network?
>>>
>>> I think it is up to each operator to decide how the marking is done.
>>
>>
>> In the 3GPP model with the E-CSCF and the PSAP having a close
>> relationship you could leave this issue open. It would,
>> however, make their life easier.
>>
>>> There will always be agreements between the PSAP operators
>>> and the other
>>> ("public") operators using them.
>>
>> Only in the 3GPP IMS alike architecture. The IETF emergency
>> services architecture is a bit different.
>>
>>  I guess it would also be possible to
>>> put the original service URN into the P-Called-Party-Id
>> header (as for
>>> normal calls), eventhough I don't think it's currently specified.
>>
>> I am not sure whether this is a good solution.
>>
>>>
>>>> Do you expect that the call is directly sent from the E-CSCF to the
>>> PSAP and that there are no other hops in between?
>>>
>>> I think both cases are applicable.
>> When you have intermediate entities that need to recognize
>> emergency calls and need to treat the call differently then
>> you might want to define the procedures since otherwise there
>> is a chance that things don't work as expected.
>>
>> Ciao
>> Hannes
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>>>> -----Original Message-----
>>>>>> From: Hannes Tschofenig [mailto:[e-mail]]
>>>>>> Sent: 3. syyskuuta 2007 22:59
>>>>>> To: Dean Willis
>>>>>> Cc: IETF SIP List; ECRIT
>>>>>> Subject: Re: [Ecrit] Re: [Sip]
>>>>>> draft-rosenberg-sip-ua-loose-route-01.txt
>>>>>>
>>>>>> Hi Dean,
>>>>>>
>>>>>> in ECRIT we assumed that the Request URI contains the
>>>> service URN. We
>>>>>> put that stuff into the Phone BCP document (which
>>>> unfortunately still
>>>>>> contains an error I just noticed).
>>>>>> That's what we told the 3GPP in the past as well. Hence,
>>>> they wrote
>>>>>> it in their specs. See TS 24.229, Section 5.1.6.8.3,
>> bullet (1).
>>>>>>
>>>>>> Within the ECRIT group we weren't aware that this issue
>>>> has not been
>>>>>> decided and hence we are a bit concerned about the
>> recent change
>>>>>> given that other SDOs followed our suggestion already.
>>>>>>
>>>>>> Do you have an idea what we should do now?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> Dean Willis wrote:
>>>>>>
>>>>>>> Hannes Tschofenig wrote:
>>>>>>>
>>>>>>>> No response received -- resend.
>>>>>>>>
>>>>>>>> Hannes Tschofenig wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Dear SIP WG members,
>>>>>>>>>
>>>>>>>>> during the ECRIT meeting we learned that the SIP
>>> working group
>>>>>>>>> "rejected" the concept described in
>>>>>>>>> draft-rosenberg-sip-ua-loose-route-01.txt.
>>>>>>>>>
>>>>>>>>> Could someone please give us more information about this
>>>>>>>>>
>>>>>> decision as
>>>>>>
>>>>>>>>> it impacts the work we do in ECRIT?
>>>>>>>>>
>>>>>>> I wouldn't say that UA Loose Route was "rejected" so much
>>>>>>>
>>>>>> as "does not
>>>>>>
>>>>>>> yet have consensus".
>>>>>>>
>>>>>>> This is in part influenced by "WG doesn't seem to have a
>>>> compelling
>>>>>>> reason to make such a significant change."
>>>>>>>
>>>>>>> Perhaps ECRIT has a compelling reason?
>>>>>>>
>>>>>>> --
>>>>>>> Dean
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>> This list is for NEW development of the core SIP Protocol Use
>>>>>> [e-mail] for questions on
>>> current sip Use
>>>>>> [e-mail] 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 [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
>>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ecrit


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