Subject: [dispatch] FW: New Version Notification for draft-patel-ecrit-sos-parameter-11

From: "Patel, Milan" <[email-masked]>
Date: Tue, 9 Nov 2010 19:46:01 -0500

Hi,

The latest version of draft-patel-ecrit-sos-parameter is now available. The draft describes a mechanism to requests pertaining to emergency registration, which is a requirement in 3GPP IMS based emergency services since release 7. The mechanism allows a registrar to identify emergency registration requests and act accordingly to perform the necessary admission control to remove subscription related restrictions that might otherwise prevent successful initiation of an emergency call. 

In order to further progress this draft, please can you review the draft and provide any feedback to Robert and myself. Based upon your feedback, Robert will decide whether or not to AD sponsor the draft. 

Best regards,
Milan

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2010 11:34 AM
To: Patel, Milan
Subject: New Version Notification for draft-patel-ecrit-sos-parameter-11 

A new version of I-D, draft-patel-ecrit-sos-parameter-11.txt has been successfully submitted by Milan Patel and posted to the IETF repository.

Filename:	 draft-patel-ecrit-sos-parameter
Revision:	 11
Title:		 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services
Creation_date:	 2010-11-09
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
This document defines a new Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI) parameter intended for marking SIP
registration requests related to emergency calls and allow admission
control to ensure successful initiation of emergency calls.  The
usage of this new URI parameter complements the usage of the Service
Uniform Resource Name (URN) and is not intended to replace it.

The IETF Secretariat.

Milan Patel 
Consultant
InterDigital Communications, LLC

Tel.: +44 7917 678 250
Fax: 
Email: [email-masked]
http://www.InterDigital.com

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 09:49:05 +0800

I have a few questions about this:

- Is this intended to change the normative behavior of registrars as 
defined in 3261? (In most respects it might not - it may only be 
affecting behavior over and above normative behavior, such as 
authorization policy.)

- Is it intended that two contacts that differ only by the presence of 
the sos parameter may be concurrently registered? (I gather that is the 
intent, but am not certain.)

- Is it intended that the presence of the sos parameter in a contact 
enable the registration of that contact even in cases when the To-URI of 
the REGISTER request is not valid for the domain of the registrar?

Elaboration on the above:

3261 section 10.3 calls out the rules the registrar must follow. Its 
much better if you are not suggesting changes to those. If you are, then 
you really need to spell out in black and white what specific changes 
you want in those rules.

Note that the ordering of the steps in that section calls for 
determining if the domain and AOR are valid before considering any of 
the contacts. If you expect the presence of ;sos in one of the contacts 
to alter that it will make things much more complex.

Those rules also call for comparison of URIs in the REGISTER request 
with those previously registered using SIP URI comparison rules. The 
comparison rules will result in two URIs comparing equal if they differ 
only by the presence of the sos parameter.

	Thanks,
	Paul

On 11/10/2010 8:46 AM, Patel, Milan wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 21:21:21 -0500

Hi,
I've read the draft, and have some questions.  

1) I'm very sympathetic to the problem, but I have a weird question: what happens in "legacy" mobile phone cases? (CDMA/GSM/whatever)  I mean in the US, mobile phones without paid subscriptions can still make emergency calls.  Is their registration signal any different?

2) You use the word "AOR" multiple times, but you don't really mean it.  A Contact-URI is not (generally) an AoR. 

3) Section 4.3.1 says:
   The "sos" URI parameter SHALL be present in the Contact header in the
   200 (OK) response sent upon successful registration, thus indicating
   to the UA that this contact address will be included in the Contact
   header of an INVITE for emergency call initiation.
I don't understand this sentence.  Do you mean in the INVITE from the UA to the P-CSCF?  Why do you need to indicate this to the UA, when the UA is the one inserting it? (I'm confused)

4) You discus a couple times that the "sos" param is used in the Contact header for INVITE, "in case the service URN is removed by a network entity".  Do you mean the P-CSCF removing it from the request-URI?  Why don't you just use History-Info to look for it, then? (that is after all why we have it)

5) You says a few times that the sos param should be "appended to the Contact address".  It would be cleaner to say the 'sos' URI param is included in the Contact URI. (or Contact header field SIP URI)

6) For a call back from the PSAP, it's weird to apply different routing and policy behavior due to the 'sos' param in the *Contact header* of the INVITE, as opposed to being a param of the request-URI from the PSAP.  A Contact represents the SIP message generator's address and features and such - i.e., the properties of the originator of the request, not the properties of the destination of the request.  No?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 10:37:48 +0800

Hadriel's mail reminded me I forgot something in mine.
IIRC this draft says the sos parameter is only to appear in the Contact 
in REGISTER. That seems unworkable. Any subsequent call (e.g. callback) 
via the AOR will result in an R-URI that has the sos parameter.

I see no reason to restrict the places a URI with this param may appear.

	Thanks,
	Paul

---

From: "Patel, Milan" <[email-masked]>
Date: Wed, 10 Nov 2010 18:09:51 -0500

Hi Paul,

