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

[Hannes Tschofenig]

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: Internet-Drafts@...
Reply-To: internet-drafts@...
To: i-d-announce@...



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
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Brian Rosen]

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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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]
>
> 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: Internet-Drafts@...
> Reply-To: internet-drafts@...
> To: i-d-announce@...
>
>
>
> 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
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Milan Patel]

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

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.

Regards,
Milan




-----Original Message-----
From: ecrit-bounces@... [mailto:ecrit-bounces@...] 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.

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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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]

>
> 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: Internet-Drafts@...
> Reply-To: internet-drafts@...
> To: i-d-announce@...
>
>
>
> 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
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Brian Rosen]

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.

> -----Original Message-----
> From: Milan Patel [mailto:milanpa@...]
> 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,
>
> 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).
>
> 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.
>
> Regards,
> Milan
>
>
>
>
> -----Original Message-----
> From: ecrit-bounces@... [mailto:ecrit-bounces@...] 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.
>
> 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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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]
> >
> > 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: Internet-Drafts@...
> > Reply-To: internet-drafts@...
> > To: i-d-announce@...
> >
> >
> >
> > 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
> > Ecrit@...
> > https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[John-Luc Bakker]

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
<Hannes.Tschofenig@...> 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:   Internet-Drafts@...
> Reply-To:       internet-drafts@...
> To:     i-d-announce@...
>
>
>
> 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
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Milan Patel]

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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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
<Hannes.Tschofenig@...> 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:   Internet-Drafts@...
> Reply-To:       internet-drafts@...
> To:     i-d-announce@...
>
>
>
> 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
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Brian Rosen]

I am still opposed to this mechanism.

There seems to be four threads here:
1. Marking an emergency registration
2. Keeping the Route header with the sos urn on the call as far as it needs
to go
3. Making the UA aware of an emergency call when it didn't recognize that
itself
4. Marking a call back

I recognize a need to mark an emergency registration.  As before, I'm not
convinced this is the best solution, but there is a problem that needs to be
solved.

I see no reason why the Route header with the sos urn does not get put on
the call as soon as it is recognized, and remain on the call until it gets
to the last SIP hop (a gateway in the case that is being discussed, a PSAP
if the call is terminated in PS).  Leave the Route header on, and use that
as the marking.

The UA should recognize the emergency call.  If you are planning a system
where you know it won't, fix that.  Having a backup mechanism is okay.  The
way to alert the UA is to redirect the call to urn:service:sos.  Then the UA
knows it's an emergency call.

Call backs have not yet really been addressed well, but "recognize the
domain" works.  It works for everyone: it works for the gateway, it works
for a proxy, it works for the UA if the UA knows it was an emergency call.
I will say that I would prefer a more specific marking for a call back.  I'd
prefer to have a comprehensive discussion of call backs and make sure we
have all the parts dealt with.  I will say this: there are two kinds of call
backs.  One is immediate, when a call is lost, or while the call is being
handled more information is needed.  The address used for that is the
Contact, not the AoR.  The latter is a follow up call placed later, and does
use AoR (or P-A-I).  The former needs marking, the latter doesn't.  It may
be that we make that the URI in Contact is distinguished in some way that
lets us know that this is a call back of an emergency call.

Brian

-----Original Message-----
From: ecrit-bounces@... [mailto:ecrit-bounces@...] On Behalf Of
Milan Patel
Sent: Friday, October 03, 2008 9:45 AM
To: John-Luc Bakker; ECRIT
Subject: Re: [Ecrit] [Fwd: I-D
Action:draft-patel-ecrit-sos-parameter-00.txt]

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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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
<Hannes.Tschofenig@...> 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:   Internet-Drafts@...
> Reply-To:       internet-drafts@...
> To:     i-d-announce@...
>
>
>
> 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
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Roger Marshall]

My understanding, based on Milan's 3GPP status at last week's 5th
Emergency Services Workshop, is that 3GPP is open to adopting some IETF
solution for call marking, so far has none, and that the window to
finalize solutions for their the requirements is closing.  It seemed
that the message at the workshop was that 3GPP will either use an IETF
mechanism - or create one of their own.

