From charles.newyork@gmail.com Fri Oct 12 09:21:45 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2EF21F8722 for ; Fri, 12 Oct 2012 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUDbx1norRdX for ; Fri, 12 Oct 2012 09:21:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1899821F86DA for ; Fri, 12 Oct 2012 09:21:44 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4096158vcb.31 for ; Fri, 12 Oct 2012 09:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=i/Wi9XB28BxJ75spgtSqab0npF6X3Ek9wcEqTNzrjr4=; b=XZqdiScfFFpDdYLxRT+Z9n0SeAEkaXEq+EmInMDdhZGY0qKcRZz2nLu4I1Vxh9dR+R KOC2ZK9sQBp+fZxXigOsWDoh89Ay2KLmlGotwglm/nJAgdX9RD6Rqy/nxEaKIJF7d2ui /lQU+P5wF36Ol7UaYXmjD/mntjzzQ96jmTClil6VUXNvoGXPeEQlS0I+tTAMAi3EOxK5 i9N+6BfU6UIbHoN+munebFeio6ZZj1bexsFzdFs6M1VJb2F4Gwzxx+1Jn8pMal8TqE8k OdkF7cLtGKv44B0a+C4p7mPD41jfHmNSaABRIxqf3u03vOO0SSpdGLm/jFdc1j1DrrtD RDNw== Received: by 10.58.155.169 with SMTP id vx9mr2901442veb.45.1350058903559; Fri, 12 Oct 2012 09:21:43 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Fri, 12 Oct 2012 09:21:23 -0700 (PDT) From: Charles Shen Date: Fri, 12 Oct 2012 12:21:23 -0400 X-Google-Sender-Auth: z3pPrNE-I_T1qKXH6r26UGtvc-U Message-ID: To: Adam Roach , Janet P Gunn , keith.drage@alcatel-lucent.com, bruno.chatras@orange.com Content-Type: multipart/alternative; boundary=047d7b6044f25f5c5a04cbdf1529 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] (reorder/recorder) draft-ietf-soc-load-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:21:45 -0000 --047d7b6044f25f5c5a04cbdf1529 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for all the interesting inputs! To wrap this up, I will revise the current sentence in Sec. 8.1 PSTN filtering also provides administrative option for routing failed call attempts to either Recorder Tone or a special announcement. To the following: PSTN filtering also provides administrative option for routing failedcall attempts to either a reorder tone [cite:ITU-T E.300SerSup3] indicating overload conditions, or a special recorded announcement. Let me know if you have more comments. Charles On Sun, Aug 5, 2012 at 1:39 PM, Adam Roach wrote: > 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, bruno.chatras@orange.com 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=E2=80=99t think thi= s 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 =E2=80=9Cspecial information tone= as > defined in **ITU**-T Recommendation E.182 to indicate =E2=80=A6. or a spe= cific > recorded announcement=E2=80=9D.**** > > > The issue with using a special information tone for overload is that Nort= h > American systems use that signal to indicate conditions that cannot be > rectified by re-trying later. They are widely understood by humans to mea= n > "you dialed the wrong number," and used by some automated systems to remo= ve > numbers from directories. Using them for overload situations would have t= he > 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 indicat= e > resource exhaustion, such as a Congestion Tone in Europe or a Reorder Ton= e > in North America." > > /a > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > --047d7b6044f25f5c5a04cbdf1529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for all the interesting inputs! To wrap this up, I will revise the c= urrent=C2=A0sentence in Sec. 8.1

   PSTN filtering =
also provides administrative option for routing failed
   call attempts to either Recorder Tone or a special announcement.

To the following:

PSTN filt=
ering also provides administrative option for routing failed
call attempts to either a reorder tone [cite:=
ITU-T E.300SerSup3] indicating overload conditions, or a special recorded a=
nnouncement.

Let me know if you have = more comments.

Charles


On Sun, Aug 5, 2012 at 1:39 PM, Adam Roach <adam@nostru= m.com> wrote:
=20 =20 =20
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, bruno.chatras@orange.com wrote:
=20 =20 =20 =20

I = think recorder tone is a tone to indicate to the called party that the calling party is recording the conversation. So I don=E2=80=99t think this tone would be appropriate in the case of call failure due to overload control.


Not "recorder" -- "reorder," which is what North Am= erican 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 =E2=80=9Cspecial information tone as defined in ITU-T Recommendation E.182 to indicate =E2=80=A6. or a specific recorded announcemen= t=E2=80=9D.


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

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload


