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

From: "John-Luc Bakker" <[email-masked]>
Date: Fri, 3 Oct 2008 09:31:57 -0400

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.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
>
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Milan Patel" <[email-masked]>
Date: Fri, 3 Oct 2008 14:45:08 +0100

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,

Kind regards,

John-Luc

On Mon, Sep 15, 2008 at 3:24 AM, Hannes Tschofenig
<[email-masked]> wrote:
>        Title           : SOS Uniform Resource Identifier (URI)
parameter for marking of Session Initiation Protocol (SIP) requests
related to emergency services
> 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: Fri, 3 Oct 2008 11:14:56 -0400

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: [email-masked] [mailto:[email-masked]] 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, 

Best regards,
Milan

-----Original Message-----

Milan,

Kind regards,

John-Luc

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 27 Oct 2008 11:00:27 -0700

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.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Friday, October 03, 2008 8:15 AM
> To: 'Milan Patel'; 'John-Luc Bakker'; 'ECRIT'
> 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 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Milan Patel
> 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
> 
> 
> 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
> 
> parameter for marking of Session Initiation Protocol (SIP) 
> requests related to emergency services
> >        Author(s)       : M. Patel
> > emergency services solutions.  It is not intended as a 
> replacement for 
> > the service URN.
> >

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Milan Patel" <[email-masked]>
Date: Mon, 27 Oct 2008 18:22:58 -0000

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: [email-masked] [mailto:[email-masked]] 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]

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

-roger marshall.

> Of Brian Rosen
> 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.
> 

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

> Of Milan Patel
> 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
> 
> 

> > implementation to automatically retrieve the ASCII version of the 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "John-Luc Bakker" <[email-masked]>
Date: Mon, 27 Oct 2008 14:23:09 -0500

Milan,

I fail to see how the opaque parameter's description would expedite
matters more when compared to a description that includes type of
service information.
I fail to see how excluding the type of service information would
impede expedience.

I would very much like to see you include a few lines on type of
service information given the usefullness expressed, lack of
additional complexity, and lack of decreased efficiency.

Regards,

John-Luc

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Oct 2008 14:56:31 -0700

I think it would be useful to have a working group discussion of this
draft in Minneapolis, and maybe even some time prior to that for
informal discussion.  A couple of process questions:

Since this is a SIP URI parameter, it is governed by 3969.  That
means this must be in a standards-track RFC.  Is it also governed
by a SIP change process the means SIP has to bless it?

If so, has it been seen by SIP and discussed there?  Can I assume
it should be discussed in parallel, if this is required, given the
timelines Milan has put forward?

On the technical front, I'm not sure I yet understand what
John-Luc is suggesting.  Is there a set off diffs or a proposed addition
that we can point to?  (RFC Editor note style, for example)

As a suggestion for content for the presentation, can I ask that
Milan write up a brief summary of the other methods that were
considered and rejected here, along with the reasoning?  I have
the suspicion that we could play "name your favorite alternate 
method" for some time on this one, and short-cutting that with
pointers to discussions that have already completed might help.

		regards,
				Ted

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Oct 2008 15:47:24 -0700

>  others to weigh in on making this a wg item.

It sounds like the WG does need a WG item to address the requirements.

(I haven't had a chance to thoroughly read this particular draft, so 
I don't have an opinion as to if this specific draft should be the 
basis for the WG draft.)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Finagle's Second Law:
    No matter what the anticipated result, there will always be
    someone eager to (a) misinterpret it, (b) fake it, or (c)
    believe it happened according to his own pet theory.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 29 Oct 2008 17:45:52 +0100

RFC 3969 defines:

3.  Use of the Registry

   SIP and SIPS URI parameters and values for these parameters MUST be
   documented in a standards-track RFC in order to be registered by
   IANA.  This documentation MUST fully explain the syntax, intended
   usage, and semantics of the parameter.  The intent of this
   requirement is to assure interoperability between independent
   implementations, and to prevent accidental namespace collisions
   between implementations of dissimilar features.

4.2.  Registration Policy for SIP and SIPS URI Parameters

   As per the terminology in RFC 2434 [4], the registration policy for
   SIP and SIPS URI parameters shall be "Specification Required".

   For the purposes of this registry, the parameter for which IANA
   registration is requested MUST be defined by a standards-track RFC.

http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-00 defines:

   RFC3969 [4] stipulates that the (original) RFC2434 rule of
   "Specification Required" applies to registrations of new SIP URI
   parameters; however Section 3 of that same document mandates that a
   standards action is required to register new parameters with the
   IANA.  This contradiction arose from a misunderstanding of the nature
   of the RFC2434 categories; the intention was for the IANA
   Considerations to mandate that Standards Action is required.

A standards track RFC must be done by a group that is chartered to do
it, or be AD sponsored - that does not mean it has to be the SIP group
unless we establish such a policy.

Regards

Keith 

> On Behalf Of Ted Hardie
> Sent: Tuesday, October 28, 2008 9:57 PM
> To: John-Luc Bakker; Milan Patel
> Cc: ECRIT
>  I think it would be useful to have a working group 
> discussion of this draft in Minneapolis, and maybe even some 
> time prior to that for informal discussion.  A couple of 
> process questions:
> 
> Since this is a SIP URI parameter, it is governed by 3969.  
> That means this must be in a standards-track RFC.  Is it also 
> governed by a SIP change process the means SIP has to bless it?
> 
> If so, has it been seen by SIP and discussed there?  Can I 
> assume it should be discussed in parallel, if this is 
> required, given the timelines Milan has put forward?
> 
> John-Luc is suggesting.  Is there a set off diffs or a 
> proposed addition that we can point to?  (RFC Editor note 
> style, for example)
> 
> As a suggestion for content for the presentation, can I ask 
> that Milan write up a brief summary of the other methods that 
> were considered and rejected here, along with the reasoning?  
> I have the suspicion that we could play "name your favorite 
> alternate method" for some time on this one, and 
> short-cutting that with pointers to discussions that have 
> already completed might help.
> 
> 		regards,
> 				Ted

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 30 Oct 2008 12:40:00 +0200

I also believe that we should tackle this work in ECRIT. 

I do have some comments on the details of the draft. I will provide them
in a separate mail. 

Ciao
Hannes

>On Behalf Of ext Roger Marshall
>Sent: 27 October, 2008 20:00
>To: ECRIT
>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.
>
>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.
>
>After that, we can work out the exact approach.  I would 
>encourage others to weigh in on making this a wg item.
>
>-roger marshall.
>
>On Behalf 
>far as it 
>before, I'm 
>not get put 
>"recognize the 
>On Behalf 
>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.