Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt

["DRAGE, Keith (Keith)" <[e-mail]>]

I would like to support Milan's reasoning here.

I do not believe use of an option-tag helps.

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Milan Patel
> Sent: Thursday, May 07, 2009 11:44 AM
> To: Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo
> Cc: [e-mail]
> Subject: Re: [Ecrit] Expert review of
> draft-patel-ecrit-sos-parameter-03.txt
>
> Hi John-Luc,
>
> Firstly, it is my understanding that emergency registration
> occurs when the emergency call request is detected by the UE
> (e.g. user dials 911).
> The duration of this emergency registration is also not
> specified to be the same as that of a normal registration.
>
> Secondly, if the registrar were to reject the emergency
> registration because it did not support the "sos" URI
> parameter, and no other registration existed, the UE would
> have to initiate an unauthenticated emergency call. Surely,
> it would make more sense to either register the user, even if
> it means overriding an existing non-emergency registration or
> if using 3GPP IMS, the network can return a 380 response to
> the UE, forcing it to use for example the CS domain.
>
> Upon receiving the 420 response, if the UAC attempts
> registration again, then this registration would be treated
> as a non-emergency registration.
> This is the same result as ignoring the URI parameter if the
> registrar did not support it.
>
> Therefore, I still think the current procedures are sufficient.
>
> Regards,
> Milan
>
> Milan Patel
> Carrier Networks Core Standards
> Nortel
> [e-mail]
> Telephone [phone] / ESN 560 2381 Mobile [phone]
> 9261 / ESN 748 9261
>
> For the Companies listed below, The Institute of Chartered
> Accountants in England and Wales authorises A R Bloom, S
> Harris and C Hill to act as Insolvency Practitioners under
> section 390(2)(a) of the Insolvency Act
> 1986 and the Association of Chartered Certified Accountants
> authorises A M Hudson to act as an Insolvency Practitioner
> under section 390(2)(a) of the Insolvency Act 1986.
>
> The affairs, business and property of the Companies are being
> managed by the Joint Administrators, A R Bloom, S Harris, AM
> Hudson and C Hill who act as agents of the Companies only and
> without personal liability.
>
> The Companies are Nortel Networks UK Limited; Nortel Networks
> SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks
> NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks
> Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks
> (Austria) GmbH; Nortel Networks sro; Nortel Networks
> Engineering Service Kft; Nortel Networks Portugal SA; Nortel
> Networks Slovensko sro; Nortel Networks Oy; Nortel Networks
> Romania SRL; Nortel Networks AB; Nortel Networks
> International Finance & Holding BV
>
> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: 07 May 2009 06:05
> To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo
> Cc: [e-mail]
> Subject: RE: [Ecrit] Expert review of
> draft-patel-ecrit-sos-parameter-03.txt
>
>
> Hi,
>
> My comments between the <christer> and </christer> tags.
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of John-Luc Bakker
> > Sent: 7. toukokuuta 2009 6:08
> > To: Milan Patel; Gonzalo Camarillo
> > Cc: [e-mail]
> > Subject: Re: [Ecrit] Expert review of
> > draft-patel-ecrit-sos-parameter-03.txt
> >
> > Hi Milan,
> >
> > I would like to pick up on Gonzalo's comment below:
> >
> > > The document does not talk about backwards compatibility.
> > What happens
> > > if the registrar does not understand the 'sos' parameter?
> > Will it do
> > > the right thing? Will the UAC detect the failure? Is there
> > a need to
> > > define an option tag?... the document should address these points.
> >
> > In the meanwhile, the document does talk about backwards
> > compatibility.
> >
> > However, the legacy registrar will do the only (right) thing
> > it can do but from a perspective of the UE that might not be
> > the anticipated
> > (right) thing.
> >
> > It is my understanding that an emergency registration can
> > happen at any time and a UE is not required to immediately
> > follow up the successful registration with an emergency call
> > or tear down the emergency registration after the emergency call.
> >
> > Suppose a UAC has one public user identity and it performs a
> > normal registration with some feature tags. Subsequently, the
> > same UAC performs an emergency registration with different
> > feature tags. Would the legacy registrar "refresh" the
> > binding, then the S-CSCF would apply "emergency"
> > feature tags to all session requests.
> >
> > An option tag would prevent this.
> >
> > If in agreement, I suggest the following changes to the draft
> > (between <new> and </new> tags):
> >
> > 4.1.  REGISTER Request
> >
> >    When the UA sends a REGISTER request for emergency
> > registration, the
> >    "sos" URI parameter MUST be appended to the URI in the Contact
> >    Header<new> and the option-tag "e-reg" must be included in
> > the Proxy-Require and Require header</new>.  This serves as
> > an indication to the
> >    registrar that the
> >    request is for emergency registration<new> and it is only
> > accepted if emergency registration is supported</new>.
> >
> >    Example:
> >
> >    Contact: "Alice" <sip:[e-mail];sos> ;q=0.7; expires=3600
> >
> >    In the event that more than one Contact header field is
> included in
> >    the REGISTER request, only the contact addresses that include the
> >    "sos" URI parameter shall be considered as emergency registered
> >    contact addresses.
> >
> > <new>
> > Upon receipt of a 420 (Bad Extension) response the UAC will
> > use an existing registration or initiate another registration.
> > </new>
>
> <christer>
> Why would you need to insert the option-tag in the
> Proxy-Require header)
> Why do you need intermediates to support the "sos" parameter? Isn't it
> enough if the registrar, which in this case acts as UAS (and therefor
> applies the Require header) support the "sos" parameter?
> </christer>
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> > 4.3.  Backwards compatibility issues
> >
> >    The backwards compatibility scenario considered in this
> document is
> >    where a legacy registrar does not support the "sos" URI
> parameter.
> >
> > <new>
> > This document registers an option tag with IANA in section 6.2.
> > Inclusion of the option tag will prevent a legacy registrar
> > from handling the request.
> > </new>
> >
> > 6.  IANA Considerations
> > <new>
> > 6.2  SIP URI parameter
> > </new>
> >    This specification defines one new SIP URI parameter, as per the
> >    registry created by RFC 3969 [RFC3969]
> >
> >    Parameter Name: sos
> >
> >    Predefined Values: none
> >
> >    Reference: [RFCXXXX]
> >
> >    [NOTE TO IANA: Please replace XXXX with the RFC number of this
> >    specification.]
> > <new>
> > 6.2  SIP Option Tag
> >
> > This specification registers a new SIP option tag, as per the
> > guidelines in Section 27.1 of RFC 3261 [RFC3261].
> >
> > Name:  e-reg
> >
> > Description:  This option tag is used to identify the
> > emergency registration extension.  When used in a Supported
> > header, it indicates that a User Agent understands the
> > extension.  When used in a Require header field of a REGISTER
> > request, it indicates that the registrar is not expected to
> > process the registration unless it supports the emergency
> > registration extension.
> > </new>
> >
> > Regards,
> >
> >     John-Luc
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Milan Patel
> > Sent: Tuesday, April 28, 2009 8:36 AM
> > To: Gonzalo Camarillo
> > Cc: [e-mail]
> > Subject: Re: [Ecrit] Expert review of
> > draft-patel-ecrit-sos-parameter-03.txt
> >
> > Hi Gonzalo,
> >
> > Version 4 of draft-patel-ecrit-sos-parameter addresses all
> > the comments you provided in the expert review. Please can
> > you confirm that you are OK with its contents and that all
> > the issues you had previously highlighted are now resolved.
> > http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-04
> > Best regards,
> > Milan
> >
> > Milan Patel
> > Carrier Networks Core Standards
> > Nortel
> > [e-mail]
> > Telephone [phone] / ESN 560 2381 Mobile [phone]
> > 9261 / ESN 748 9261
> >
> > For the Companies listed below, The Institute of Chartered
> > Accountants in England and Wales authorises A R Bloom, S
> > Harris and C Hill to act as Insolvency Practitioners under
> > section 390(2)(a) of the Insolvency Act
> > 1986 and the Association of Chartered Certified Accountants
> > authorises A M Hudson to act as an Insolvency Practitioner
> > under section 390(2)(a) of the Insolvency Act 1986.
> >
> > The affairs, business and property of the Companies are being
> > managed by the Joint Administrators, A R Bloom, S Harris, AM
> > Hudson and C Hill who act as agents of the Companies only and
> > without personal liability.
> >
> > The Companies are Nortel Networks UK Limited; Nortel Networks
> > SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks
> > NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks
> > Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks
> > (Austria) GmbH; Nortel Networks sro; Nortel Networks
> > Engineering Service Kft; Nortel Networks Portugal SA; Nortel
> > Networks Slovensko sro; Nortel Networks Oy; Nortel Networks
> > Romania SRL; Nortel Networks AB; Nortel Networks
> > International Finance & Holding BV
> >
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[e-mail]]
> > Sent: 09 March 2009 10:32
> > To: Patel, Milan (MOP:EP10)
> > Cc: [e-mail]; Hannes Tschofenig
> > Subject: Re: [Ecrit] Expert review of
> > draft-patel-ecrit-sos-parameter-03.txt
> >
> > Hi,
> >
> > the problem with this text is that it specifies behavior for
> > entities that will not implement this specification. The new
> > section should describe how a legacy registrar will handle,
> > following regular SIP rules, a REGISTER request with the sos
> > parameter. However, it cannot specify extra behavior for such
> > a legacy registrar. That is the whole point of backwards
> > compatibility: to support unchanged legacy applications that
> > will not implement the new functionality.
> >
> > In any case, I believe you can use most of the text you
> > proposed below.
> > It just needs to be rephrased so that it is more descriptive
> > and non normative.
> >
> > Thanks,
> >
> > Gonzalo
> >
> > Milan Patel wrote:
> > > Folks,
> > >
> > > In response to Gonzalo's comment on backwards
> > compatibility, I propose
> >
> > > a subclause "4.3 Backwards compatibility issues" as follows:
> > >
> > >
> >
> ----------------------------------------------------------------------
> > > --
> > > ----------------------------------
> > > 4.3       Backwards compatibility issues
> > > The backwards compatibility scenario considered in this
> document is
> > > where the registrar does not support the "sos" URI
> > parameter. In this
> > > case, if the registrar receives a REGISTER request that
> > includes the
> > > "sos" URI parameter in the Contact header, the registrar
> > MUST proceed
> > > with registration procedures and silently ignore the
> > URI-parameter in
> > > accordance with RFC 3261. This ensures the user is
> > registered and thus
> >
> > > can successfully initiate an emergency call.
> > >
> > > The drawback of proceeding with registration is if the
> > > address-of-record is barred or has roaming restrictions
> > applied, then
> > > these restrictions will not be lifted and thus
> registration will be
> > > unsuccessful. This may limit the UAC's ability to
> successfully place
> > an emergency call.
> > >
> > > If registration is successful, the registrar shall return a
> > 200 (OK)
> > > response to the UAC and does not include the "sos" URI
> parameter in
> > > the Contact header. The UAC is aware of its registered
> > contact address
> >
> > > and address-of-record, however, cannot distinguish between this
> > > registration and a non-emergency registration.
> > >
> >
> ----------------------------------------------------------------------
> > > --
> > > --------------------------------------
> > >
> > > Comments/feedback/suggestions for improvement are
> > appreciated. I will
> > > address Gonzalo's other comments in version -04 of the
> > draft as well.
> > >
> > > Best regards,
> > > Milan
> > >
> > > Milan Patel
> > > Carrier Networks Core Standards
> > > Nortel
> > > [e-mail]
> > > Telephone [phone] / ESN 560 2381 Mobile +44 774
> 053 9261 /
> > > ESN 748 9261
> > >
> > > For the Companies listed below, The Institute of Chartered
> > Accountants
> >
> > > in England and Wales authorises A R Bloom, S Harris and C
> > Hill to act
> > > as Insolvency Practitioners under section 390(2)(a) of the
> > Insolvency
> > > Act
> > > 1986 and the Association of Chartered Certified Accountants
> > authorises
> >
> > > A M Hudson to act as an Insolvency Practitioner under section
> > > 390(2)(a) of the Insolvency Act 1986.
> > >
> > > The affairs, business and property of the Companies are
> > being managed
> > > by the Joint Administrators, A R Bloom, S Harris, AM Hudson
> > and C Hill
> >
> > > who act as agents of the Companies only and without personal
> > liability.
> > >
> > > The Companies are Nortel Networks UK Limited; Nortel Networks SA;
> > > Nortel GmbH; Nortel Networks France SAS; Nortel Networks
> NV; Nortel
> > > Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo;
> > > Nortel Networks Hispania SA; Nortel Networks (Austria)
> GmbH; Nortel
> > > Networks sro; Nortel Networks Engineering Service Kft;
> > Nortel Networks
> >
> > > Portugal SA; Nortel Networks Slovensko sro; Nortel Networks
> > Oy; Nortel
> >
> > > Networks Romania SRL; Nortel Networks AB; Nortel Networks
> > > International Finance & Holding BV
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]] On Behalf
> >
> > > Of Gonzalo Camarillo
> > > Sent: 19 February 2009 13:57
> > > To: [e-mail]
> > > Subject: [Ecrit] Expert review of
> > > draft-patel-ecrit-sos-parameter-03.txt
> > >
> > > Folks,
> > >
> > > I have been asked to perform an expert review of the
> > following draft:
> > >
> > > http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt
> > >
> > > The approach taken by the draft seems OK in general. I have a few
> > > comments though:
> > >
> > > The requirement in Section 3 is too specific because it already
> > > assumes that the solution will be an indication in the SIP header
> > > fields. The requirement does not need to make that
> > assumption. I would
> >
> > > remove "by providing an appropriate indication in the SIP header
> > fields".
> > >
> > > In Section 5, the reference to RFC 2234 should be replaced
> > with one to
> >
> > > RFC 5234.
> > >
> > > Also in Section 5, the formal syntax should be rewritten so
> > that it is
> >
> > > compatible with the ABNF in RFC 3261. RFC 3261 already defines
> > > uri-parameter as follows:
> > >
> > >    uri-parameter   =  transport-param / user-param / method-param
> > >                       / ttl-param / maddr-param / lr-param /
> > > other-param
> > >
> > >    other-param       =  pname [ "=" pvalue ]
> > >    pname             =  1*paramchar
> > >    pvalue            =  1*paramchar
> > >
> > > This document should simply define a new value for pname.
> > >
> > > The document does not talk about backwards compatibility.
> > What happens
> >
> > > if the registrar does not understand the 'sos' parameter?
> > Will it do
> > > the right thing? Will the UAC detect the failure? Is there
> > a need to
> > > define an option tag?... the document should address these points.
> > >
> > > Cheers,
> > >
> > > Gonzalo
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> >
> ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain
> > confidential information, privileged material (including
> > material protected by the solicitor-client or other
> > applicable privileges), or constitute non-public information.
> > Any use of this information by anyone other than the intended
> > recipient is prohibited. If you have received this
> > transmission in error, please immediately reply to the sender
> > and delete this information from your system. Use,
> > dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and
> > may be unlawful.
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>