--047d7b6044f25f5c5a04cbdf1529-- From charles.newyork@gmail.com Fri Oct 12 09:44:17 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9721F871D for ; Fri, 12 Oct 2012 09:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6WbjvCNPnV2 for ; Fri, 12 Oct 2012 09:44:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9EC21F871C for ; Fri, 12 Oct 2012 09:44:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3633129vbb.31 for ; Fri, 12 Oct 2012 09:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=jWVRkG/GsgD5Bv+Ovyh5EGy8ocLbhHzMlPyOwGcXe5Y=; b=kUvssWwpjC151S7lLX+EzfFP4GQOIR9aEvfiZFEQRsQBNBhc4kqofwdFvM00CO8/8Y Il+D0fcbWn9NU3xucweObJN6R4aUxNGSYLvqvA/9hlVpU1cjS87pr9cdJRLZap9G5hkl J0IZ00OTezjRkSwDPQ6Zu6s7pLyzSkk3EwXcMd0QuMNnzRI/m4Jh97+U7Ds5N04NPlb9 /t/9iI+hur1Glx+gS8B/NbtMcgBGYZbnkSbJsF/KsbQSRFwmoaFfxxDvqb7z1n2kK7by wOzAmMgjLky/7z64hFZtfaBLrNeDV+9FT4d6a5n9J3rGgpUQ8HjX2HcrQj/xvPmd3vTh XdYw== Received: by 10.58.155.169 with SMTP id vx9mr2937600veb.45.1350060253952; Fri, 12 Oct 2012 09:44:13 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Fri, 12 Oct 2012 09:43:53 -0700 (PDT) In-Reply-To: <23338_1343832995_501943A3_23338_11382_1_88CAD1D4E8773F42858B58CAA28272A0068486@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> <23338_1343832995_501943A3_23338_11382_1_88CAD1D4E8773F42858B58CAA28272A0068486@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Fri, 12 Oct 2012 12:43:53 -0400 X-Google-Sender-Auth: sZXFYLUfivWdlV4e-MptZc6d0H4 Message-ID: To: bruno.chatras@orange.com Content-Type: multipart/alternative; boundary=047d7b6044f2dcbbc604cbdf652e Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:44:17 -0000 --047d7b6044f2dcbbc604cbdf652e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI Bruno, So I am defining a "target-sip-entity" condition element parallel to the "call-identity" elements as below. I think it should help in the situation you mentioned, without adding too much complexity. I am making it optional, unless people have strong opposite opinions. ... Thanks Charles On Wed, Aug 1, 2012 at 10:56 AM, wrote: > Hi Charles, > > "Route" may be a bit misleading as the matching should be performed on th= e > identity or address obtained after applying RFC3263 procedures to the fir= st > value of the route header or to the R-URI rather than on the contents the > route header as such. > > BC > > > > -----Message d'origine----- > > De : charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De la > > part de Charles Shen > > Envoy=C3=A9 : lundi 30 juillet 2012 05:07 > > =C3=80 : CHATRAS Bruno RD-CORE > > Cc : Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning > > Schulzrinne; Arata Koike > > Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event- > > package > > > > Hi Bruno, sorry for the delayed response! > > > > I've updated the local number grouping text. For the multi-path > > filtering policy problem, since it will affect texts in multiple > > sections, I'd like to discuss a bit more in terms of the solution. > > > > Assuming the following scenario, > > > > P3A > > alice@p1 --- P1 --- P2 -- / \ --- P4 --- bob@p4 > > \ / > > P3B > > > > where P2 can reach bob through either P3A or P3B, the call identity in > > the existing policy does not distinguish the calls to bob@p4 through > > P3A from those through P3B. Therefore it would be good for the load > > control > > policy to include not only the call destination (e.g., bob@p4 in > > this case), but also through which path the call is routed. > > > > One possible solution could be to add a new sub-element called > > under the existing schema. In the simple case, > > the new element can be of the same type as the > > element in [RFC4745]. The contents of the element holds what > > you call target SIP entities. > > > > Using the same example above, server P1 may receive a policy > > containing the new element as below: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Similarly server P2 may receive a policy containing the new element as > > below: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then the call filtering can match both the call destination and the > > path (assuming either a SIP Route header is included, or a next hop > > SIP server is chosen dynamically). > > > > There is still a small problem though - if the new element is > > defined as one of element in RFC4745, then the > > sub-elements under it are not ordered, while here we seem to need an > > ordered list (as in the list of SIP Route headers). Therefore, we > > might have to define new rules for the element to make its > > sub-elements ordered. > > > > Any thoughts? > > > > Charles > > > > > > > > > > > > On Tue, Jul 17, 2012 at 1:07 PM, wrote: > > > Hi Charles, > > > > > > See below. > > > > > >> -----Message d'origine----- > > >> De : charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De > > la > > >> part de Charles Shen > > >> Envoy=C3=A9 : mardi 17 juillet 2012 18:37 > > >> =C3=80 : CHATRAS Bruno RD-CORE > > >> Cc : Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning > > >> Schulzrinne; Arata Koike > > >> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event- > > >> package > > >> > > >> Hi Bruno, thank you so much for the detailed review and comments! > > I've > > >> addressed 8 out of the total 10, except the following two which I'd > > >> appreciate more clarification. > > >> > > >> > 2) Section 5.8, line 525-528 > > >> > > > >> > The current text suggests that incoming requests are filtered > > >> irrespective of their actual destination. The subscriber should > > rather > > >> apply filters on requests that are outgoing to the pre-overloaded > > >> destination. One solution would be to rephrase the following text: > > >> > > > >> > "A subscriber receiving the notification first installs these rule= s > > >> and then filter incoming requests to enforce actions on appropriate > > >> requests, for example, limiting the sending rate of call requests > > >> destined for a specific SIP entity." > > >> > > > >> > With > > >> > > > >> > "A subscriber receiving the notification first installs these rule= s > > >> and then filter outgoing requests towards the notifier to enforce > > >> actions on appropriate requests, for example, limiting the sending > > rate > > >> of call requests destined for a specific SIP entity." > > >> > > > >> > This would however not permit the use of external state agents as > > >> described in section 5.12. Therefore it seems that a "target sip > > entity" > > >> parameter should be added to overload control documents. > > >> > > > >> > > >> I think I might have not understood your point. The requests are > > >> filtered based on the call identities, which can convey information > > >> including the call destination. Could you elaborate what this "targe= t > > >> sip entity" is exactly for? > > > [BC] > > > > > > Let's take two examples that I think are not covered by the current > > wording. > > > > > > 1) Example 1 > > > > > > Call configuration: A is connected so SP1, B is connected to SP2. SP1 > > and SP2 are connected via SP3. SP3 is connected to an Application Serve= r > > (AS). Under normal load conditions, a call from A to B is routed along > > the following path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential > > service and can be bypassed in case of overload. > > > > > > Now let's assume that AS is overloaded and sends to SP3 a filter > > requesting that 50% of INVITE messages be dropped, regardless of the > > contents of the from/to/PAI/R-URI. > > > > > > According to the current wording, SP3 will indeed filter 50% of the > > INVITE requests while they could be routed to B via SP2. > > > > > > 2) Example 2 > > > > > > Call Configuration: An 800 translation service is installed on two > > Application Servers AS-1 and AS-2. A is connected to SP1 and calls 800 > > 1234 4529, which is translated by AS-1 and AS-2 into a regular E164 > > number, depending on e.g. the caller's location. SP1 forwards INVITE > > requests with R-URI =3D "800 number" to AS-1 or AS-2 based on a load > > balancing strategy. > > > > > > As calls to 800 1234 4529 creates a pre-overload condition in AS-1, > > AS-1 sends to SP-1 a filter requesting that 50% of calls towards 800 > > 1234 4529 be rejected. > > > > > > According to the current wording, SP3 will apply the filter on > > incoming INVITE requests, irrespective of whether they are intended to > > be sent to AS1 or AS2. > > > > > > =3D=3D> It seems that these use cases could be solved by applying the > > filters to outgoing requests (not incoming requests) that are to be > > routed to the AS that sent these filters. This means that the SP has to > > store the AS address together with the received filters or this address > > has to be included explicitly as a new filter criteria. > > > > > >> > > >> > > >> > 5) Section 6.3.1, local number grouping: > > >> > > > >> > The proposed solution for local numbers is not suitable. For > > example, > > >> if the phone-context for short service numbers in a country is the > > >> country code, the solution does not permit to define a filter that > > >> excludes all E.164 numbers in that country but retain all short > > service > > >> numbers. I think we should either define another solution or state > > that > > >> grouping of local numbers is not supported or state that grouping of > > >> local numbers only works under specific assumptions on the use of > > phone- > > >> context values. > > >> > > > >> > > >> How about adding the following text? > > >> > > >> It should be noted that the method of grouping local numbers as > > >> defined in this document does not support all cases. For example, if > > >> the phone-context for short service numbers in a country is the > > >> country code, this solution does not permit to define a filter that > > >> excludes all E.164 numbers in that country but retain all short > > >> service numbers. A complete solution for local number grouping > > >> requires a separate method outside the scope of this document. > > > [BC] > > > > > > Looks OK for me. > > > > > > > > >> > > >> > > >> Thanks! > > >> > > >> Charles > > >> > > >> > > >> On Wed, Jul 11, 2012 at 3:33 AM, wrote: > > >> > Hi! > > >> > > > >> > Here are my comments about this I-D. > > >> > > > >> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph = 5 > > >> (i.e. after line 360) and modifies the first two sentences as follow= s: > > >> > > > >> > "In the above case, the network entity where load filtering policy > > is > > >> first introduced is the SIP server providing access to the resource > > that > > >> creates the overload condition. In other cases, the network entry > > point > > >> of load filtering policy could also be an entity that hosts this > > >> resource. " > > >> > > > >> > 2) Section 5.8, line 525-528 > > >> > > > >> > The current text suggests that incoming requests are filtered > > >> irrespective of their actual destination. The subscriber should > > rather > > >> apply filters on requests that are outgoing to the pre-overloaded > > >> destination. One solution would be to rephrase the following text: > > >> > > > >> > "A subscriber receiving the notification first installs these rule= s > > >> and then filter incoming requests to enforce actions on appropriate > > >> requests, for example, limiting the sending rate of call requests > > >> destined for a specific SIP entity." > > >> > > > >> > With > > >> > > > >> > "A subscriber receiving the notification first installs these rule= s > > >> and then filter outgoing requests towards the notifier to enforce > > >> actions on appropriate requests, for example, limiting the sending > > rate > > >> of call requests destined for a specific SIP entity." > > >> > > > >> > This would however not permit the use of external state agents as > > >> described in section 5.12. Therefore it seems that a "target sip > > entity" > > >> parameter should be added to overload control documents. > > >> > > > >> > 3) Section 5.8, add the following text (adapted from draft-ietf- > > soc- > > >> overload-control) after line 537: > > >> > > > >> > "When enforcing actions on requests matching the filters, > > subscribers > > >> 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." > > >> > > > >> > 4) Section 6.3.1, matching identities: After line 699, add the > > >> following text: > > >> > > > >> > "Before evaluating call-identity conditions, the subscriber shall > > >> convert URIs received in SIP header fields in canonical form as per > > RFC > > >> 3261, except that the phone-context parameter shall not be removed, > > if > > >> present." > > >> > > > >> > 5) Section 6.3.1, local number grouping: > > >> > > > >> > The proposed solution for local numbers is not suitable. For > > example, > > >> if the phone-context for short service numbers in a country is the > > >> country code, the solution does not permit to define a filter that > > >> excludes all E.164 numbers in that country but retain all short > > service > > >> numbers. I think we should either define another solution or state > > that > > >> grouping of local numbers is not supported or state that grouping of > > >> local numbers only works under specific assumptions on the use of > > phone- > > >> context values. > > >> > > > >> > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence > > and > > >> reword the rest of the text accordingly. Reason: The use of local > > number > > >> 'tel' URI in the R-URI and To header field is not rare. In several > > >> countries, short numbers are used quite extensively to access specia= l > > >> services. > > >> > > > >> > "Second, use of the local number 'tel' URI in practice is expected > > to > > >> be rare." > > >> > > > >> > 7) Clause 6.3.3, after line 800, add: > > >> > > > >> > "SUBSCRIBE requests are not filtered if the event-type header fiel= d > > >> indicates the event package defined in this document." > > >> > > > >> > 8) Section 7, line 985 - 990: replace "call type" with "call > > identity > > >> type" (3 times) > > >> > > > >> > 9) Section 8.1 > > >> > > > >> > Line 1048, add "except in specific cases when the Intelligent > > Network > > >> architecture is used [AINGR]. > > >> > > > >> > Line 1060, remove the last part of the first sentence starting wit= h > > >> "and the number of prefix to be matched.": ITU IN specifications > > allow > > >> for dynamic sets. > > >> > > > >> > Line 1068, remove the last part of the first sentence staring with > > >> "with a fixed set.": Reason: ITU IN specifications allow for dynamic > > >> sets. > > >> > > > >> > 10) Miscellaneous points > > >> > Section 1, line 106, replace RFC3265 with RFC3261 > > >> > Section 4.1, line 231, replace "proxy" with "node" (this text > > should > > >> apply to any type of SIP entity) > > >> > Section 4.3, line 265, replace "proxy" with "node" (this text > > should > > >> apply to any type of SIP entity) > > >> > Section 4.3, Line 341, replace "singling" with "signaling" > > >> > Section 4.3, Line 342, replace "all signaling relationship in > > Figure 1 > > >> is" with "all signaling relationships in Figure 1 are" > > >> > Section 5.6, Line 503, add "request" after "SUBSCRIBE" > > >> > Section 5.11, Line 585, remove "is" > > >> > Section 6.5, Line 851, replace "vliad" with "valid" > > >> > > > >> > Bruno > > >> > > > >> > > > >> >> -----Message d'origine----- > > >> >> De : sip-overload-bounces@ietf.org [mailto:sip-overload- > > >> bounces@ietf.org] > > >> >> De la part de Salvatore Loreto > > >> >> Envoy=C3=A9 : lundi 2 juillet 2012 21:09 > > >> >> =C3=80 : sip-overload@ietf.org > > >> >> Cc : Volker Hilt > > >> >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event- > > >> package > > >> >> > > >> >> [as chair] > > >> >> > > >> >> based on the mailing list discussion and the one we had during th= e > > >> last > > >> >> SoC f2f meeting in Paris, > > >> >> the chairs think the draft-ietf-soc-oload-control-event-package i= s > > >> ready > > >> >> for the WGLC. > > >> >> > > >> >> Today we are starting a two-week working group last call. > > >> >> This call ends on Wednesday, July 16th. > > >> >> > > >> >> the last version of the document can be retrieved here: > > >> >> http://tools.ietf.org/html/draft-ietf-soc-load-control-event- > > package- > > >> 03 > > >> >> > > >> >> > > >> >> reviews and comments are really appreciate and requested from all > > the > > >> >> participants > > >> >> > > >> >> > > >> >> cheers > > >> >> /Sal > > >> >> > > >> >> -- > > >> >> Salvatore Loreto, PhD > > >> >> www.sloreto.com > > >> >> > > >> >> _______________________________________________ > > >> >> sip-overload mailing list > > >> >> sip-overload@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/sip-overload > > >> > > > >> > > > >> > > _______________________________________________________________________= _ > > >> _________________________________________________ > > >> > > > >> > 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 fo= r > > >> messages that have been modified, changed or falsified. > > >> > Thank you. > > >> > > > >> > _______________________________________________ > > >> > sip-overload mailing list > > >> > sip-overload@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > _______________________________________________________________________= _ > > _________________________________________________ > > > > > > 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 ave= z > > 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 an= d > > 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. > > > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > --047d7b6044f2dcbbc604cbdf652e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI Bruno,=C2=A0

So I am defining a "targ= et-sip-entity" condition element parallel to the "call-identity&q= uot; elements as below. I think it should help in the situation you mention= ed, without adding too much complexity. I am making it optional, unless peo= ple have strong opposite opinions.

=C2=A0 =C2=A0<!-- CONDITIONS -->
<= br>
=C2=A0 =C2=A0<!-- TARGET SIP ENTITY -->
=C2= =A0 =C2=A0<xs:element name=3D"TARGET-SIP-ENTITY" type=3D"= xs:anyURI" minOccurs=3D"0"/>

=C2=A0 <!-- CALL IDENTITY -->
=C2= =A0 ...

Thanks

Charles

On Wed, Aug 1, 2012 at 10:56 AM, <= bruno.chatras@orange.com> wrote:
Hi Charles,

