Subject: [sip-overload] Overload and emergency

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 5 Nov 2012 14:47:17 +0100

For emergency, draft-ietf-soc-overload-control-10

   A SIP client SHOULD honor the local policy for prioritizing SIP
   requests such as policies based on the content of the Resource-
   Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
   RPH contents may indicate high priority requests that should be
   preserved as much as possible during overload.  The RPH contents can
   also indicate a low-priority request that is eligible to be dropped
   during times of overload.  Other indicators, such as the SOS URN
   [RFC5031] indicating an emergency request, may also be used for
   prioritization.

 And for draft-ietf-soc-load-control-event-package-05

   In addition, whatever the actual policy is, SIP
   servers SHOULD honor the local policy for prioritizing SIP requests
   such as policies based on the contents of the Resource-Priority
   Header (RPH) [RFC4412].  The RPH contents may indicate high priority
   requests that should be preserved as much as possible, or low
   priority requests that could be dropped during overload.  Other
   indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
   indicating an emergency request, may also be used for prioritization.
   SIP request rejection and message prioritization at an overloaded
   server are also discussed in Section 5.10 of
   [I-D.ietf-soc-overload-control] and Section 12 of [RFC6357].

Prioritisation of emergency is under exactly the same sort constraints as priority, therefore in both these drafts I would like to see exactly parallel specification to priority.

   A SIP client SHOULD honor any local policy for prioritizing SIP
   requests such as policies based on the content of the Resource-
   Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
   RPH contents may indicate high priority requests that should be
   preserved as much as possible during overload.  The RPH contents can
   also indicate a low-priority request that is eligible to be dropped
   during times of overload.  

   A SIP client SHOULD honor any local policy for prioritizing SIP 
   requests relating to emergency calls, as identified by the SOS 
   URN [RFC5031] indicating an emergency request.

While only some countries require priority for emergency, those that do want this adequately specified.

Note that in the load control document, this does need to be separate paragraphs.

Keith

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 5 Nov 2012 09:37:16 -0500

Keith,

I agree we should have the same wording in 
draft-ietf-soc-overload-control
soc-load-control-event-package
also
draft-ietf-soc-overload-rate-control

But I do have one concern with your proposed new wording.

Both versions of the current wording give RPH and SOS as examples of 
"local policy" which may prioritize  which SIP messages don't get drops. 
However, they are only examples, and do not preclude other local policies. 

For instance I have understood "drop new INVITES before you drop messages 
associated with already established sessions" to be another example of 
"local policy".  But it isn't explicitly mentioned in that text.  Some of 
the documents mention it elsewhere.

Perhaps
"   A SIP client SHOULD honor any local policy for prioritizing SIP
   requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.
 
   requests based on the content of the Resource-

   A SIP client SHOULD honor any local policy for prioritizing SIP 
   requests relating to emergency calls, as identified by the SOS 
   URN [RFC5031] indicating an emergency request."

That puts RPH and the SOS URN on the same level, and makes the  use of 
"INVITEs" vs, "existing sessions" an explicit example. 

Janet

From:   "DRAGE, Keith (Keith)" <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   11/05/2012 08:47 AM
Subject:        [sip-overload] Overload and emergency
Sent by:        [email-masked]

Prioritisation of emergency is under exactly the same sort constraints as 
priority, therefore in both these drafts I would like to see exactly 
parallel specification to priority.

While only some countries require priority for emergency, those that do 
want this adequately specified.

Note that in the load control document, this does need to be separate 
paragraphs.

Keith
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 5 Nov 2012 15:41:30 +0100

That is fine by me

Keith

________________________________
From: Janet P Gunn [mailto:[email-masked]]
Sent: 05 November 2012 14:37
To: DRAGE, Keith (Keith)
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] Overload and emergency

Keith,

Both versions of the current wording give RPH and SOS as examples of "local policy" which may prioritize  which SIP messages don't get drops.  However, they are only examples, and do not preclude other local policies.

For instance I have understood "drop new INVITES before you drop messages associated with already established sessions" to be another example of "local policy".  But it isn't explicitly mentioned in that text.  Some of the documents mention it elsewhere.

Perhaps

That puts RPH and the SOS URN on the same level, and makes the  use of "INVITEs" vs, "existing sessions" an explicit example.

Janet

________________________________

Keith

---

From: <[email-masked]>
Date: Wed, 7 Nov 2012 15:13:10 +0000

BTW, why do we have a SHOULD rather than a MUST? Setting a local policy is optional but if there is one it seems to me that the SIP client MUST honor it.
BC

De : [email-masked] [mailto:[email-masked]] De la part de DRAGE, Keith (Keith)
Envoyé : lundi 5 novembre 2012 15:42
À : Janet P Gunn
Cc : [email-masked]
Objet : Re: [sip-overload] Overload and emergency

That is fine by me

Keith

Keith,

Perhaps

Janet

Keith

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.