Subject: Re: [sip-overload] Alignment of priority and emergency call handling

From: Janet P Gunn <[email-masked]>
Date: Wed, 1 Aug 2012 05:06:07 -0400

Sounds good to me. Is "Recorder tone" defined there?

Janet

-----"DRAGE, Keith (Keith)" <[email-masked]> wrote: -----

To: Janet P Gunn/USA/CSC@CSC, "[email-masked]" <[email-masked]>
From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: 07/30/2012 06:19PM
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [sip-overload] Alignment of priority and emergency call handling

Can I suggest that we stick to the terminology available in ITU-T Recommendation E.182 (and E.180) as this U.S. terminology is very specific to the U.S. and other terms are used elsewhere in world.

Keith

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 30 July 2012 23:03
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

Thanks

WRT the last comment - "Reorder tone" is also known (at least in the US) as "fast busy".

I agree that there might be "announcements"

but I do not know what you mean by "Recorder tone". Do you mean the tone that sometimes comes on just BEFORE an announcement?

Janet

[email-masked] wrote: -----

To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: [email-masked]
Date: 07/29/2012 11:35PM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

Hi Janet, thank you very much for your detailed comments! I've
incorporated them in the new revision. Also please see response
inline.

On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn <[email-masked]> wrote:
> I agree with Keith's comments about priority and emergency calls.
>

done

> I also have a number of other comments, mostly editorial (I apologize for my
> lateness in responding).
>
>
> Introduction should stress that this approach is for situations where you
> can predict, in advance, a likely traffic surge,
> and its source/destination distribution.  For instance, it is appropriate
> for a mass-phone-voting event, Mother's Day, New
> Years, and even a hurricane (there is usually some advance notice).
> However, it is less likely to be effective for the initial phase of
> unpredicted/unpredictable mass calling events, such as
> earthquakes or terrorist attacks.  In these latter cases, the local traffic
> load may peak by more than an order of magnitude
> in minutes, if not seconds.  This does not allow time to either
> effectively identify the filters needed, nor distribute then to the
> appropriate servers, soon enough to prevent congestion
> attack.  Once other, more immediate, techniques (such as the loss-based or
> rate-based  methods) have prevented the initial
> congestion collapse, the event package can be used to effectively control
> the continuing overload.
> --

agree.

> This sentence
>  Load filtering works best if it prevents calls as close to
>  the user agent clients as possible.
> could be clarified by including the word "originating"
>  Load filtering works best if it prevents calls as close to
>  the originating user agent clients as possible.
> --

right

> There appears to be a cut and past error here
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless when associated with other explicit context.
> I suspect it is supposed to be
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless associated with other explicit context.
> --
>

right

> I am not sure I understand this statement
> This
>    specification, however, does not preclude the load control document
>    defined here (Section 6) to be extended in the future for other forms
>    of control as appropriate.
> What sorts of "other forms of control" are you referring to?  Presumably not
> service level and QoS control, as you have
> already defined them (or at least referred to them) as "load control" but
> not "overload control".
> --

Yes, it could be confusing, so I removed this sentence.

>  Section 3
> I think that
> For destination-specific overload situations, the load filter
>       needs to be able to describe the callee.
> should be
> For destination-specific overload situations, the load filter
>       should be able to specify the callee.
> --

agree.

> This bullet
>  To address accidental and intentional high-volume call generators,
>       the load filter should allow to specify the caller.
> does not use correct grammar.
> I suspect you mean
>  To address accidental and intentional high-volume call generators,
>       the load filter should be able to  specify the caller.
> --

agree

> With regard to this bullet,
>    o  For telephone numbers, it should be possible to specify prefixes
>       which allow control over limited regionally-focused overloads.
> This is really an assumption rather than a requirement.
> Furthermore, I do not believe it is true.  In these days of number
> portability, and people retaining their original mobile
> phone number, as their primary number, when they move across the country,
> the correlation between "telephone number prefix"
> (aka area code) and "physical location" is rapidly decreasing.
> I agree that,for regional calling events, you need a way of identifying the
> geographical location (originating and/or
> terminating) to determine which calls to filter.  But I do not think that
> area codes will continue to be the most effective
> way of doing this.
> Perhaps an alternate wording would be
>    o  It should be possible to specify particular information in the SIP
> headers (e.g., prefixes in telephone numbers)
>       which allow control over limited regionally-focused overloads
> ---