Thank you for your email and review of the draft. 
My responses are inline, below.
Best regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Wednesday, November 10, 2010 1:49 AM
To: [email-masked]
Subject: Re: [dispatch] FW: New Version Notificationfor
draft-patel-ecrit-sos-parameter-11

[Milan] the intention is not to change the normative behavior of
registrars either as specified in RFC 3261 or any deviation that 3GPP
may have taken. The URI parameter merely distinguishes REGISTER requests
that pertain to emergency registration and allow the registrar to apply
any overriding of subscription related restrictions in order to allow
the UA to successfully initiate emergency calls.

[milan] yes but does not preclude that the two contacts can be
different.

[Milan] registration in the emergency case, still occurs with a
registrar in the home domain of the subscriber, and thus any URI used in
the To must be valid in that domain in order to be valid. The emergency
registration only considers valid credentials in order to be successful.
Failure of emergency registration may result in not being able to route
an emergency call in the local network. If a UA does not have valid
credentials, or even an expired subscription, it might initiate an
unauthenticated (SIMless in the mobile case) emergency call. This is
described in 3GPP TS 23.167. 

	Thanks,
	Paul

On 11/10/2010 8:46 AM, Patel, Milan wrote:
> Hi,
>
> The latest version of draft-patel-ecrit-sos-parameter is now
available. The draft describes a mechanism to requests pertaining to
emergency registration, which is a requirement in 3GPP IMS based
emergency services since release 7. The mechanism allows a registrar to
identify emergency registration requests and act accordingly to perform
the necessary admission control to remove subscription related
restrictions that might otherwise prevent successful initiation of an
emergency call.
>
> In order to further progress this draft, please can you review the
draft and provide any feedback to Robert and myself. Based upon your
feedback, Robert will decide whether or not to AD sponsor the draft.
> A new version of I-D, draft-patel-ecrit-sos-parameter-11.txt has been
successfully submitted by Milan Patel and posted to the IETF repository.
> Title:		 SOS Uniform Resource Identifier (URI) Parameter
for Marking of Session Initiation Protocol (SIP) Requests related to
Emergency Services
> This e-mail is intended only for the use of the individual or entity
to which it is addressed, and may contain information that is
privileged, confidential and/or otherwise protected from disclosure to
anyone other than its intended recipient. Unintended transmission shall
not constitute waiver of any privilege or confidentiality obligation. If
you received this communication in error, please do not review, copy or
distribute it, notify me immediately by email, and delete the original
message and any attachments. Unless expressly stated in this e-mail,
nothing in this message or any attachment should be construed as a
digital or electronic signature.

Milan Patel 
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: "Patel, Milan" <[email-masked]>
Date: Wed, 10 Nov 2010 18:24:07 -0500

Hi Hadriel,

Thank you for reviewing the draft and for your feedback. I have provided
my responses inline below. 
Best regards,
Milan

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 2:21 AM
To: Patel, Milan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] FW: New Version Notification
fordraft-patel-ecrit-sos-parameter-11

Hi,

1) I'm very sympathetic to the problem, but I have a weird question:
what happens in "legacy" mobile phone cases? (CDMA/GSM/whatever)  I mean
in the US, mobile phones without paid subscriptions can still make
emergency calls.  Is their registration signal any different?

[Milan] without a valid subscription or valid credentials to facilitate
successful registration with a SIP registrar, the UA can fallback to
using unauthenticated emergency call procedures are described in 3GPP TS
23.167.

2) You use the word "AOR" multiple times, but you don't really mean it.
A Contact-URI is not (generally) an AoR. 

[Milan] will take that into account - thanks.

3) Section 4.3.1 says:
   The "sos" URI parameter SHALL be present in the Contact header in the
   200 (OK) response sent upon successful registration, thus indicating
   to the UA that this contact address will be included in the Contact
   header of an INVITE for emergency call initiation.
I don't understand this sentence.  Do you mean in the INVITE from the UA
to the P-CSCF?  Why do you need to indicate this to the UA, when the UA
is the one inserting it? (I'm confused)

[Milan] this text does not appear in the latest version. I believe I
have removed all text that goes beyond the registration procedures.

4) You discus a couple times that the "sos" param is used in the Contact
header for INVITE, "in case the service URN is removed by a network
entity".  Do you mean the P-CSCF removing it from the request-URI?  Why
don't you just use History-Info to look for it, then? (that is after all
why we have it)

[Milan] as above, I believe such text is now omitted from the draft and
it only concentrates on the registration procedures, in order to
distinguish emergency registration requests and to inform the registrar
to perform appropriate admission control to allow emergency calls to be
successfully initiated by a UA that has valid credentials to register
with its home network and be authenticated.

5) You says a few times that the sos param should be "appended to the
Contact address".  It would be cleaner to say the 'sos' URI param is
included in the Contact URI. (or Contact header field SIP URI)

[Milan] will take that into account - thanks

6) For a call back from the PSAP, it's weird to apply different routing
and policy behavior due to the 'sos' param in the *Contact header* of
the INVITE, as opposed to being a param of the request-URI from the
PSAP.  A Contact represents the SIP message generator's address and
features and such - i.e., the properties of the originator of the
request, not the properties of the destination of the request.  No?