"Route" may be a bit misleading as the matching should be perform= ed on the identity or address obtained after applying RFC3263 procedures to= the first value of the route header or to the R-URI rather than on the con= tents the route header as such.

BC


> -----Message d'origine-----
> De=C2=A0: charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De la
> part de Charles Shen
> Envoy=C3=A9=C2=A0: lundi 30 juillet 2012 05:07
> =C3=80=C2=A0: CHATRAS Bruno RD-CORE
> Cc=C2=A0: Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning
> Schulzrinne; Arata Koike
> Objet=C2=A0: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-eve= nt-
> package
>
> Hi Bruno, sorry for the delayed response!
>
> I've updated the local number grouping text. For the multi-path > filtering policy problem, since it will affect texts in multiple
> sections, I'd like to discuss a bit more in terms of the solution.=
>
> Assuming the following scenario,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P3A
> alice@p1 --- P1 --- P2 -- / =C2=A0 =C2=A0 =C2=A0 \ --- P4 --- bob@p4 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ =C2=A0 =C2=A0 =C2= =A0/
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P3B
>
> where P2 can reach bob through either P3A or P3B, the call identity in=
> the existing policy does not distinguish the calls to bob@p4 through > P3A from those through P3B. Therefore it would be good for the load > control
> policy to include not only the call destination (e.g., bob@p4 in
> this case), but also through which path the call is routed.
>
> One possible solution could be to add a new sub-element called
> <route> under the existing <call-identity> schema. In the = simple case,
> the new <route> element can be of the same type as the <ident= ity>
> element in [RFC4745]. The contents of the <route> element holds = what
> you call target SIP entities.
>
> Using the same example above, server P1 may receive a policy
> containing the new element as below:
>
> <call-identity>
> =C2=A0 =C2=A0 <sip>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <to>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <one id=3D"sip:bob@p4.example.c= om">
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </to>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <route>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <many domain=3D"p2.example.com">= ;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <many domain=3D"p3a.example.com"&= gt;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <many domain=3D"p4.example.com">= ;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </route>
> =C2=A0 =C2=A0 </sip>
> </call-identity>
>
>
> Similarly server P2 may receive a policy containing the new element as=
> below:
>
> <call-identity>
> =C2=A0 =C2=A0 <sip>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <to>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <one id=3D"sip:bob@p4.example.c= om">
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </to>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <route>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <many domain=3D"p3a.example.com"&= gt;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <many domain=3D"p4.example.com">= ;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 </route>
> =C2=A0 =C2=A0 </sip>
> </call-identity>
>
>
> Then the call filtering can match both the call destination and the > path (assuming either a SIP Route header is included, or a next hop > SIP server is chosen dynamically).
>
> There is still a small problem though - if the new <route> eleme= nt is
> defined as one of <identity> element in RFC4745, then the <ma= ny>
> sub-elements under it are not ordered, while here we seem to need an > ordered list (as in the list of SIP Route headers). Therefore, we
> might have to define new rules for the <route> element to make i= ts
> sub-elements ordered.
>
> Any thoughts?
>
> Charles
>
>
>
>
>
> On Tue, Jul 17, 2012 at 1:07 PM, =C2=A0<bruno.chatras@orange.com> wrote:<= br> > > Hi Charles,
> >
> > See below.
> >
> >> -----Message d'origine-----
> >> De : charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De
> la
> >> part de Charles Shen
> >> Envoy=C3=A9 : mardi 17 juillet 2012 18:37
> >> =C3=80 : CHATRAS Bruno RD-CORE
> >> Cc : Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning
> >> Schulzrinne; Arata Koike
> >> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control= -event-
> >> package
> >>
> >> Hi Bruno, thank you so much for the detailed review and comme= nts!
> I've
> >> addressed 8 out of the total 10, except the following two whi= ch I'd
> >> appreciate more clarification.
> >>
> >> > 2) Section 5.8, line 525-528
> >> >
> >> > The current text suggests that incoming requests are fil= tered
> >> irrespective of their actual destination. The subscriber shou= ld
> rather
> >> apply filters on requests that are outgoing to the pre-overlo= aded
> >> destination. One solution would be to rephrase the following = text:
> >> >
> >> > "A subscriber receiving the notification first inst= alls these rules
> >> and then filter incoming requests to enforce actions on appro= priate
> >> requests, for example, limiting the sending rate of call requ= ests
> >> destined for a specific SIP entity."
> >> >
> >> > With
> >> >
> >> > "A subscriber receiving the notification first inst= alls these rules
> >> and then filter outgoing requests towards the notifier to enf= orce
> >> actions on appropriate requests, for example, limiting the se= nding
> rate
> >> of call requests destined for a specific SIP entity." > >> >
> >> > This would however not permit the use of external state = agents as
> >> described in section 5.12. Therefore it seems that a "ta= rget sip
> entity"
> >> parameter should be added to overload control documents.
> >> >
> >>
> >> I think I might have not understood your point. The requests = are
> >> filtered based on the call identities, which can convey infor= mation
> >> including the call destination. Could you elaborate what this= "target
> >> sip entity" is exactly for?
> > [BC]
> >
> > Let's take two examples that I think are not covered by the c= urrent
> wording.
> >
> > 1) Example 1
> >
> > Call configuration: A is connected so SP1, B is connected to SP2.= SP1
> and SP2 are connected via SP3. SP3 is connected to an Application Serv= er
> (AS). Under normal load conditions, a call from A to B is routed along=
> the following path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essentia= l
> service and can be bypassed in case of overload.
> >
> > Now let's assume that AS is overloaded and sends to SP3 a fil= ter
> requesting that 50% of INVITE messages be dropped, regardless of the > contents of the from/to/PAI/R-URI.
> >
> > According to the current wording, SP3 will indeed filter 50% of t= he
> INVITE requests while they could be routed to B via SP2.
> >
> > 2) Example 2
> >
> > Call Configuration: An 800 translation service is installed on tw= o
> Application Servers AS-1 and AS-2. A is connected to SP1 and calls 800=
> 1234 4529, which is translated by AS-1 and AS-2 into a regular E164 > number, depending on e.g. the caller's location. SP1 forwards INVI= TE
> requests with R-URI =3D "800 number" to AS-1 or AS-2 based o= n a load
> balancing strategy.
> >
> > As calls to 800 1234 4529 creates a pre-overload condition in AS-= 1,
> AS-1 sends to SP-1 a filter requesting that 50% of calls towards 800 > 1234 4529 be rejected.
> >
> > According to the current wording, SP3 will apply the filter on > incoming INVITE requests, irrespective of whether they are intended to=
> be sent to AS1 or AS2.
> >
> > =3D=3D> It seems that these use cases could be solved by apply= ing the
> filters to outgoing requests (not incoming requests) that are to be > routed to the AS that sent these filters. This means that the SP has t= o
> store the AS address together with the received filters or this addres= s
> has to be included explicitly as a new filter criteria.
> >
> >>
> >>
> >> > 5) Section 6.3.1, local number grouping:
> >> >
> >> > The proposed solution for local numbers is not suitable.= For
> example,
> >> if the phone-context for short service numbers in a country i= s the
> >> country code, the solution does not permit to define a filter= that
> >> excludes all E.164 numbers in that country but retain all sho= rt
> service
> >> numbers. I think we should either define another solution or = state
> that
> >> grouping of local numbers is not supported or state that grou= ping of
> >> local numbers only works under specific assumptions on the us= e of
> phone-
> >> context values.
> >> >
> >>
> >> How about adding the following text?
> >>
> >> It should be noted that the method of grouping local numbers = as
> >> defined in this document does not support all cases. For exam= ple, if
> >> the phone-context for short service numbers in a country is t= he
> >> country code, this solution does not permit to define a filte= r that
> >> excludes all E.164 numbers in that country but retain all sho= rt
> >> service numbers. A complete solution for local number groupin= g
> >> requires a separate method outside the scope of this document= .
> > [BC]
> >
> > Looks OK for me.
> >
> >
> >>
> >>
> >> Thanks!
> >>
> >> Charles
> >>
> >>
> >> On Wed, Jul 11, 2012 at 3:33 AM, =C2=A0<bruno.chatras@orange.com>= ; wrote:
> >> > Hi!
> >> >
> >> > Here are my comments about this I-D.
> >> >
> >> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after = paragraph 5
> >> (i.e. after line 360) and modifies the first two sentences as= follows:
> >> >
> >> > "In the above case, the network entity where load f= iltering policy
> is
> >> first introduced is the SIP server providing access to the re= source
> that
> >> creates the overload condition. In other cases, the network e= ntry
> point
> >> of load filtering policy could also be an entity that hosts t= his
> >> resource. "
> >> >
> >> > 2) Section 5.8, line 525-528
> >> >
> >> > The current text suggests that incoming requests are fil= tered
> >> irrespective of their actual destination. The subscriber shou= ld
> rather
> >> apply filters on requests that are outgoing to the pre-overlo= aded
> >> destination. One solution would be to rephrase the following = text:
> >> >
> >> > "A subscriber receiving the notification first inst= alls these rules
> >> and then filter incoming requests to enforce actions on appro= priate
> >> requests, for example, limiting the sending rate of call requ= ests
> >> destined for a specific SIP entity."
> >> >
> >> > With
> >> >
> >> > "A subscriber receiving the notification first inst= alls these rules
> >> and then filter outgoing requests towards the notifier to enf= orce
> >> actions on appropriate requests, for example, limiting the se= nding
> rate
> >> of call requests destined for a specific SIP entity." > >> >
> >> > This would however not permit the use of external state = agents as
> >> described in section 5.12. Therefore it seems that a "ta= rget sip
> entity"
> >> parameter should be added to overload control documents.
> >> >
> >> > 3) Section 5.8, add the following text (adapted from dra= ft-ietf-
> soc-
> >> overload-control) after line 537:
> >> >
> >> > "When enforcing actions on requests matching the fi= lters,
> subscribers
> >> SHOULD honor the local policy for prioritizing SIP requests s= uch as
> >> policies based on the content of the Resource-Priority header= (RPH,
> >> RFC4412 [RFC4412]). =C2=A0Specific (namespace.value) RPH cont= ents may
> >> indicate high priority requests that should be =C2=A0preserve= d as much as
> >> possible during overload. =C2=A0The RPH contents can also ind= icate 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."
> >> >
> >> > 4) Section 6.3.1, matching identities: After line 699, a= dd the
> >> following text:
> >> >
> >> > "Before evaluating call-identity conditions, the su= bscriber shall
> >> convert URIs received in SIP header fields in canonical form = as per
> RFC
> >> 3261, except that the phone-context parameter shall not be re= moved,
> if
> >> present."
> >> >
> >> > 5) Section 6.3.1, local number grouping:
> >> >
> >> > The proposed solution for local numbers is not suitable.= For
> example,
> >> if the phone-context for short service numbers in a country i= s the
> >> country code, the solution does not permit to define a filter= that
> >> excludes all E.164 numbers in that country but retain all sho= rt
> service
> >> numbers. I think we should either define another solution or = state
> that
> >> grouping of local numbers is not supported or state that grou= ping of
> >> local numbers only works under specific assumptions on the us= e of
> phone-
> >> context values.
> >> >
> >> > 6) Section 6.3.1, line 746 - 753, remove the last but on= e sentence
> and
> >> reword the rest of the text accordingly. Reason: The use of l= ocal
> number
> >> 'tel' URI in the R-URI and To header field is not rar= e. In several
> >> countries, short numbers are used quite extensively to access= special
> >> services.
> >> >
> >> > "Second, use of the local number 'tel' URI = in practice is expected
> to
> >> be rare."
> >> >
> >> > 7) Clause 6.3.3, after line 800, add:
> >> >
> >> > "SUBSCRIBE requests are not filtered if the event-t= ype header field
> >> indicates the event package defined in this document." > >> >
> >> > 8) Section 7, line 985 - 990: replace "call type&qu= ot; with "call
> identity
> >> type" (3 times)
> >> >
> >> > 9) Section 8.1
> >> >
> >> > Line 1048, add "except in specific cases when the I= ntelligent
> Network
> >> architecture is used [AINGR].
> >> >
> >> > Line 1060, remove the last part of the first sentence st= arting with
> >> "and the number of prefix to be matched.": ITU IN s= pecifications
> allow
> >> for dynamic sets.
> >> >
> >> > Line 1068, remove the last part of the first sentence st= aring with
> >> "with a fixed set.": Reason: ITU IN specifications = allow for dynamic
> >> sets.
> >> >
> >> > 10) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Miscellaneous poin= ts
> >> > Section 1, line 106, replace RFC3265 with RFC3261
> >> > Section 4.1, line 231, replace "proxy" with &q= uot;node" (this text
> should
> >> apply to any type of SIP entity)
> >> > Section 4.3, line 265, replace "proxy" with &q= uot;node" (this text
> should
> >> apply to any type of SIP entity)
> >> > Section 4.3, Line 341, replace "singling" with= "signaling"
> >> > Section 4.3, Line 342, replace "all signaling relat= ionship in
> Figure 1
> >> is" with "all signaling relationships in Figure 1 a= re"
> >> > Section 5.6, Line 503, add "request" after &qu= ot;SUBSCRIBE"
> >> > Section 5.11, Line 585, remove "is"
> >> > Section 6.5, Line 851, replace "vliad" with &q= uot;valid"
> >> >
> >> > Bruno
> >> >
> >> >
> >> >> -----Message d'origine-----
> >> >> De : sip-overload-bounces@ietf.org [mailto:sip-overload-
> >> bounces= @ietf.org]
> >> >> De la part de Salvatore Loreto
> >> >> Envoy=C3=A9 : lundi 2 juillet 2012 21:09
> >> >> =C3=80 : sip-overload@ietf.org
> >> >> Cc : Volker Hilt
> >> >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-co= ntrol-event-
> >> package
> >> >>
> >> >> [as chair]
> >> >>
> >> >> based on the mailing list discussion and the one we = had during the
> >> last
> >> >> SoC f2f meeting in Paris,
> >> >> the chairs think the draft-ietf-soc-oload-control-ev= ent-package is
> >> ready
> >> >> for the WGLC.
> >> >>
> >> >> Today we are starting a two-week working group last = call.
> >> >> This call ends on Wednesday, July 16th.
> >> >>
> >> >> the last version of the document can be retrieved he= re:
> >> >> http://tools.ietf.org/html/draft-ie= tf-soc-load-control-event-
> package-
> >> 03
> >> >>
> >> >>
> >> >> reviews and comments are really appreciate and reque= sted from all
> the
> >> >> participants
> >> >>
> >> >>
> >> >> cheers
> >> >> /Sal
> >> >>
> >> >> --
> >> >> Salvatore Loreto, PhD
> >> >> www.sloreto.com
> >> >>
> >> >> _______________________________________________
> >> >> sip-overload mailing list
> >> >> sip-overload@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/sip-over= load
> >> >
> >> >
> >>
> ______________________________________________________________________= __
> >> _________________________________________________
> >> >
> >> > Ce message et ses pieces jointes peuvent contenir des in= formations
> >> 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 j= ointes. 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 confidentia= l 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.
> >> >
> >> > _______________________________________________
> >> > sip-overload mailing list
> >> > sip-overload@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/sip-overload=
> >
> >
> ______________________________________________________________________= __
> _________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des information= s
> 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. L= es
> messages electroniques etant susceptibles d'alteration,
> > France Telecom - Orange decline toute responsabilite si ce messag= e 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 authorisat= ion.
> > If you have received this email in error, please notify the sende= r and
> delete this message and its attachments.
> > As emails may be altered, France Telecom - Orange is not liable f= or
> messages that have been modified, changed or falsified.
> > Thank you.
> >

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 message= s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
sip-overload mailing list
sip-overload@iet= f.org
https://www.ietf.org/mailman/listinfo/sip-overload

