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

From: "John-Luc Bakker" <[email-masked]>
Date: Wed, 6 May 2009 22:08:17 -0500

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

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Milan Patel
Sent: Tuesday, April 28, 2009 8:36 AM
To: Gonzalo Camarillo
Cc: [email-masked]
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
[email-masked]
Telephone +44 162 843 2381 / 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: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: 09 March 2009 10:32
To: Patel, Milan (MOP:EP10)
Cc: [email-masked]; 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
> [email-masked]
> Telephone +44 162 843 2381 / 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: [email-masked] [mailto:[email-masked]] On Behalf

> Of Gonzalo Camarillo
> Sent: 19 February 2009 13:57
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 May 2009 07:05:01 +0200

Hi,

My comments between the <christer> and </christer> tags. 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of John-Luc Bakker
> Sent: 7. toukokuuta 2009 6:08
> To: Milan Patel; Gonzalo Camarillo
> Cc: [email-masked]
> 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"
> If in agreement, I suggest the following changes to the draft 
> (between <new> and </new> tags):
> 
> 4.1.  REGISTER Request
> 
>    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:
> 
> 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

> 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 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
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Milan Patel
> 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.
> Telephone +44 162 843 2381 / 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 
> 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.
> 
> It just needs to be rephrased so that it is more descriptive 
> and non normative.
> 
> Thanks,
> 
> Gonzalo
> 
> Milan Patel wrote:
> > Folks,
> > 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> 
> > Of Gonzalo Camarillo
> 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.

---

From: "Milan Patel" <[email-masked]>
Date: Thu, 7 May 2009 11:43:31 +0100

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

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 07 May 2009 06:05
To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo
Cc: [email-masked]
Subject: RE: [Ecrit] Expert review of

Hi,

<christer>

Regards,

Christer

> Accountants
> authorises

---

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 7 May 2009 10:22:26 -0500

Hi Christer,

I see the XML tutorial has been time well spend! :)

<copy_of>
<christer>
</copy_of>

In my proposed changes below I have a MUST for including the option-tag
in the Proxy-Require. It would be useful for an emergency registration
attempt to be rejected using a 420 response as soon as possible, i.e.
already by the first proxy if the proxy has knowledge the extension is
not supported. However, I can agree that mandating inclusion of the
option-tag in the Proxy-Require is not required. 

Regards,

	John-Luc

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 12:05 AM
To: John-Luc Bakker; Milan Patel; Gonzalo Camarillo
Cc: [email-masked]
Subject: RE: [Ecrit] Expert review of

Hi,

<christer>

Regards,

Christer

---

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 7 May 2009 12:03:39 -0500

Hi Milan,

See inline

-----Original Message-----
From: Milan Patel [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 5:44 AM
To: Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo
Cc: [email-masked]
Subject: RE: [Ecrit] Expert review of

Hi John-Luc,

<John-Luc>
My understanding of 23.228 is that it is not specified if emergency
registration only occurs during initiation of an emergency call. Indeed,
the draft states:

   The 3GPP IP
   Multimedia Subsystem (IMS) emergency services architecture,
   illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User
   Equipment (UE) performs emergency registration prior to or during the
   initiation of an emergency call.
</John-Luc>

<John-Luc>
If the UE has sufficient credentials, the UE can make a normal
registration. I don't see a need to require an automatic fall back to
unauthenticated emergency call procedures. In most cases, I expect that
the normal registration is already in place.

The feature tag ensures that a UE doesn't "successfully" connect to a
legacy registrar and subsequently gets unanticipated behavior.
</John-Luc>

<John-Luc>
But the UE would still attempt a normal registration either after the
emergency registration or before the emergency registration was
attempted. In both cases, the registration would be "refreshed",
possibly even having a different "q" value (i.e. "q" value not set to 1
is refreshed by "normal" registration with a different "q" value).
</John-Luc>

Regards,
Milan

Milan Patel

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 07 May 2009 06:05
To: John-Luc Bakker; Patel, Milan (MOP:EP10); Gonzalo Camarillo
Cc: [email-masked]
Subject: RE: [Ecrit] Expert review of

Hi,

<christer>

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 May 2009 19:12:25 +0200

Hi, 

>I see the XML tutorial has been time well spend! :)

Yes.

<copy_of>
<copy_of>
<christer>

That is not really how Proxy-Require is intented to be used, in my
opinion. 

You use Proxy-Require if you require extension support from a proxy. You
do not insert Proxy-Require because you assume proxies will know whether
the UAS (the registrar in this case) supports the extension, and can
reject the request if they know what the UAS does not support it.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, May 07, 2009 12:05 AM
To: John-Luc Bakker; Milan Patel; Gonzalo Camarillo
Cc: [email-masked]
Subject: RE: [Ecrit] Expert review of

Hi,

<christer>

Regards,

Christer

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 May 2009 22:25:11 +0300

Hi,

thanks for putting together a new version of the draft. I still have a 
couple of minor comments on the following paragraph:

"If registration is successful, the 200 (OK) response from a legacy
    registrar is unlikely to include the "sos" URI parameter in the
    Contact header.  The UAC is aware of its registered contact address
    and address-of-record, however, is unable to distinguish between this
    registration and a non-emergency registration."

Clarifying why it is "unlikely" would be useful. Is it because RFC 3261 
gives registrars the freedom to do so, or because current implementation 
behave in different ways, or ...?

Also, the last sentence says that the UAC will not be able to 
distinguish this registration from a non-emergency registration. Well, 
that is because this indeed is a non-emergency registration for the 
legacy registrar. I would remove that whole sentence or, if you want to 
include that information, clarify that the registrar will treat this 
registration as any non-emergency registration.

Thanks,

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 15 May 2009 16:30:11 +0200

I would like to support Milan's reasoning here.

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

Keith

> Sent: Thursday, May 07, 2009 11:44 AM
> 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.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 May 2009 14:38:06 +0200

Hi,

I agree with Milan and Keith.

Regards,

Christer 

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 15. toukokuuta 2009 17:30
> To: Milan Patel; Christer Holmberg; John-Luc Bakker; Gonzalo Camarillo
> Cc: [email-masked]
> > Firstly, it is my understanding that emergency registration occurs 
> > when the emergency call request is detected by the UE (e.g. 
> user dials 
> > 911).
> specified to 
> > be the same as that of a normal registration.
> >
> registration 
> > 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.
> > 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
> >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of John-Luc Bakker
> > > 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.
> > >
> 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.
> > >
> > > 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"
> > >    When the UA sends a REGISTER request for emergency 
> registration, 
> > > the
> > > Proxy-Require and Require header</new>.  This serves as an 
> > > indication to the
> > >    registrar that the
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > 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
> > >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Milan Patel
> > > 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.
> Harris and 
> > > C Hill to act as Insolvency Practitioners under section 
> 390(2)(a) of 
> > > the Insolvency Act
> > > authorises A M Hudson to act as an Insolvency Practitioner under 
> > > section 390(2)(a) of the Insolvency Act 1986.
> > >
> > > 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.
> > >
> > > 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
> > >
> > > 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.
> > >
> > > confidential information, privileged material (including material 
> > > protected by the solicitor-client or other applicable 
> privileges), 
> > > or constitute non-public information.
> transmission in 
> > > error, please immediately reply to the sender and delete this 
> > > information from your system. Use, dissemination, 
> distribution, or