Subject: RE: [Ecrit] draft-ietf-ecrit-urn

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Mar 2006 11:35:30 -0000

Certainly in the 3GPP scheme of things, while the UA is required to try and identify emergency calls, it is regarded as fallible, and therefore the first proxy met (P-CSCF) will also perform an emergency call identification procedure. Therefore from a 3GPP perspective a proxy needs to be able to insert this marking. This first proxy is not the entity that performs the routeing analysis to determine which PSAP is to be used - that is performed by a later proxy in the path (E-CSCF), and therefore the Request-URI sent from this proxy will not be the PSAP URI, but will be the emergency URN.

After the analysis is done the call is forwarded either to the PSAP (IP connected) or via another proxy (BGCF) and a gateway UA (MGCF) to the PSAP (PSTN connected). I assume the Request-URI in both these cases is no longer the emergency URN but represents directly the PSAP.

This process is described more fully in http://www.3gpp.org/ftp/Specs/html-info/23167.htm

Both before the proxy (E-CSCF) and after it, there is a need to mark the call in order to give it priority as the intermediate SIP entities are not necessarily dedicated entirely to emergency calls. I agree we should keep this simple. It also occurs to me that any recognition of the marking should also be possible reasonably early in the proxy processing (section 16.1 onwards of RFC 3261).

regards

Keith

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 28 February 2006 20:32
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Ecrit] draft-ietf-ecrit-urn
> 
> 
> I'm hoping that the use of the service URN in the SIP To 
> header field is 
> sufficient marking. In the sipping-sos case, I had split this 
> into two 
> since there was the perception that overloading the user field of the 
> URI with lots of different services would be a bad idea. This isn't 
> really a problem here.
> 
> See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an 
> attempt to go through the various cases of who determines 
> that a call is 
> an emergency call.
> 
> The one issue that arises is if the UA doesn't recognize 
> emergency calls 
> and just routes the SIP or tel URI to the proxy. The proxy 
> can't replace 
> the To header field, so there's no place to put a service 
> indication. I 
> don't know if that is important since the same entity will 
> also have to 
> do the mapping and thus insert a PSAP URI in the request URI 
> field. The 
> request will then visit that PSAP URI on the next hop. Unless a PSAP 
> were to use the same URI for both the general business 
> address and the 
> emergency contact address, there is no confusion and no additional 
> routing in the "public" SIP server space. (Commingling emergency and 
> non-emergency calls on the same SIP URI seems both ill-advised and 
> unnecessary.)
> 
> Do you think we need the additional marker? (My general 
> inclination is 
> to keep things as simple as possible, i.e., to avoid adding 
> SIP header 
> fields if we can help it.)
> 
> It would be easy to keep the same media feature tag as in sipping-sos:
> 
> Accept-Contact: *;sip.service="urn:service:sos.marine"
> 
> Opinions?
> 
> Henning
> 
> 
> Drage, Keith (Keith) wrote:
> > I understood that the predecessor of this document 
> > 
> > draft-ietf-sipping-sos-02: Emergency Services URI for the 
> Session Initiation Protocol
> >                        
> > implicitly carried the implementation of the following 
> requirement from draft-ietf-ecrit-requirements-05, i.e. the 
> presence of the emergency URI was also the emergency marking.
> > 
> >   Id3.  Emergency Marking: Any device in the signaling path that
> >       recognizes by some means that the signaling is 
> associated with an
> >       emergency call MUST add a specific emergency indication, if it
> >       doesn't already exist, to the signaling before forwarding it.
> >       This marking mechanism must be different than QoS marking.
> > 
> >       Motivation: Marking ensures proper handling as an 
> emergency call
> >       by downstream elements that may not recognize, for example, a
> >       local variant of a logical emergency address.
> > 
> > So my question is as to whether the presence of the service 
> type "sos" defined in the new draft is sufficient indication 
> of this marking, or whether ecrit expects some other SIP 
> indication to give this emergency marking.
> > 
> > regards
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > [email-masked]
> > tel: +44 1793 776249
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Mar 2006 09:35:51 -0500

If a priority marking is desired, maybe Resource-Priority is the  
right mechanism (with a new namespace). Would that suffice?

On Mar 1, 2006, at 6:35 AM, Drage, Keith (Keith) wrote:

> Certainly in the 3GPP scheme of things, while the UA is required to  
> try and identify emergency calls, it is regarded as fallible, and  
> therefore the first proxy met (P-CSCF) will also perform an  
> emergency call identification procedure. Therefore from a 3GPP  
> perspective a proxy needs to be able to insert this

I don't see how this can work if the UA uses 'urn:service:sos' as the  
'To' header field, as it should. Such proxy identification would only  
be needed if the UA doesn't know the dial string and uses either a  
tel or SIP URI.

> marking. This first proxy is not the entity that performs the  
> routeing analysis to determine which PSAP is to be used - that is  
> performed by a later proxy in the path (E-CSCF), and therefore the  
> Request-URI sent from this proxy will not be the PSAP URI, but will  
> be the emergency URN.
>
> After the analysis is done the call is forwarded either to the PSAP  
> (IP connected) or via another proxy (BGCF) and a gateway UA (MGCF)  
> to the PSAP (PSTN connected). I assume the Request-URI in both  
> these cases is no longer the emergency URN but represents directly  
> the PSAP.
>
> Both before the proxy (E-CSCF) and after it, there is a need to  
> mark the call in order to give it priority as the intermediate SIP  
> entities are not necessarily dedicated entirely to emergency calls.  
> I agree we should keep this simple. It also occurs to me that any  
> recognition of the marking should also be possible reasonably early  
> in the proxy processing (section 16.1 onwards of RFC 3261).
>
> regards
>
> Keith
>