Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt]

From: "Barclay, Deborah L \(Deb\)" <[email-masked]>
Date: Fri, 10 Oct 2008 16:50:13 -0500

Milan, John-Luc,

For the example provided below, the service-urn would be replaced as a
result of determining the call is routed to a CS PSAP.  The service-urn
is preserved until the routing function determines the appropriate
emergency center and only replaces the service-urn because it had to be
converted to a digits. If different service-urns require different
destinations, that would have been accounted for.  The single sos
parameter should be sufficient for proper emergency call handling and
the service-urn is available and sufficient for correct routing.  

Since opinions were being sought, my opinion is to keep the sos
parameter/marker simple for efficient emergency call handling purposes.

Thank you,
Deb Barclay
 
> ------------------------------
> 
> Message: 2
> Date: Fri, 3 Oct 2008 14:45:08 +0100
> From: "Milan Patel" <[email-masked]>
> Subject: Re: [Ecrit] [Fwd: I-D
> 	Action:draft-patel-ecrit-sos-parameter-00.txt]
> To: "John-Luc Bakker" <[email-masked]>, "ECRIT"
> 	<[email-masked]>
> Message-ID:
> 	
> <[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi John-Luc, 
> 
> Currently the draft only specifies that the "sos" parameter 
> only conveys information that the request/response is related 
> to an emergency session. But I do find your use case valid. 
> I'd like to know what others think, but can propose the 
> extension in version-01 if there is wider support.
> 
> Best regards,
> Milan
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of John-Luc Bakker
> Sent: 03 October 2008 14:32
> To: ECRIT
> Subject: Re: [Ecrit] [Fwd: I-D
> Action:draft-patel-ecrit-sos-parameter-00.txt]
> 
> Milan,
> 
> The proposed new URI parameter is opaque. It marks the call 
> as an emergency call but fails to convey the emergency call 
> type even if an emergency call type could be deduced from the 
> original request.
> Particularly if the Emergency Service URN in the Request-URI 
> is replaced by a network entity, as you suggest, not loosing 
> the emergency call type information seems useful. In some 
> deployments, emergency calls are routed to PSAPs that support 
> the requested emergency types.
> 
> Kind regards,
> 
> John-Luc
> 
> On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig 
> <[email-masked]> wrote:
> > Please take a look at this document. Milan would like to hear some
> comments!
> >
> > Ciao
> > Hannes
> >
> > -------- Original Message --------
> > Subject:        I-D Action:draft-patel-ecrit-sos-parameter-00.txt
> > Date:   Fri, 12 Sep 2008 09:45:01 -0700 (PDT)
> > From:   [email-masked]
> > Reply-To:       [email-masked]
> > To:     [email-masked]
> >
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >        Title           : SOS Uniform Resource Identifier (URI)
> parameter for marking of Session Initiation Protocol (SIP) 
> requests related to emergency services
> >        Author(s)       : M. Patel
> >        Filename        : draft-patel-ecrit-sos-parameter-00.txt
> >        Pages           : 9
> >        Date            : 2008-09-12
> >
> > This memo describes requirements and protocol conventions for a new 
> > SIP (Session Initiation Protocol) URI parameter intended 
> for marking 
> > SIP requests and responses related to emergency services.  This 
> > proposal addresses issues that exist in the current 3rd Generation 
> > Partnership Project IP Multimedia Subsystem (IMS) Emergency 
> services 
> > solution, but is not precluded from being used by other SIP-based 
> > emergency services solutions.  It is not intended as a 
> replacement for 
> > the service URN.
> >
> > A URL for this Internet-Draft is:
> >
>
http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t
xt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> >
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "John-Luc Bakker" <[email-masked]>
Date: Wed, 22 Oct 2008 12:43:13 -0500

Hi Deb,

Thanks for commenting.
RFC 5031 mentions a generic emergency URN and emergency URNs for
specific emergency service types; such as "urn:service:sos.gas" or
other locally relevant types (e.g "urn:service:sos.eletricity?").
Would an INVITE, for the purposes of making a call back, from a UAS
handling urn:service:sos.<gas, electricity, etc.> calls also include
the sos parameter?

In case the UAC failed to recognize the request as a emergency session
request and the local network translates, say "121", to
"urn:service:sos.electricity", would the UAC still receive an opaque
"sos" indicator?

In case emergency service type information is available, I see no harm
in indicating the emergency service type information to the UAC. I am
not sure what "efficiency" is gained by not indicating emergency
service type information using a few extra characters in a SIP
message.

Kind regards,

John-Luc

---

From: "Barclay, Deborah L (Deb)" <[email-masked]>
Date: Thu, 23 Oct 2008 08:18:54 -0500

Hi John-Luc,

I have provided responses to your questions. See "dlb>" below.

Thanks,
Deb 

> From: John-Luc Bakker [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 12:43 PM
> To: Barclay, Deborah L (Deb)
> Cc: [email-masked]
> RFC 5031 mentions a generic emergency URN and emergency URNs 
> for specific emergency service types; such as 
> "urn:service:sos.gas" or other locally relevant types (e.g 
> "urn:service:sos.eletricity?").
> Would an INVITE, for the purposes of making a call back, from 
> a UAS handling urn:service:sos.<gas, electricity, etc.> calls 
> also include the sos parameter?

Dlb> If sos.gas was sent by the UE to make the original call and
supported by the network, then according to rfc5031, it is an emergency
service requiring immediate response and it was not used for general
services. Therefore, it seems that the jurisdictions that treat sos.gas
as an emergency call would then treat the callback as a callback for an
emergency call - and would include the indicator.   This is consistent
with ecrit phonebcp, it would be treated as an emergency callback
because emergency callback is determined "by retaining the domain of the
PSAP which answers an outgoing emergency call".  Do you agree with this
analysis?

> 
> In case the UAC failed to recognize the request as a 
> emergency session request and the local network translates, 
> say "121", to "urn:service:sos.electricity", would the UAC 
> still receive an opaque "sos" indicator?

Dlb> Assuming this is a bad example and meant one that is in the rfc
(electricity is not)then, applying the same logic, yes, if the network
determined it was an emergency call then the sos indicator applies since
rfc5031 says sos service urns should only be used for emergencies
requiring an immediate response and should not be used for general
services.  Do you agree?

> 
> In case emergency service type information is available, I 
> see no harm in indicating the emergency service type 
> information to the UAC. I am not sure what "efficiency" is 
> gained by not indicating emergency service type information 
> using a few extra characters in a SIP message.

Dlb> There aren't any 3GPP requirements/procedures (or ecrit) for
emergency call handling, other than the ability to route to different
destinations, that alter handling based on a sub-service type (e.g., the
MMtel interaction procedures are just for emergency calls and callback -
nothing different depending on subservice type).  So I don't see the
need to define sub-service types for the sos parameter.  Do you agree?
:)

> > result of determining the call is routed to a CS PSAP.  The 
> > service-urn is preserved until the routing function determines the 
> > appropriate emergency center and only replaces the 
> service-urn because 
> > it had to be converted to a digits. If different 
> service-urns require 
> > different destinations, that would have been accounted for.  The 
> > single sos parameter should be sufficient for proper emergency call 
> > handling and the service-urn is available and sufficient 
> for correct routing.
> >
> >> Currently the draft only specifies that the "sos" parameter only 
> >> conveys information that the request/response is related to an 
> >> emergency session. But I do find your use case valid.
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of John-Luc Bakker
> >> The proposed new URI parameter is opaque. It marks the call as an 
> >> emergency call but fails to convey the emergency call type 
> even if an 
> >> emergency call type could be deduced from the original request.
> >> Particularly if the Emergency Service URN in the Request-URI is 
> >> replaced by a network entity, as you suggest, not loosing the 
> >> emergency call type information seems useful. In some deployments, 
> >> emergency calls are routed to PSAPs that support the requested 
> >> emergency types.
> >>
> >> Kind regards,
> >>
> >> John-Luc
> >>

---

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 23 Oct 2008 09:52:24 -0500

Hi Deb,

Thank you for your swift responses!
Similarly, see <JLB> below.

> PSAP which answers an outgoing emergency call".  Do you agree with this

<JLB>What is the case for not including the emergency type
information? A UE may handle PSAP call backs for different emergency
types differently. E.g. calls backs from a PSAP handling requests for
"animal-control" may get different treatment when another PSAP call
back is in progress.

> requiring an immediate response and should not be used for general

<JLB>I agree that "electricity" is not presently in the RFC however
the RFC does outline how the set of emergency types can be enhanced so
urn:service:sos.electricity may make it into the set with emergency
types at some point. Clearly, a solution needs to take into account
evolution of the set of emergency service types.

<JLB>Hypothetics aside, if the network determines that a call with
some digits in the R-URI is an emergency call and the network
determines that the request requests a certain emergency service type
(e.g. gas or poison or animal-control per RFC) then it would be useful
to indicate to the UAC what type of undetected emergency call was
made. A UAC may be configured differently for dealing with certain
emergency call types, e.g. a user request for privacy of location
information may or may not apply for certain emergency types.

<JLB>It is demonstrated that the network can deduce the emergency
service type from the dialed digits so not informing the UAC of that
bit of information seems unnecessary restrictive. I am not aware of
requirements that the emergency service type MUST not be indicated.
What is the case for not including emergency type information?

> need to define sub-service types for the sos parameter.  Do you agree?

<JLB>Recognizing emergency service types has more uses than "routing".
Including a subservice type is also useful if the local jurisdiction
doesn't recognize a call to e.g. "animal-control" as an emergency. For
example, because a PSAP and the rest of the infrastructure wasn't
designed for the increased load if such calls are required to receive
emergency call treatment. Having a discussion of whether or not to be
able to indicate subservice types using the sos parameter seems a
discussion in scope of the ECRIT list. Absence of the information may
have undesirable side effects as indicated above. I fail to see the
efficiency gain by not including it. AFAIK no case has been made for
not including it when the information is available.