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

From: "McCalmont, Patti" <[email-masked]>
Date: Wed, 1 Mar 2006 09:07:16 -0600

Keith,

I'm in agreement for the local network to add markings that identify the
emergency call as early as possible. This enables, as you said,
prioritizing the call by other proxies in the path. It also could be
used as a means to detect the emergency call in a visited network and
process the call locally.

Patti McCalmont

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2006 5:36 AM
To: 'Henning Schulzrinne'
Cc: [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-urn

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

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