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

[Paul Kyzivat <[e-mail]>]

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

On 11/10/2010 10:21 AM, Hadriel Kaplan wrote:
>
> 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
>
>
> On Nov 9, 2010, at 7:46 PM, 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.
>>
>> Best regards,
>> Milan
>>
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[e-mail]]
>> 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.: [phone]
>> Fax:
>> Email: [e-mail]
>> 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.
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>