--047d7b6044f2dcbbc604cbdf652e-- From charles.newyork@gmail.com Fri Oct 12 09:46:10 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8472821F8738 for ; Fri, 12 Oct 2012 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P6yTwzW3Nli for ; Fri, 12 Oct 2012 09:46:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B05AD21F86A2 for ; Fri, 12 Oct 2012 09:46:09 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4124603vcb.31 for ; Fri, 12 Oct 2012 09:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=f63Dw9TN3mQRcRjZGKEZIdHjYmty+Ks9t1bQcbJiFIA=; b=ltkB1+fobI7uI3K80beMrlf5kqtkGwFzA2w5wjoXFFeRX0zd4zKCH/kRsWbbuqefoS rWejHdyxufgJTKravI7X4FFuCBEwGCzeFpXGh6J10ej6gp3tWS6up6xRn5X+Rq1vG9g3 SXjbhDbUUQI2xUBVeMRRI4NjGQvLB6ASkB1z8W73W9QMFI9p3qzUq/H/VwvWBDDkxol5 agK6PkdaiX1ZE6U5eTspKEZzYlbS7X7dzZ9CwqQ6fzrgfoCAHAf053C53yVDeoR4gVsa vBq5u9JPnCSBLhJ33AS37jKbyXy+BxPn5XUYfourNmSweaXkn9zivzwl50M48yez5MCc XtNw== Received: by 10.58.216.101 with SMTP id op5mr2986927vec.11.1350060369141; Fri, 12 Oct 2012 09:46:09 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Fri, 12 Oct 2012 09:45:48 -0700 (PDT) In-Reply-To: <3484_1343809910_5018E976_3484_3511_1_88CAD1D4E8773F42858B58CAA28272A00680EA@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5016C3F1.4060709@nostrum.com> <3484_1343809910_5018E976_3484_3511_1_88CAD1D4E8773F42858B58CAA28272A00680EA@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Fri, 12 Oct 2012 12:45:48 -0400 X-Google-Sender-Auth: CnUUYj4PE5_lAb0PbfVBOyFm31M Message-ID: To: bruno.chatras@orange.com Content-Type: multipart/alternative; boundary=047d7b6d8daeba614504cbdf6c97 Cc: "SOC \(SIP Overload Control\) WG" , "draft-ietf-soc-load-control-event-package@tools.ietf.org" Subject: Re: [sip-overload] Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:46:10 -0000 --047d7b6d8daeba614504cbdf6c97 Content-Type: text/plain; charset=UTF-8 will update. thanks Charles On Wed, Aug 1, 2012 at 4:31 AM, wrote: > ** ** > > Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly > we can cite an international specification for the discussion of call > gapping -- doesn't Q.1248 cover this?. **** > > *[BC] *As far as Intelligent Networks are concerned, this is covered in > Q.1248.2 (CallGap and CallFiltering procedures). Despite its name, the > first procedure is for gapping service requests towards IN services (e.g. > 800 services), the second procedure enables switch-based call filtering > (to any destination, not just IN services) to be configured by an IN > server. PSTN congestion control is addressed in E.412.**** > > ** ** > > _________________________________________________________________________________________________________________________ > > 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. > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > --047d7b6d8daeba614504cbdf6c97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable will update. thanks

Charles

On Wed, Aug 1, 2012 at 4:31 AM, <bruno.chatras@orange.com> wrote:

=C2=A0

Finally, I note that we cite GR= -2938-CORE at the top of page 24. Certainly we can cite an international sp= ecification for the discussion of call gapping -- doesn't Q.1248 cover this?.

As far as Intel= ligent Networks are concerned, this is covered in Q.1248.2 (CallGap and Cal= lFiltering procedures). Despite its name, the first procedure is for gappin= g service requests towards IN services (e.g. 800 services), the second procedure enables switch-based =C2=A0call = filtering (to any destination, not just IN services) to be configured by an= IN server. =C2=A0PSTN congestion control is addressed in E.412.

=C2= =A0

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload


--047d7b6d8daeba614504cbdf6c97-- From charles.newyork@gmail.com Fri Oct 12 09:53:00 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84021F8712 for ; Fri, 12 Oct 2012 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-jxoeUSo2Xn for ; Fri, 12 Oct 2012 09:52:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4321F8711 for ; Fri, 12 Oct 2012 09:52:59 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4132206vcb.31 for ; Fri, 12 Oct 2012 09:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=0C0bEF5RpXap22lUSJ7pzpC2SWElfqVx1T87Q5QYP9k=; b=pJjL3L44tEWfpiaxaiwEoV9zOOaLMuVuncDvTA3Rb5CAGOiP5EBqcXY6p+sNAYxgxp kNKs7yy4lCHEanEtTj9jW55XWplcG+X6hdYvv2o743bxxBHVTFORN7VuvR9+EWFUG3n1 EjVKVYqX9+G2HwAjWHjGswsz5KC8Cj6YN9zEG6Oj9W8EzW8cEV1IBU9HswW77SDylgYz 4ogKTOUNTFM9rE6pTnt0Pil4k5Bo5V1IDMvqbqKKJjwnzJXwA7EiZvb6YL7IULQCYQN2 llz8L0Fb3VTs+TwJcLyMpZ5Yc+IBBVEOV/DpEbg9sBFQ7NPcT0F50jbiqGNKoO52JgdM +lEw== Received: by 10.52.16.179 with SMTP id h19mr2301709vdd.107.1350060778601; Fri, 12 Oct 2012 09:52:58 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Fri, 12 Oct 2012 09:52:38 -0700 (PDT) From: Charles Shen Date: Fri, 12 Oct 2012 12:52:38 -0400 X-Google-Sender-Auth: NNA5X390yQcn7X61ZzjQamKl8v0 Message-ID: To: bruno.chatras@orange.com, Adam Roach Content-Type: multipart/alternative; boundary=bcaec502d7ba223c5404cbdf8548 Cc: "SOC \(SIP Overload Control\) WG" , "draft-ietf-soc-load-control-event-package@tools.ietf.org" Subject: Re: [sip-overload] (Applicable Initial Methods for Overload Control and Error Code) Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:53:00 -0000 --bcaec502d7ba223c5404cbdf8548 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2012 at 10:10 AM, wrote: > Two comments/questions below.**** > > ** ** > > *De :* sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.or= g] > *De la part de* Adam Roach > *Envoy=C3=A9 :* lundi 30 juillet 2012 19:27 > *=C3=80 :* draft-ietf-soc-load-control-event-package@tools.ietf.org > *Cc :* SOC (SIP Overload Control) WG > *Objet :* [sip-overload] Comments on SOC Event Package**** > > ** > > > Similarly, we run into an issue in which an ACK response to a 200 is > dropped, as doing so will cause the 200 to be retransmitted, which again > exacerbates any overload condition that may arise. In other words, I thin= k > we need to specify that "drop" cannot be applied to ACK (and reject clear= ly > can't, since ACK never sees a response) -- so ACKs must always go through > regardless of overload filters. For the same reason, proxies that receive > an ACK response to a non-200 need to always process the ACK rather than > dropping it.**** > > * * > > * [BC] I don=E2=80=99t think this can happen. The current text says tha= t > =E2=80=9CConditions are evaluated on receipt of an initial SIP request fo= r a dialog > or* > > * standalone transaction=E2=80=9D. So my understanding is that conditions= are not > evaluated on receipt of an ACK. Moreover, the =E2=80=9CACK=E2=80=9D is no= t a valid value > for the element and the current text says that when the > element is not included in a filter, the rule actions are applicable to a= ll > initial methods. A formal definition of initial method may be missing but= I > assume ACK is not an initial method. > > * > Yes, it's a good idea to make it more explicit about the applicable methods. The current draft lists the following methods as possibly subject to control (in the XML schema section) MESSAGE REGISTER SUBSCRIBE OPTIONS PUBLISH Any suggestions for missing or mis-placed method in this list? I will add it explicitly in the main text once we are fine with the list. > * * > > *On the other hand, I=E2=80=99m wondering whether this comment about ACK = should > not be made against draft-ietf-soc-overload-control, section 5.10?* > > > > On to topic of rejects, I note that the current draft simply gives an > example (500 Server Internal Error) rather than specifying how rejection = is > performed. This will make troubleshooting a system more difficult. I > would suggest that we add a new 500-class error code that is used to > indicate this specific situation. We also need to think about whether > "Retry-After" handling is appropriate in this case. I think it is, but we > need to work through how it is set (i.e., is it part of the overload rule= , > or is it set by the server itself?)**** > > * * > > *[BC] Is there any reason for rejecting calls with a different response > code depending on whether overload control information was obtained using > the feedback-based or even-based solution? I guess the answer is no. > Section 5.10.2 of draft-ietf-soc-overload-control says that the SIP serve= r > must reject requests with a 503 response.* > > > > So maybe 503 response code should do for the event-package rejection? Thanks Charles --bcaec502d7ba223c5404cbdf8548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 29, 2012 at 10:10 AM, <= bruno.chatras@orange.com> wrote:

Two comments/questions be= low.

=C2=A0

De=C2=A0:= sip-overload-bounces@ietf.org [mailto:sip-overload-bounce= s@ietf.org] De la part de Adam Roach
Envoy=C3=A9=C2=A0: lundi 30 juillet 2012 19:27
=C3=80=C2=A0: draft-ietf-soc-load-control-event-p= ackage@tools.ietf.org
Cc=C2=A0: SOC (SIP Overload Control) WG
Objet=C2=A0: [sip-overload] Comments on SOC Event Package<= /u>



Similarly, we run into an issue in which an ACK response to a 200 is droppe= d, as doing so will cause the 200 to be retransmitted, which again exacerba= tes any overload condition that may arise. In other words, I think we need = to specify that "drop" cannot be applied to ACK (and reject clearly can't, since ACK never sees a respo= nse) -- so ACKs must always go through regardless of overload filters. For = the same reason, proxies that receive an ACK response to a non-200 need to = always process the ACK rather than dropping it.

=C2=A0

=C2=A0standalone transaction=E2=80=9D. So my under= standing is that conditions are not evaluated on receipt of an ACK. Moreove= r, the =E2=80=9CACK=E2=80=9D is not a valid value for the <method> elem= ent and the current text says that when the <method> element is not i= ncluded in a filter, the rule actions are applicable to all initial methods= . A formal definition of initial method may be missing but I assume ACK is not an initial method.


<= br>
Yes, it's a good idea to make it more explicit about= the applicable methods. The current draft lists the following methods as p= ossibly subject to control (in the XML schema section)

MESSAGE
REGISTER
SUBSCRIBE
OPTIONS
PUBLISH

Any suggestions for mi= ssing or mis-placed method in this list? I will add it explicitly in the ma= in text once we are fine with the list.=C2=A0

=C2=A0

On the other hand, I=E2=80=99m wondering whether t= his comment about ACK should not be made against draft-ietf-soc-overload-co= ntrol, section 5.10?



On to topic of rejects, I note that the current draft simply gives an examp= le (500 Server Internal Error) rather than specifying how rejection is perf= ormed. This will make troubleshooting a system more difficult. I would sugg= est that we add a new 500-class error code that is used to indicate this sp= ecific situation. We also need to think about whether "Retry-After&quo= t; handling is appropriate in this case. I think it is, but we need to work through how it is set (i.e., is it part o= f the overload rule, or is it set by the server itself?)

=C2=A0

[BC] Is there any reason for rejecting call= s with a different response code depending on whether overload control information was obtained using the feedback-based or even-based solution? = I guess the answer is no. Section 5.10.2 of draft-ietf-soc-overload-control= says that the SIP server must reject requests with a 503 response.<= u>




So maybe 503 response code should do for the event-package reje= ction?


Thanks

Charles







--bcaec502d7ba223c5404cbdf8548-- From charles.newyork@gmail.com Fri Oct 12 10:10:44 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741BA21F87B1 for ; Fri, 12 Oct 2012 10:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4DgjZMMc1nY for ; Fri, 12 Oct 2012 10:10:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D41D21F86DF for ; Fri, 12 Oct 2012 10:10:42 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3661544vbb.31 for ; Fri, 12 Oct 2012 10:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JvRR0UNRlURX22dj87LEkmJ4xiVY8opDU0RA6eSV6JI=; b=S3bQQocB/gicHpPhNc9TUcKB63PDB5vPgFE8PjYNLbpK80VsEkbgv7LerNruVdj1yE vijqvdUOtfb+Q5mgk13a2+ExlzkNBIGWPdcrPzG6TxFfGfk9lN5jEIX8AnETmhsw0yFC U3qmZRJzLAq3pAMZ25R6FGKac+pqvGGI1MlEagzZU/uDIdtTfXNyKM2S1Ph2S61J/bWk crYagWwoXmXfp7qf2T9FrWKBWziw5p+tJ0A1gqROguYKS4pOdYUFaH015vvj/O+H25v0 /GZZwN2ITG/f9XIukGT05ywzPgRcPvwtA2cyBLtOjWmF1zG9fY/4ky1NhN7K6csSCw2C UF6Q== Received: by 10.52.96.167 with SMTP id dt7mr2380538vdb.118.1350061841810; Fri, 12 Oct 2012 10:10:41 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Fri, 12 Oct 2012 10:10:20 -0700 (PDT) In-Reply-To: <5016C3F1.4060709@nostrum.com> References: <5016C3F1.4060709@nostrum.com> From: Charles Shen Date: Fri, 12 Oct 2012 13:10:20 -0400 X-Google-Sender-Auth: 9MNfqP1akw7taq0CaVTk0FnOPNI Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=20cf307d03da81872204cbdfc461 Cc: "SOC \(SIP Overload Control\) WG" , draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:10:44 -0000 --20cf307d03da81872204cbdfc461 Content-Type: text/plain; charset=UTF-8 Hi Adam, thanks a lot for your review, sorry I was just able to catch up with the draft. please see detailed reply inline. On Mon, Jul 30, 2012 at 1:27 PM, Adam Roach wrote: > I apologize for coming in so late after WGLC with these comments. > > The first, and most important comment is that this document is presently > based on the obsolete RFC3265. That document has been replaced by RFC 6665. > This has a number of impacts. The first, most obvious one is that the > references to the SIP events document need to be replaced to cite RFC6665 > instead. This also necessitates that the section numbers cited in RFC3265 > need to be updated to match the corresponding sections in 6665. If you have > trouble figuring out where any specific bit of text went, I'll be happy to > point you in the right direction. > > Thank you. the -4 version partially migrated to 6665, the -5 version should complete it with your help. One of the concepts that is now deprecated by 6665 is sharing multiple > subscriptions on the same dialog. This means that the final sentence of the > second paragraph of section 4.3 (starting "The same subscription dialog can > also be used...") needs to be removed. > > Thanks for pointing out the concept change. actually the sentence "The same subscription dialog can also be used to convey policies for multiple different load filtering events in a set of rules (Section 6.1)." is meant to say that same subscription dialog may convey multiple rules (in a ruleset) each for different load filtering events (e.g., applicable to different destinations). Do you still think it is really in conflict with the 6665 change you mentioned? Maybe the sentence should be clarified instead of removed? > Section 5.12 can be removed. The concept of State Agents has been removed > from 6665. > done > > Related to SIP events, but not the 6665 changes: I looked very carefully > for an indication of which Request URI is supposed to be used in the > SUBSCRIBE messages sent for this event package, but saw no guidance. I > suspect that you want a URI of the form "sip:server.example.com" (i.e., > without a user) where "server.example.com" represents the server whose > overload state is being requested. Full example messages would help to make > this clearer. > > Below is the flow I plan to add to Section 6.5, please see if they suffice atlanta biloxi | F1 SUBSCRIBE | |------------------------>| | F2 200 OK | |<------------------------| | F3 NOTIFY | |<------------------------| | F4 200 OK | |------------------------>| F1 SUBSCRIBE atlanta.example.com -> biloxi.example.com SUBSCRIBE sip:biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy7cjbu3 From: sip:atlanta.example.com;tag=162ab5 To: sip:biloxi.example.com Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2012 SUBSCRIBE Contact: sip:atlanta.example.com Event: load-control Max-Forwards: 70 Accept: application/load-control+xml Expires: 3600 Content-Length: 0 F2 200 OK biloxi.example.com -> atlanta.example.com SIP/2.0 200 OK Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy7cjbu3 ;received=192.0.2.1 To: ;tag=331dc8 From: ;tag=162ab5 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2012 SUBSCRIBE Expires: 3600 Contact: sip:biloxi.example.com Content-Length: 0 F3 NOTIFY biloxi.example.com -> atlanta.example.com NOTIFY sip:atlanta.example.com SIP/2.0 Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy71g2ks From: ;tag=331dc8 To: ;tag=162ab5 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com Event: load-control Subscription-State: active;expires=3599 Max-Forwards: 70 CSeq: 1775 NOTIFY Contact: sip:biloxi.example.com Content-Type: application/load-control+xml Content-Length: ... [Load Control Document] F4 200 OK atlanta.example.com -> biloxi.example.com SIP/2.0 200 OK Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy71g2ks ;received=192.0.2.2 From: ;tag=331dc8 To: ;tag=162ab5 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1775 NOTIFY Content-Length: 0 > The second paragraph on page 13 effectively turns the soft state mechanism > of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as > you can end up with a situation in which a communication disruption (say, a > change in authentication) can lead to persistent throttling when it is not > appropriate to do so. This artificially limits throughput, which is > somewhat counter to what the overload control effort is supposed to do. > What is the justification for keeping state beyond the duration of a > subscription? > The reason behind the existing text is to separate the contents that the mechanism conveys from the mechanism itself. With the current text, the situtaion you mentioned should be avoided by requiring the Notifier sending explicit filter modification messages while the subscription is still in place. However, I am fine revising it to state that terminating the Subscribe/Notify relationship also requires the subscriber to terminate all the filtering rules from the specific Notifier. > The third paragraph on page 13 says that a NOTIFY request that does not > contain a body MUST be ignored. In contrast, section 4.3 says that a > notification includes an empty body indicates that no overload rules are in > effect. These statements are in conflict with each other, unless you are > intending to distinguish between a message containing an *empty* (but > present) body, and a message that does not contain a body. If that's the > distinction being made, you need to be far more explicit that such is the > intention. I would strongly counsel against such a decision; even if the > difference is made clear in the text, it is such a subtle distinction that > it is unlikely to be implemented correctly. > > OK. So how about combining them to "a NOTIFY request that does not contain a body or contains an empty body indicates that no filtering rules need to be updated."? Unrelated to the 6665 issues, I have some additional comments. At the top > of page 9, there is a statement that the proxies to which proxies should > subscribe can be learned from the signaling messages sent and received. I > think we need some guidance about when this learned information can be > purged. Presumably we don't want a single interaction between proxies to > result in a subscription that is kept in place for the rest of all time. > > I agree. We can add a sentence requiring the SIP entities to decide on when the relationship information needs to be purged (e.g., after certain period of inactivity). I am not sure if we need to/can specify a "standard" value for that inactivity period, do you have any thoughts? > Near the top of page 16, the document specifies that elements containing > multiple , , and elements are ORed together. I don't > think this is quite what you intend. If you have a and an , > you don't really want to match everything that is in the OR > everything excluded by the . I can kind of figure out what you > really meant, but the language needs to be adjusted to actually say it. > > Good point, possible update as the following: ... When the , , and elements contain multiple or sub-elements, the result is also combined using logical OR. When the sub-element further contains one or more sub-elements, the result of each sub-element is combined using a logical OR, similar to that of the element in ... On page 19, one of the specified actions is "drop." There is passing > implication that doing this over an unreliable link will cause > retransmissions. This needs more treatment in the text. In fact, as > dropping requests over an unreliable link will *always* make overload worse > rather than better, I would strongly recommend that we add text that > specifies that any "drop" rule applied to an unreliable transport MUST be > treated as if it were "reject." > MUST is a bit strong, but it seems to make sense. Here is the proposed revised text: "If the "alt-action" value is "drop", it should be noted that when running SIP over an unreliable transport such as UDP, using the "drop" action will create message retransmissions that further worsen the overload situation. Therefore, any "drop" action applied to an unreliable transport MUST be treated as if it were "reject." > > Similarly, we run into an issue in which an ACK response to a 200 is > dropped, as doing so will cause the 200 to be retransmitted, which again > exacerbates any overload condition that may arise. In other words, I think > we need to specify that "drop" cannot be applied to ACK (and reject clearly > can't, since ACK never sees a response) -- so ACKs must always go through > regardless of overload filters. For the same reason, proxies that receive > an ACK response to a non-200 need to always process the ACK rather than > dropping it. > > On to topic of rejects, I note that the current draft simply gives an > example (500 Server Internal Error) rather than specifying how rejection is > performed. This will make troubleshooting a system more difficult. I would > suggest that we add a new 500-class error code that is used to indicate > this specific situation. > see response on a separate thread. > We also need to think about whether "Retry-After" handling is appropriate > in this case. I think it is, but we need to work through how it is set > (i.e., is it part of the overload rule, or is it set by the server itself?) > > I personally think "Retry-After" maybe something more appropriate for the server itself, as the overload control rules might be relatively static here. > Finally, I note that we have a "forward" rule. I think we would be well > served by a very similar "redirect" rule that sends a 300-class response > rather than forwarding the request to an alternate destination. > > That makes sense. So I am changing it to: "When the "alt-action" value is "redirect", an "alt-target" attribute MUST be defined. The "alt-target" specifies a list of one or more URIs where the request should be redirected. The server responds to the filtered request with a 300-class response message containing the list of redirection URIs, as in the behavior of a SIP redirect server." and also define the alt-target as a list of URIs where the requests can be redirected to. > Small editorial nit: while the use of the date "79 AD" in the example at > the top of page 21 is both clever and amusing to those who have both > received an education on the topic of Vesuvius' destruction of Pompeii and > recall its details, the use of a two-digit year in an example is likely to > lead to confusion on the part of implementors. We really don't need > examples from which implementors might incorrectly infer that omitting the > century portion of the year in ISO-style dates is acceptable. > OK, I will change it to Katrina in 2005, hope it will be a better example. > > Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly > we can cite an international specification for the discussion of call > gapping -- doesn't Q.1248 cover this?. It seems a bit provincial to use a > Bellcore spec to the exclusion of an ITU-T spec in the context of a > document to be published by an international standards body such as the > IETF. > Done. Thanks! Charles > > > /a > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > --20cf307d03da81872204cbdfc461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adam, thanks a lot for your review, sorry I was just able to catch up wi= th the draft. please see detailed reply inline.

On Mon, Jul 30, 2012 at 1:27 PM, Adam Roach <adam@nostrum.com>= ; wrote:
=20 =20 =20
I apologize for coming in so late after WGLC with these comments.

The first, and most important comment is that this document is presently based on the obsolete RFC3265. That document has been replaced by RFC 6665. This has a number of impacts. The first, most obvious one is that the references to the SIP events document need to be replaced to cite RFC6665 instead. This also necessitates that the section numbers cited in RFC3265 need to be updated to match the corresponding sections in 6665. If you have trouble figuring out where any specific bit of text went, I'll be happy to point you in the right direction.


Thank you. the -4 version pa= rtially migrated to 6665, the -5 version should complete it with your help.=


One of the concepts that is now deprecated by 6665 is sharing multiple subscriptions on the same dialog. This means that the final sentence of the second paragraph of section 4.3 (starting "The sam= e subscription dialog can also be used...") needs to be removed.


Thanks for pointing out= the concept change. actually the sentence "The same subscription dial= og can also be used to convey policies for multiple different load filterin= g events in a set of rules (Section 6.1)." is meant to say that same s= ubscription dialog may convey multiple rules (in a ruleset) each for differ= ent load filtering events (e.g., applicable to different destinations). Do = you still think it is really in conflict with the 6665 change you mentioned= ? Maybe the sentence should be clarified instead of removed? =C2=A0 =C2=A0<= /div>
=C2=A0
Section 5.12 can be removed. The concept of State Agents has been removed from 6665.

done
=
=C2=A0

Related to SIP events, but not the 6665 changes: I looked very carefully for an indication of which Request URI is supposed to be used in the SUBSCRIBE messages sent for this event package, but saw no guidance. I suspect that you want a URI of the form "sip:server.example.com" (i.e., without a user) where "server.ex= ample.com" represents the server whose overload state is being requested. Full example messages would help to make this clearer.



Below is= the flow I plan to add to Section 6.5, please see if they suffice=C2=A0

=C2=A0 =C2=A0atlanta =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0biloxi
=C2=A0 =C2=A0 =C2=A0 | F1 SUBSCRIB= E | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 |------------------------>| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2= =A0 =C2=A0 | F2 200 OK =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 = =C2=A0 |<------------------------| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 | F3 NOTI= FY =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 |<------------------------| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2= =A0 =C2=A0 | F4 200 OK =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2= =A0 |------------------------>| =C2=A0 =C2=A0

= =C2=A0 =C2=A0F1 SUBSCRIBE atlanta.ex= ample.com -> biloxi.example.co= m

=C2=A0 =C2=A0 =C2=A0 SUBSCRIBE sip:biloxi.example.com SIP/2.0
=C2=A0 =C2=A0 = =C2=A0 Via: SIP/2.0/TCP atlanta.exam= ple.com;branch=3Dz9hG4bKy7cjbu3
=C2=A0 =C2=A0 =C2=A0 From: sip:= atlanta.example.com;tag=3D162ab5
=C2=A0 =C2=A0 =C2=A0 To: sip= :biloxi.example.com
=C2= =A0 =C2=A0 =C2=A0 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
=C2=A0 =C2=A0 =C2=A0 CSeq: 2012 SUBSCRIBE
=C2=A0 =C2=A0 =C2= =A0 Contact: sip:atlanta.example.com=
=C2=A0 =C2=A0 =C2=A0 Event: load-control
=C2=A0 = =C2=A0 =C2=A0 Max-Forwards: 70
=C2=A0 =C2=A0 =C2=A0 Accept: appli= cation/load-control+xml
=C2=A0 =C2=A0 =C2=A0 Expires: 3600
=C2=A0 =C2=A0 =C2=A0 Cont= ent-Length: 0

=C2=A0 =C2=A0F2 200 OK =C2=A0 biloxi.example.com -> atlanta.example.com

=C2=A0 =C2=A0 =C2=A0 SIP/2.0 200 OK
=C2=A0 = =C2=A0 =C2=A0 Via: SIP/2.0/TCP biloxi= .example.com;branch=3Dz9hG4bKy7cjbu3
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 ;received=3D192.0.2.1
=C2=A0 =C2=A0 =C2=A0 To: <sip:biloxi.example.com>;tag=3D331dc8
=C2=A0 =C2=A0 =C2=A0 From: <sip:atlanta.example.com>;tag=3D162ab5
=C2=A0 =C2=A0 =C2=A0= Call-ID: 2xTb9vxS= it55XU7p8@atlanta.example.com
=C2=A0 =C2=A0 =C2=A0 CSeq: 2012 SUBSCRIBE
=C2=A0 =C2=A0 =C2= =A0 Expires: 3600
=C2=A0 =C2=A0 =C2=A0 Contact: sip:biloxi.example.com
=C2=A0 =C2=A0 =C2= =A0 Content-Length: 0

=C2=A0 =C2=A0F3 NOTIFY =C2= =A0biloxi.example.com -> atlanta.example.com

=C2=A0 =C2=A0 =C2=A0 NOTIFY sip:atlanta.example.com SIP/2.0
=C2=A0 =C2=A0 =C2= =A0 Via: SIP/2.0/TCP biloxi.example.c= om;branch=3Dz9hG4bKy71g2ks
=C2=A0 =C2=A0 =C2=A0 From: <sip:biloxi.example.com>;tag=3D331dc8
=C2=A0 =C2=A0 =C2=A0 T= o: <sip:atlanta.example.com&g= t;;tag=3D162ab5
=C2=A0 =C2=A0 =C2=A0 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com=
=C2=A0 =C2=A0 =C2=A0 Event: load-control
=C2=A0 =C2=A0 =C2= =A0 Subscription-State: active;expires=3D3599
=C2=A0 =C2=A0 =C2= =A0 Max-Forwards: 70
=C2=A0 =C2=A0 =C2=A0 CSeq: 1775 NOTIFY
=
=C2=A0 =C2=A0 =C2=A0 Contact: sip:biloxi.example.com
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/load-control+xml
<= div>=C2=A0 =C2=A0 =C2=A0 Content-Length: ...

=C2= =A0 =C2=A0 =C2=A0 [Load Control Document]

=C2=A0 = =C2=A0F4 200 OK atlanta.example.com<= /a> -> biloxi.example.com=C2= =A0

=C2=A0 =C2=A0 =C2=A0 SIP/2.0 200 OK
=C2=A0 = =C2=A0 =C2=A0 Via: SIP/2.0/TCP atlan= ta.example.com;branch=3Dz9hG4bKy71g2ks
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 ;received=3D192.0.2.2
=C2=A0 =C2=A0 =C2=A0 From: <sip:<= a href=3D"http://biloxi.example.com">biloxi.example.com>;tag=3D331dc= 8
=C2=A0 =C2=A0 =C2=A0 To: <sip:atlanta.example.com>;tag=3D162ab5
=C2=A0 =C2=A0 =C2=A0 C= all-ID: 2xTb9vxSit= 55XU7p8@atlanta.example.com
=C2=A0 =C2=A0 =C2=A0 CSeq: 1775 NOTIFY
=C2=A0 =C2=A0 =C2=A0 = Content-Length: 0

=C2=A0
The second paragraph on page 13 effectively turns the soft state mechanism of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as you can end up with a situation in which a communication disruption (say, a change in authentication) can lead to persistent throttling when it is not appropriate to do so. This artificially limits throughput, which is somewhat counter to what the overload control effort is supposed to do. What is the justification for keeping state beyond the duration of a subscription?


=
The reason behind the existing text is to separate the contents that t= he mechanism conveys from the mechanism itself. With the current text, the = situtaion you mentioned should be avoided by requiring the Notifier sending= explicit filter modification messages while the subscription is still in p= lace. However, I am fine revising it to state that terminating the Subscrib= e/Notify relationship also requires the subscriber to terminate all the fil= tering rules from the specific Notifier. =C2=A0 =C2=A0


The third paragraph on page 13 says that a NOTIFY request that does not contain a body MUST be ignored. In contrast, section 4.3 says that a notification includes an empty body indicates that no overload rules are in effect. These statements are in conflict with each other, unless you are intending to distinguish between a message containing an *empty* (but present) body, and a message that does not contain a body. If that's the distinction being made, you need to be far more explicit that such is the intention. I would strongly counsel against such a decision; even if the difference is made clear in the text, it is such a subtle distinction that it is unlikely to be implemented correctly.


=C2=A0OK. So how about = combining them to "a NOTIFY request that does not contain a body or co= ntains an empty body indicates that no filtering rules need to be updated.&= quot;?=C2=A0

Unrelated to the 6665 issues, I have some additional comments. At the top of page 9, there is a statement that the proxies to which proxies should subscribe can be learned from the signaling messages sent and received. I think we need some guidance about when this learned information can be purged. Presumably we don't want a singl= e interaction between proxies to result in a subscription that is kept in place for the rest of all time.


I agree. We can add a s= entence requiring the SIP entities to decide on when the relationship infor= mation needs to be purged (e.g., after certain period of inactivity). I am = not sure if we need to/can specify a "standard" value for that in= activity period, do you have any thoughts? =C2=A0

=C2=A0
Near the top of page 16, the document specifies that elements containing multiple <one>, <except>, and <many> elements are ORed together. I don't think this is quite what you intend. If you have a <many> and an <except>, you don't really want to match everything that is in the <many> OR everything excluded by the <exclude>. I can kind of figure out what you really meant, but the language needs to be adjusted to actually say it.


Good point, possible up= date as the following: =C2=A0

... When the <fro= m>, <to>, <request-uri> and <p-asserted-identity> elem= ents contain multiple <one> or <many> sub-elements, the result = is also combined using logical OR. When the <many> sub-element furthe= r contains one or more <except> sub-elements, the result of each <= except> sub-element is combined using a logical OR, similar to that of t= he <identity> element in <xref target=3D"RFC4745"/>..= .=C2=A0

On page 19, one of the specified actions is "drop." There is = passing implication that doing this over an unreliable link will cause retransmissions. This needs more treatment in the text. In fact, as dropping requests over an unreliable link will *always* make overload worse rather than better, I would strongly recommend that we add text that specifies that any "drop" rule applied to an unreliable transport MUST be treated as if it were "reject."<= br>

MUST is a bit strong, but it= seems to make sense. Here is the proposed revised text:=C2=A0
"If the "alt-action" value is "drop", i= t should be noted that when running SIP over an unreliable transport such a= s UDP, using the "drop" action will create message retransmission= s that further worsen the overload situation. Therefore, any "drop&quo= t; action applied to an unreliable transport MUST be treated as if it were = "reject."
=C2=A0

Similarly, we run into an issue in which an ACK response to a 200 is dropped, as doing so will cause the 200 to be retransmitted, which again exacerbates any overload condition that may arise. In other words, I think we need to specify that "drop" cannot be appli= ed to ACK (and reject clearly can't, since ACK never sees a response) -- so ACKs must always go through regardless of overload filters. For the same reason, proxies that receive an ACK response to a non-200 need to always process the ACK rather than dropping it.

On to topic of rejects, I note that the current draft simply gives an example (500 Server Internal Error) rather than specifying how rejection is performed. This will make troubleshooting a system more difficult. I would suggest that we add a new 500-class error code that is used to indicate this specific situation.

see response on a separate thread.

=C2=A0
We also need to think about whether "Retry-After" handling is appropriate in = this case. I think it is, but we need to work through how it is set (i.e., is it part of the overload rule, or is it set by the server itself?)


I personally think &quo= t;Retry-After" maybe something more appropriate for the server itself,= as the overload control rules might be relatively static here. =C2=A0
=C2=A0
Finally, I note that we have a "forward" rule. I think we wou= ld be well served by a very similar "redirect" rule that sends a 30= 0-class response rather than forwarding the request to an alternate destination.


That makes sense. So I = am changing it to:=C2=A0

"When the "alt-= action" value is "redirect", an "alt-target" attri= bute MUST be defined. The "alt-target" specifies a list of one or= more URIs where the request should be redirected. The server responds to t= he filtered request with a 300-class response message containing the list o= f redirection URIs, as in the behavior of a SIP redirect server."

and also define the alt-target as a list of URIs where = the requests can be redirected to.

=C2=A0 =C2=A0&l= t;xs:attribute name=3D"alt-target" type=3D"alt-target-type&q= uot; use=3D"optional"/>

=C2=A0 =C2=A0<!-- ALT TARGET TYPE -->
= =C2=A0 =C2=A0<xs:simpleType name=3D"alt-target-type">
=
=C2=A0 =C2=A0 =C2=A0 <xs:list itemType=3D"xs:anyURI"/>=
=C2=A0 =C2=A0</xs:simpleType>

=C2=A0
Small editorial nit: while the use of the date "79 AD" in the example at the top of page 21 is both clever and amusing to those who have both received an education on the topic of Vesuvius' destruction of Pompeii and recall its details, the use of a two-digit year in an example is likely to lead to confusion on the part of implementors. We really don't need examples from which implementors might incorrectly infer that omitting the century portion of the year in ISO-style dates is acceptable.


OK, I will change it to Katrin= a in 2005, hope it will be a better example.=C2=A0

=C2=A0

Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly we can cite an international specification for the discussion of call gapping -- doesn't =20 Q.1248 cover this?. It seems a bit provincial to use a Bellcore spec to the exclusion of an ITU-T spec in the context of a document to be published by an international standards body such as the IETF.

=
Done.

Thanks!

<= div>Charles
=C2=A0


/a

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload


--20cf307d03da81872204cbdfc461-- From jgunn6@csc.com Fri Oct 12 12:02:44 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7319D21F8733 for ; Fri, 12 Oct 2012 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9M8NeN5qH+b for ; Fri, 12 Oct 2012 12:02:43 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5641821F8704 for ; Fri, 12 Oct 2012 12:02:43 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-8.tower-86.messagelabs.com!1350068562!54845870!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10408 invoked from network); 12 Oct 2012 19:02:42 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-8.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Oct 2012 19:02:42 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9CJ2c7u011855; Fri, 12 Oct 2012 15:02:40 -0400 In-Reply-To: References: To: Charles Shen MIME-Version: 1.0 X-KeepSent: 650ED4FD:A6C4D18B-85257A95:006810B2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Fri, 12 Oct 2012 15:02:38 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 10/12/2012 02:58:22 PM, Serialize complete at 10/12/2012 02:58:22 PM Content-Type: multipart/alternative; boundary="=_alternative 00689C1185257A95_=" Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] (reorder/recorder) draft-ietf-soc-load-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:02:44 -0000 This is a multipart message in MIME format. --=_alternative 00689C1185257A95_= Content-Type: text/plain; charset="US-ASCII" I bit of a tangent, but my father had a device on his (US) phone, which generated the "reorder tone" every time you picked up the phone (whether to answer a call or make a call). Irritating as anything to those of us who called him , as we have been unconsciously trained to interpret that tone as "wrong number" and hang up. Also irritating when you were making a call from his phone. But he claimed it did cut way back on the robo-calls. Janet ... 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. --=_alternative 00689C1185257A95_= Content-Type: text/html; charset="US-ASCII" I bit of a tangent, but my father had a device on his (US) phone, which generated the "reorder tone" every time you picked up the phone (whether to answer a call or make a call).