agree

> sec 4.2
>  in this statement
>  and that loads are allocated in a way which
>    both prevents overload and minimizes the likelihood of network
>    resource under-utilization.
> would it be better to say "maximizes effective throughput(aka goodput)"
> instead of "minimizes the likelihood of network
>    resource under-utilization."?
> ---

agree

> sec 4.3
>
> Should this
> In order for load filters to be properly distributed, each SIP proxy
>    server in the network is required to subscribe to the load control
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> be
> In order for load filters to be properly distributed, each SIP proxy
>    server in the network SHOULD subscribe to the load control
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> ? (not sure myself)
>
> ---

agree.

> For case II, perhaps "hurricane" (which has a more predictable, and more
> gradual, increase in traffic) would be a better
> example than "earthquake", due to the issues mentioned above.
> --
> Sec 5.3
> In sec 4.4 you say
> Another important aspect that affects the applicability of SIP load
>    filtering is that all possible signaling source neighbors need to
>    participate and enforce the designated filter.  Otherwise, a single
>    non-conforming neighbor could make the whole control efforts useless
>    by pumping in excessive traffic to overload the server.
> But in section 5.3 you say
> a subscriber may be interested in some
>    specific types of load control policy only.
> Maybe I am misunderstanding what you mean by "types of load control policy",
> but the statement in 5.3 ("only interested in
> some") seem inconsistent with the statement in 4.3 ("all must participate").
> Perhaps you could add a clarifying statement.
> ---

Since the details of the subscription filter specification are not
defined anyway, I removed this "For example" sentence to avoid the
confusion.

> 5.8
> Modifications of existing load
>    control policies at the subscriber is performed after directly
>    receiving notifications containing updated load control policies.
> Grammar
> either
> ... modifications ... are ...
> or
> ...modification ...is ...
> but NOT
> ... modifications ... is ...
> ---

right

> 5.11
> This sentence
> "Another factor usually not known precisely or is
>    computed automatically is the validity duration of the load control
>    event."
> Seems to be a cut and paste error of some sort.
> ...

Changed to "  Another factor that is usually not known precisely or
needs to be computed automatically is the validity duration of the
load control event.  "

> 8.1
> Should this
> "... administrative option for routing failed
>    call attempts to either Recorder Tone or a special announcement...."
> be "Reorder Tone" instead of "Recorder Tone"?
>
>

I think this is something like a recording machine playing something
message, am I correct?

thanks

Charles

> Janet
>
>
>
> [email-masked] wrote: -----
>
> To: [email-masked]
> From: "Vijay K. Gurbani"
> Sent by: [email-masked]
> Date: 07/26/2012 12:03PM
> Cc: [email-masked]
>
> Subject: Re: [sip-overload] Alignment of priority and emergency call
> handling
>
> On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:
>> I do not believe you need to include other artifacts.
>>
>> Rather overload-control lists both RPH and sos URN, and the event
>> package lists only RPH.
>
> So it is a simple matter of ensuring that the text in
> draft-ietf-soc-load-control-event-package is consistent with the
> text in draft-ietf-soc-overload-control?
>
> If so, Charles --- can you please take care of this in
> draft-ietf-soc-load-control-event-package?
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [email-masked]
> Web:   http://ect.bell-labs.com/who/vkg/
>
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
> CSC to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-mail
> for such purpose.
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 2 Aug 2012 13:02:11 -0400

In that case, the Event package draft should use the ITU terms.

What are the equivalent ITU terms?

Janet

Date: 08/01/2012 11:25AM

Recorder tone is not.

Neither is reorder tone in the quick skin I did.

Keith

From: Janet P Gunn [mailto:[email-masked]]
Sent: 01 August 2012 10:06
To: DRAGE, Keith (Keith)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] Alignment of priority and emergency call handling