I think that Brian has captured 4 topics that this draft (and list
discussion) is targeting:
1. Marking emergency call registration
2. Keeping the Route header containing an SOS URN to the end
3. Tagging the UA as an emergency call
4. Marking a call back for specific call treatment

Regardless of whether all of these issues are adequately handled in this
early draft (likely not yet), what does seem to be clear is that 3GPP
has additional requirements not currently met by the existing marking
mechanism.

I would like to see this draft be turned into a working group item.
After that, we can work out the exact approach.  I would encourage
others to weigh in on making this a wg item.

-roger marshall.

> -----Original Message-----
> From: ecrit-bounces@... [mailto:ecrit-bounces@...]
> On Behalf Of Brian Rosen
> Sent: Friday, October 03, 2008 8:15 AM
> To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT'
> Subject: Re: [Ecrit] [Fwd: I-D
> Action:draft-patel-ecrit-sos-parameter-00.txt]
>
> I am still opposed to this mechanism.
>
> There seems to be four threads here:
> 1. Marking an emergency registration
> 2. Keeping the Route header with the sos urn on the call as
> far as it needs to go 3. Making the UA aware of an emergency
> call when it didn't recognize that itself 4. Marking a call back
>
> I recognize a need to mark an emergency registration.  As
> before, I'm not convinced this is the best solution, but
> there is a problem that needs to be solved.
>
> I see no reason why the Route header with the sos urn does
> not get put on the call as soon as it is recognized, and
> remain on the call until it gets to the last SIP hop (a
> gateway in the case that is being discussed, a PSAP if the
> call is terminated in PS).  Leave the Route header on, and
> use that as the marking.
>
> The UA should recognize the emergency call.  If you are
> planning a system where you know it won't, fix that.  Having
> a backup mechanism is okay.  The way to alert the UA is to
> redirect the call to urn:service:sos.  Then the UA knows it's
> an emergency call.
>
> Call backs have not yet really been addressed well, but
> "recognize the domain" works.  It works for everyone: it
> works for the gateway, it works for a proxy, it works for the
> UA if the UA knows it was an emergency call.
> I will say that I would prefer a more specific marking for a
> call back.  I'd prefer to have a comprehensive discussion of
> call backs and make sure we have all the parts dealt with.  I
> will say this: there are two kinds of call backs.  One is
> immediate, when a call is lost, or while the call is being
> handled more information is needed.  The address used for
> that is the Contact, not the AoR.  The latter is a follow up
> call placed later, and does use AoR (or P-A-I).  The former
> needs marking, the latter doesn't.  It may be that we make
> that the URI in Contact is distinguished in some way that
> lets us know that this is a call back of an emergency call.
>
> Brian
>
> -----Original Message-----
> From: ecrit-bounces@... [mailto:ecrit-bounces@...]
> On Behalf Of Milan Patel
> Sent: Friday, October 03, 2008 9:45 AM
> To: John-Luc Bakker; ECRIT
> Subject: Re: [Ecrit] [Fwd: I-D
> Action:draft-patel-ecrit-sos-parameter-00.txt]
>
> 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: ecrit-bounces@... [mailto:ecrit-bounces@...]
> 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
> <Hannes.Tschofenig@...> 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:   Internet-Drafts@...
> > Reply-To:       internet-drafts@...
> > To:     i-d-announce@...
> >
> >
> >
> > 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-para
> meter-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
> > Ecrit@...
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit

[Milan Patel]

Thanks for the support Roger.
Indeed, I failed to express the urgency of 3GPP to have a solution
defined before the end of the year. I believe if we keep the proposed
parameter simple as described by Deborah, progress can be achieved more
quickly. I have had offline discussions with Brian on his previous
comments and he has suggested some alternative methods of solving the
four topics of the draft. These may be proposed as an alternative
solution for the forthcoming 3GPP meetings. I will upload a -01 version
of the draft based upon the current status of 3GPP requirements but in
the mean time appreciate the comments received.

Regards,
Milan  

-----Original Message-----
From: ecrit-bounces@... [mailto:ecrit-bounces@...] On Behalf
Of Roger Marshall
Sent: 27 October 2008 18:00
To: ECRIT
Subject: Re: [Ecrit] [Fwd: I-D
Action:draft-patel-ecrit-sos-parameter-00.txt]