Irritating as anything to those of us who called him , as we have been unconsciously trained to interpret that tone as "wrong number" and hang up.  Also irritating when you were making a call from his phone.

But he claimed it did cut way back on the robo-calls.

Janet

...


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.
--=_alternative 00689C1185257A95_=-- From internet-drafts@ietf.org Wed Oct 17 11:55:54 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668E921F85C2; Wed, 17 Oct 2012 11:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0xPWIJbmKUd; Wed, 17 Oct 2012 11:55:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37CF21F8682; Wed, 17 Oct 2012 11:55:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017185553.10506.63222.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 11:55:53 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-03.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:55:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-03.txt Pages : 15 Date : 2012-10-17 Abstract: The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-09] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-09]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ecnoel@research.att.com Wed Oct 17 11:59:52 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F261821F86AD for ; Wed, 17 Oct 2012 11:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWCrG6lKmsOn for ; Wed, 17 Oct 2012 11:59:51 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5192921F867E for ; Wed, 17 Oct 2012 11:59:51 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 1D44A12037A for ; Wed, 17 Oct 2012 14:59:50 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 44FE8E3E45 for ; Wed, 17 Oct 2012 14:56:11 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Wed, 17 Oct 2012 14:59:18 -0400 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Wed, 17 Oct 2012 14:59:17 -0400 Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-03.txt Thread-Index: Ac2smPmwk/+aKqKaTASSyWngukacOAAAEDWg Message-ID: <5EBD159DE88147488A3B1590E0900184031C9979F63E@njfpsrvexg2.research.att.com> References: <20121017185553.10506.63222.idtracker@ietfa.amsl.com> In-Reply-To: <20121017185553.10506.63222.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-03.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:59:52 -0000 Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control: URL: http://www.ietf.org/internet-drafts/draft-ietf-soc-overloa= d-rate-control-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-soc-overload-ra= te-control Htmlized: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-co= ntrol-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload= -rate-control-03 Changes were editorial. Comments and/or suggestions would be most appreciated. Thanks, Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Wednesday, October 17, 2012 2:56 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-03= .txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-03.txt Pages : 15 Date : 2012-10-17 Abstract: The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-09] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-09]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From internet-drafts@ietf.org Mon Oct 22 09:32:19 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1F21F849D; Mon, 22 Oct 2012 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTTX3+Wobsol; Mon, 22 Oct 2012 09:32:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7BB21F8674; Mon, 22 Oct 2012 09:32:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:32:17 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:32:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : A Session Initiation Protocol (SIP) Load Control Event P= ackage Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-05.txt Pages : 39 Date : 2012-10-22 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-packag= e-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From charles.newyork@gmail.com Mon Oct 22 09:47:17 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF5421F84D6 for ; Mon, 22 Oct 2012 09:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcdbhxvFTOoD for ; Mon, 22 Oct 2012 09:47:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7C21F8904 for ; Mon, 22 Oct 2012 09:47:15 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3505642vcb.31 for ; Mon, 22 Oct 2012 09:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=LnV7QI7VlZa/WehHGTLptkuwHG2fcFtoRfLx0HI+wi0=; b=RKXl4eqkxOH86Qi6yYm2sx5h57PC7cWI06PNJsfkZ5lHSalqqOLAmP/s8Xe1rfwjch ymG+v6rM65Fh+9I9WTFYglDMKn94qEPoW6KMUm08LJCGqb1kc+1TOwoxDoije6e9DkgU +EUnq5gA/z8J/ug+1OCA11aTST2BDIDL/PoJ7f6NTEQ/iti8NTCwB+0GBI3S87ye/Fai VueWv+5mJTHQ3cwp1Pb/cfehHuzLGVMNyG7X28eBVAnpcLz+llQ8WEkvmBHz3QgwmGNw TTN22Je4EMLxYQ/Ksqa01jMOc25WYh0V8tzWd1EehX8KgxtzC9W/8Fq4o0YqrPi8pJ+a 4/eQ== Received: by 10.220.155.132 with SMTP id s4mr15983569vcw.15.1350924433867; Mon, 22 Oct 2012 09:47:13 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.219.104 with HTTP; Mon, 22 Oct 2012 09:46:53 -0700 (PDT) In-Reply-To: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> From: Charles Shen Date: Mon, 22 Oct 2012 12:46:53 -0400 X-Google-Sender-Auth: 2CkWIPOI4BD4SXjFVBB72F1YkIg Message-ID: To: sip-overload@ietf.org Content-Type: multipart/alternative; boundary=f46d043c8222ffc45e04cca89ab0 Cc: Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:47:17 -0000 --f46d043c8222ffc45e04cca89ab0 Content-Type: text/plain; charset=UTF-8 Hi all, I've submitted a new version of draft-ietf-soc-load-control-event-package. Diff is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-load-control-event-package-05 This version should have incorporated responses to all comments received so far (please let me know if I missed anything). Main changes include adding: 6.3.3 (target-sip-entity, currently optional) 6.5.2 (example message flow), removing 5.12 (state agent), as well as changes and clarifications in a number of other sections, e.g., 6.3.2 (explicit list of method types subjected to control) 6.4 (using redirect as alternative action), 5.8 (terminating policies upon termination of subscription) and 13.2 PSTN references. Comments are welcome ! Charles On Mon, Oct 22, 2012 at 12:32 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Overload Control Working Group of > the IETF. > > Title : A Session Initiation Protocol (SIP) Load Control > Event Package > Author(s) : Charles Shen > Henning Schulzrinne > Arata Koike > Filename : draft-ietf-soc-load-control-event-package-05.txt > Pages : 39 > Date : 2012-10-22 > > Abstract: > We define a load control event package for the Session Initiation > Protocol (SIP). It allows SIP servers to distribute load filters to > other SIP servers in the network. The load filters contain rules to > throttle calls based on their source or destination domain, telephone > number prefix or for a specific user. The mechanism helps to prevent > signaling overload and complements feedback-based SIP overload > control efforts. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-load-control-event-package-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > --f46d043c8222ffc45e04cca89ab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I've submitted a new version of= =C2=A0draft-ietf-soc-load-control-event-package.=C2=A0

