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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Sep 2008 10:24:15 +0300

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.txt

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: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Sep 2008 07:20:02 -0400

I get emergency registration, but perhaps there is a better way to do it.

I don't get Req 2.  No network entity other than the PSAP should be deleting
the Route entry.

Req 3 is perverse.  The UE is not emergency aware, yet knows about the URI
parameter.  Perhaps you meant that it is emergency aware, but didn't
recognize the dialstring.  Redirect the call to urn:service:sos.

I don't understand Req 4.  The gateway has to have some mechanism to
recognize that the call is from the PSAP.  It's constructing a From/PAI.  It
can use the correct domain.

So, 3GPP needs a way to mark an emergency services registration.  It's
possible the URI parameter is the best way to do that.  I'll think about
that.

Hmmm.  Maybe I'll give you a 5th requirement.  An emergency call can be
transferred.  The result is an INVITE from the UE with a Referred-by, which
is the PSAP.  The urn:services:sos would not be in the ROUTE header, but
it's still an emergency call.  Hmmmm.  Lots of PSAPs won't REFER all the way
back to the caller.  They will use some form of B2BUA, but still, the RIGHT
way to do it is REFER.  Hmmmm.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
> Sent: Monday, September 15, 2008 3:24 AM
> To: 'ECRIT'
> Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt]
> 
> 	Title           : SOS Uniform Resource Identifier (URI) parameter
> for marking of Session Initiation Protocol (SIP) requests related to
> emergency services
> 	Author(s)       : M. Patel

---

From: "Milan Patel" <[email-masked]>
Date: Mon, 15 Sep 2008 18:01:29 +0100

Hi Brian,

I've added comments inline:

I get emergency registration, but perhaps there is a better way to do
it.

I don't get Req 2.  No network entity other than the PSAP should be
deleting
the Route entry.

[MILAN] The Route header entry of the PSAP is inserted by the E-CSCF (in
the case of an IP-based PSAP). In the case of a PSTN based PSAP, the
address of the BGCF is added in the Route header, and the PSAP address
is added to the Request URI. Prior to the request reaching the E-CSCF,
the PSAP address is not available in the SIP headers of the INVITE
request.

Req 3 is perverse.  The UE is not emergency aware, yet knows about the
URI
parameter.  Perhaps you meant that it is emergency aware, but didn't
recognize the dialstring.  Redirect the call to urn:service:sos.

[MILAN] UE may be emergency capable, but is emergency unaware since it
doesn't recognize the dialled digits (emergency number plan of the
roamed-to region is not available in the UE) - thus is unaware an
emergency call is dialled. The P-CSCF would then add the appropriate
service URN if network policy is to proceed with the emergency call.
UE recognizes the dialled digits as an emergency call but does not have
an appropriate service URN to add to the Request URI i.e. lifeboat
service. Thus UE adds dialstring to the Request-URI and the network will
add the appropriate service URN (may result in default urn:service:sos
being applied). A backwards indication in these cases would allow the UE
to explicitly be aware that it is involved in an emergency call. 

I don't understand Req 4.  The gateway has to have some mechanism to
recognize that the call is from the PSAP.  It's constructing a From/PAI.
It
can use the correct domain.

[MILAN] In this case, the From/PAI would be a tel-URI. An explicit
marking of the call back aids special handling (network service
suppression).

Hmmm.  Maybe I'll give you a 5th requirement.  An emergency call can be
transferred.  The result is an INVITE from the UE with a Referred-by,
which
is the PSAP.  The urn:services:sos would not be in the ROUTE header, but
it's still an emergency call.  Hmmmm.  Lots of PSAPs won't REFER all the
way
back to the caller.  They will use some form of B2BUA, but still, the
RIGHT
way to do it is REFER.  Hmmmm.

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: 15 September 2008 12:20
To: 'Hannes Tschofenig'; 'ECRIT'
Subject: Re: [Ecrit] [Fwd: I-D
Action:draft-patel-ecrit-sos-parameter-00.txt]

I get emergency registration, but perhaps there is a better way to do
it.

I don't get Req 2.  No network entity other than the PSAP should be
deleting
the Route entry.

Req 3 is perverse.  The UE is not emergency aware, yet knows about the
URI
parameter.  Perhaps you meant that it is emergency aware, but didn't
recognize the dialstring.  Redirect the call to urn:service:sos.

I don't understand Req 4.  The gateway has to have some mechanism to
recognize that the call is from the PSAP.  It's constructing a From/PAI.
It
can use the correct domain.

Hmmm.  Maybe I'll give you a 5th requirement.  An emergency call can be
transferred.  The result is an INVITE from the UE with a Referred-by,
which
is the PSAP.  The urn:services:sos would not be in the ROUTE header, but
it's still an emergency call.  Hmmmm.  Lots of PSAPs won't REFER all the
way
back to the caller.  They will use some form of B2BUA, but still, the
RIGHT
way to do it is REFER.  Hmmmm.

Brian

> Subject: [Ecrit] [Fwd: I-D
Action:draft-patel-ecrit-sos-parameter-00.txt]
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t
xt

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 Sep 2008 15:41:35 -0400

I'm still not getting Req 2.  Is the problem that the call has to be marked
before the E-CSCF or is it that some entity between the E-CSCF and the PSAP
deletes it?  In the case of a PSTN connected PSAP, the BGCF is the last SIP
element; the call doesn't pass it as SIP.  So as long as the Route entry is
on when the call gets to the BGCF it should be okay.

I'm also not understanding the problem in 3.  If the UE recognizes the
dialstring, then it should have the service URN.  What am I missing?
If it doesn't recognize the dialstring then the network does and redirects
the call to the proper service.

I claim that if the gateway is recognizing that the call back is from the
PSAP so that special marking is appropriate, then it can use the domain
concept as well as anything else.  I don't think having another mechanism is
warranted.  I'm not really opposed to having some kind of marking of call
backs, but I don't think it's absolutely necessary.

> From: Milan Patel [mailto:[email-masked]]
> Sent: Monday, September 15, 2008 1:01 PM
> To: Brian Rosen; ECRIT
> Subject: RE: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-
> 00.txt]
> 
> Hi Brian,
> 
> Of