[Milan] if the PSAP call back can be identified, then the call back
should be routed to the contact which was used to place the emergency
call. Thus in the IMS, the S-CSCF would replace the Request-URI with the
sos registered contact address. But this is also omitted from the draft.
Since call back was considered out of scope of the draft. 
 
-hadriel

 

Milan Patel 
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: "Patel, Milan" <[email-masked]>
Date: Wed, 10 Nov 2010 18:26:26 -0500

Hi Paul,

I will definitely take into consideration your comment below and will
discuss further with folks at 3GPP during the following week. 
Cheers,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Wednesday, November 10, 2010 2:38 AM
To: [email-masked]
Subject: Re: [dispatch] FW: New VersionNotification for
draft-patel-ecrit-sos-parameter-11

	Thanks,
	Paul

>
> 2) You use the word "AOR" multiple times, but you don't really mean
it.  A Contact-URI is not (generally) an AoR.
> I don't understand this sentence.  Do you mean in the INVITE from the
UA to the P-CSCF?  Why do you need to indicate this to the UA, when the
UA is the one inserting it? (I'm confused)
>
> 4) You discus a couple times that the "sos" param is used in the
Contact header for INVITE, "in case the service URN is removed by a
network entity".  Do you mean the P-CSCF removing it from the
request-URI?  Why don't you just use History-Info to look for it, then?
(that is after all why we have it)
>
> 6) For a call back from the PSAP, it's weird to apply different
routing and policy behavior due to the 'sos' param in the *Contact
header* of the INVITE, as opposed to being a param of the request-URI
from the PSAP.  A Contact represents the SIP message generator's address
and features and such - i.e., the properties of the originator of the
request, not the properties of the destination of the request.  No?

Milan Patel 
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2010 08:06:05 +0800

Milan,

You didn't comment on what I wrote below "Elaboration on the above". 
That is an important part because as currently written I think your 
approach does require normative changes in to 3261 regarding how the 
registrar functions.

	Thanks,
	Paul

---

From: "Patel, Milan" <[email-masked]>
Date: Thu, 11 Nov 2010 05:08:04 -0500

Hi Paul,

If the registrar had previously received a URI and then received the
same URI, but including the URI parameter within another REGISTER
request, the intention is that the old information is not overwritten in
the registrar. Does this conflict with 3261?
Cheers,
Milan

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 12:06 AM
To: Patel, Milan
Cc: [email-masked]
Subject: Re: [dispatch] FW: New Version Notificationfor

Milan,

	Thanks,
	Paul

 

Milan Patel 
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2010 23:13:22 +0800

> the registrar. Does this conflict with 3261?

Yes. Its all there in a straightforward way.

In 3261 section 10.3 bullet 7:

          For each address, the registrar then searches the list of
          current bindings using the URI comparison rules.  If the
          binding does not exist, it is tentatively added.  If the
          binding does exist, the registrar checks the Call-ID value.  If
          the Call-ID value in the existing binding differs from the
          Call-ID value in the request, the binding MUST be removed if
          the expiration time is zero and updated otherwise.  If they are
          the same, the registrar compares the CSeq value.  If the value
          is higher than that of the existing binding, it MUST update or
          remove the binding as above.  If not, the update MUST be
          aborted and the request fails.

Section 19.1.4 gives the SIP URI comparison rules. In there you will see:

       o  URI uri-parameter components are compared as follows:

          -  Any uri-parameter appearing in both URIs must match.

          -  A user, ttl, or method uri-parameter appearing in only one
             URI never matches, even if it contains the default value.

          -  A URI that includes an maddr parameter will not match a URI
             that contains no maddr parameter.

          -  All other uri-parameters appearing in only one URI are
             ignored when comparing the URIs.

Hence a new contact uri with an ;sos param will compare equal to a 
registered uri differing only by not having the ;sos parameters, so the 
new registration will replace the old one.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Nov 2010 09:44:37 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 10 November 2010 02:21
> To: Patel, Milan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dispatch] FW: New Version Notification for 
> 1) I'm very sympathetic to the problem, but I have a weird 
> question: what happens in "legacy" mobile phone cases? 
> (CDMA/GSM/whatever)  I mean in the US, mobile phones without 
> paid subscriptions can still make emergency calls.  Is their 
> registration signal any different?
> 
> 2) You use the word "AOR" multiple times, but you don't 
> really mean it.  A Contact-URI is not (generally) an AoR. 
> 
> 3) Section 4.3.1 says:
> I don't understand this sentence.  Do you mean in the INVITE 
> from the UA to the P-CSCF?  Why do you need to indicate this 
> to the UA, when the UA is the one inserting it? (I'm confused)
[JRE] In which URI is the "sos" URI parameter to be present? I believe the 200 response to REGISTER contains a list of all contact URIs currently registered for the AOR concerned. Presumably the parameter will be present only for those contact URIs where it is present, i.e., only for those generated by emergency registration, not for those generated by regular registration. In other words, no special behaviour is required - the 200 OK lists all contact URIs - some may contain the "sos" parameter, others won't.

John