=

This version should have incorporated responses to all = comments received so far (please let me know if I missed anything). Main ch= anges include adding:=C2=A06.3.3 (target-sip-entity, currently optional)=C2= =A06.5.2 (example message flow),=C2=A0removing=C2=A05.12 (state agent), as = well as changes and clarifications in a number of other sections, e.g.,=C2= =A06.3.2 (explicit list of method types subjected to control) 6.4 (using re= direct as alternative action), 5.8 (terminating policies upon termination o= f subscription) and 13.2 PSTN references.=C2=A0

Comments are welcome !

Charles=




On M= on, Oct 22, 2012 at 12:32 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the SIP Overload Control Working Group o= f the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A Se= ssion Initiation Protocol (SIP) Load Control Event Package
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Charles Shen =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henning Schulzrinne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Arata Koike
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-soc-load-control-event-package-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 39 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2012-10-22

Abstract:
=C2=A0 =C2=A0We define a load control event package for the Session Initiat= ion
=C2=A0 =C2=A0Protocol (SIP). =C2=A0It allows SIP servers to distribute load= filters to
=C2=A0 =C2=A0other SIP servers in the network. =C2=A0The load filters conta= in rules to
=C2=A0 =C2=A0throttle calls based on their source or destination domain, te= lephone
=C2=A0 =C2=A0number prefix or for a specific user. =C2=A0The mechanism help= s to prevent
=C2=A0 =C2=A0signaling overload and complements feedback-based SIP overload=
=C2=A0 =C2=A0control efforts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-s= oc-load-control-event-package

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-soc-load-c= ontrol-event-package-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-soc-load-control-event-package-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--f46d043c8222ffc45e04cca89ab0-- From internet-drafts@ietf.org Mon Oct 22 10:34:26 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22CC21F89CE; Mon, 22 Oct 2012 10:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU2mnh-uytcF; Mon, 22 Oct 2012 10:34:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4221F894D; Mon, 22 Oct 2012 10:34:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022173424.19810.60302.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:34:24 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-10.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:34:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Overload Control Author(s) : Vijay K. Gurbani Volker Hilt Henning Schulzrinne Filename : draft-ietf-soc-overload-control-10.txt Pages : 34 Date : 2012-10-22 Abstract: Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-control-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-control-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vkg@bell-labs.com Mon Oct 22 10:43:22 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495DC21F88AF for ; Mon, 22 Oct 2012 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.144 X-Spam-Level: X-Spam-Status: No, score=-109.144 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmlvtzTraR1O for ; Mon, 22 Oct 2012 10:43:21 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB9321F889F for ; Mon, 22 Oct 2012 10:43:20 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q9MHhKdW012527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Oct 2012 12:43:20 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q9MHhJAA032463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Oct 2012 12:43:20 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q9MHhJU9024567 for ; Mon, 22 Oct 2012 12:43:19 -0500 (CDT) Message-ID: <508585F5.3030109@bell-labs.com> Date: Mon, 22 Oct 2012 12:44:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [sip-overload] Revised I-D (-10) for draft-ietf-soc-overload-control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:43:22 -0000 All: I have posted a revised version of draft-ietf-soc-overload-control. Version -10 is available at [1]. The major change in this version is an update to the loss control algorithm driven by a review from Janet Gunn. An added benefit is that the updated algorithm is a bit simpler from the previous one. Janet did an exhaustive review of the rest of the document and suggested text changes for other sections as well. I have incorporated the applicable changes upto Section 4; I will incorporate remaining changes, as applicable, in a later revision. However, I wanted to get this version out for the benefit of others reviewing the algorithm. A diff between -09 and -10 is at [2]. [1] http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-10.txt [2] http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-control-10 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/