Janet

Keith

Thanks

Janet

[email-masked] wrote: -----

done

agree.

right

right

agree.

agree

agree

agree

agree.

right

thanks

Charles

---

From: <[email-masked]>
Date: Fri, 3 Aug 2012 09:08:45 +0000

I think recorder tone is a tone to indicate to the called party that the calling party is recording the conversation. So I don’t think this tone would be appropriate in the case of call failure due to overload control. An ITU E.182 special information tone would rather be used in this case.
/BC

De : [email-masked] [mailto:[email-masked]] De la part de Janet P Gunn
Envoyé : jeudi 2 août 2012 19:02
À : [email-masked]
Cc : [email-masked]
Objet : Re: [sip-overload] Eveny package was Alignment of priority and emergency call handling

Janet

Keith

________________________________

Janet

Keith

________________________________

Thanks

Janet

[email-masked] wrote: -----
To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: [email-masked]
Date: 07/29/2012 11:35PM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

done

agree.

right

right

agree.

agree

agree

agree

agree.

right

thanks

Charles

_________________________________________________________________________________________________________________________

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.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 5 Aug 2012 09:33:18 +0200

My proposal (terminology wise) would be "special information tone as defined in ITU-T Recommendation E.182 to indicate .... or a specific recorded announcement".

Keith

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: 03 August 2012 10:09
To: Janet P Gunn; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: RE: [sip-overload] Eveny package was Alignment of priority and emergency call handling

I think recorder tone is a tone to indicate to the called party that the calling party is recording the conversation. So I don't think this tone would be appropriate in the case of call failure due to overload control. An ITU E.182 special information tone would rather be used in this case.
/BC

Janet

Keith

Janet

Keith

Thanks

Janet

[email-masked] wrote: -----
To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: [email-masked]
Date: 07/29/2012 11:35PM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

done

agree.

right

right

agree.

agree

agree

agree

agree.

right

thanks

Charles

Thank you.

---

From: Adam Roach <[email-masked]>
Date: Sun, 05 Aug 2012 12:39:22 -0500

This whole conversation is as amusing as watching an American and a 
Briton argue about the meaning of the word "pants." Let me see if I can 
clear some things up.

On 8/3/12 04:08, Aug 3, [email-masked] wrote:
>
> I think recorder tone is a tone to indicate to the called party that 
> the calling party is recording the conversation. So I don't think this 
> tone would be appropriate in the case of call failure due to overload 
> control.
>

Not "recorder" -- "reorder," which is what North American phone systems 
produce to indicate overload: http://en.wikipedia.org/wiki/Reorder_tone

The reference you're looking for here is ITU-T E.300 Series Supplement 3.

On 8/5/12 02:33, Aug 5, DRAGE, Keith (Keith) wrote:
>
> My proposal (terminology wise) would be "special information tone as 
> defined in ITU-T Recommendation E.182 to indicate .... or a specific 
> recorded announcement".
>

The issue with using a special information tone for overload is that 
North American systems use that signal to indicate conditions that 
cannot be rectified by re-trying later. They are widely understood by 
humans to mean "you dialed the wrong number," and used by some automated 
systems to remove numbers from directories. Using them for overload 
situations would have the wrong meaning for people and generate unwanted 
behavior in automated systems.

I also find it curious that you chose to elide the rather important 
exceptions regarding Special Information Tones. The entire description 
in E.182 is:

> A tone advising the caller that the called number cannot be reached 
> for reasons other than "subscriber busy" or "congestion".
>
> The tone may also be used in conjunction with recorded announcements 
> to signify that what the caller is about to hear is a recording. It 
> should always be used to precede all call failure announcements.

It seems to me that this circumstance is most analogous to "congestion," 
and that a "Congestion Tone" would be far more appropriate.

Nonetheless, we may need to take regional variations into account here 
-- as it is plausible that one or two implementors may actually be 
American -- and specify something like "a tone used in the callers' 
locale to indicate resource exhaustion, such as a Congestion Tone in 
Europe or a Reorder Tone in North America."

/a