My understanding, based on Milan's 3GPP status at last week's 5th
Emergency Services Workshop, is that 3GPP is open to adopting some IETF
solution for call marking, so far has none, and that the window to
finalize solutions for their the requirements is closing.  It seemed
that the message at the workshop was that 3GPP will either use an IETF
mechanism - or create one of their own.

I think that Brian has captured 4 topics that this draft (and list
discussion) is targeting:
1. Marking emergency call registration
2. Keeping the Route header containing an SOS URN to the end 3. Tagging
the UA as an emergency call 4. Marking a call back for specific call
treatment

Regardless of whether all of these issues are adequately handled in this
early draft (likely not yet), what does seem to be clear is that 3GPP
has additional requirements not currently met by the existing marking
mechanism.

I would like to see this draft be turned into a working group item.
After that, we can work out the exact approach.  I would encourage
others to weigh in on making this a wg item.

-roger marshall.

> -----Original Message-----
> From: ecrit-bounces@... [mailto:ecrit-bounces@...] On Behalf

> Of Brian Rosen
> Sent: Friday, October 03, 2008 8:15 AM
> To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT'
> Subject: Re: [Ecrit] [Fwd: I-D
> Action:draft-patel-ecrit-sos-parameter-00.txt]
>
> I am still opposed to this mechanism.
>
> There seems to be four threads here:
> 1. Marking an emergency registration
> 2. Keeping the Route header with the sos urn on the call as far as it
> needs to go 3. Making the UA aware of an emergency call when it didn't

> recognize that itself 4. Marking a call back
>
> I recognize a need to mark an emergency registration.  As before, I'm
> not convinced this is the best solution, but there is a problem that
> needs to be solved.
>
> I see no reason why the Route header with the sos urn does not get put

> on the call as soon as it is recognized, and remain on the call until
> it gets to the last SIP hop (a gateway in the case that is being
> discussed, a PSAP if the call is terminated in PS).  Leave the Route
> header on, and use that as the marking.
>
> The UA should recognize the emergency call.  If you are planning a
> system where you know it won't, fix that.  Having a backup mechanism
> is okay.  The way to alert the UA is to redirect the call to
> urn:service:sos.  Then the UA knows it's an emergency call.
>
> Call backs have not yet really been addressed well, but "recognize the

> domain" works.  It works for everyone: it works for the gateway, it
> works for a proxy, it works for the UA if the UA knows it was an
> emergency call.
> I will say that I would prefer a more specific marking for a call
> back.  I'd prefer to have a comprehensive discussion of call backs and

> make sure we have all the parts dealt with.  I will say this: there
> are two kinds of call backs.  One is immediate, when a call is lost,
> or while the call is being handled more information is needed.  The
> address used for that is the Contact, not the AoR.  The latter is a
> follow up call placed later, and does use AoR (or P-A-I).  The former
> needs marking, the latter doesn't.  It may be that we make that the
> URI in Contact is distinguished in some way that lets us know that
> this is a call back of an emergency call.
>
> Brian
>
> -----Original Message-----
> From: ecrit-bounces@... [mailto:ecrit-bounces@...] On Behalf

> Of Milan Patel
> Sent: Friday, October 03, 2008 9:45 AM
> To: John-Luc Bakker; ECRIT
> Subject: Re: [Ecrit] [Fwd: I-D
> Action:draft-patel-ecrit-sos-parameter-00.txt]
>
> 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: ecrit-bounces@... [mailto:ecrit-bounces@...] 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
> <Hannes.Tschofenig@...> 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:   Internet-Drafts@...
> > Reply-To:       internet-drafts@...
> > To:     i-d-announce@...
> >
> >
> >
> > 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-para
> meter-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
> > Ecrit@...
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@...
> https://www.ietf.org/mailman/listinfo/ecrit
>

CONFIDENTIALITY NOTICE: The information contained in this message may be
privileged and/or confidential. If you are not the intended recipient,
or responsible for delivering this message to the intended recipient,
any review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please notify the sender immediately,
and delete it and all attachments from your computer and network.
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@...
https://www.ietf.org/mailman/listinfo/ecrit