From jgunn6@csc.com Thu Nov 12 15:54:25 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C253A682F; Thu, 12 Nov 2009 15:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGilRs7bR0yR; Thu, 12 Nov 2009 15:54:24 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 036083A6784; Thu, 12 Nov 2009 15:54:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-171.messagelabs.com!1258070088!18749039!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 17725 invoked from network); 12 Nov 2009 23:54:49 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Nov 2009 23:54:49 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nACNsmx5015380; Thu, 12 Nov 2009 18:54:48 -0500 In-Reply-To: <4AE7055E.9060208@alcatel-lucent.com> References: <4AE7055E.9060208@alcatel-lucent.com> To: Volker Hilt MIME-Version: 1.0 X-KeepSent: 84BD02F3:1BF989D2-8525766C:00820708; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Thu, 12 Nov 2009 18:54:45 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 11/12/2009 06:56:12 PM, Serialize complete at 11/12/2009 06:56:12 PM Content-Type: multipart/alternative; boundary="=_alternative 00835B9D8525766C_=" Cc: sip-overload-bounces@ietf.org, "sip-overload@ietf.org" Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 23:54:25 -0000 This is a multipart message in MIME format. --=_alternative 00835B9D8525766C_= Content-Type: text/plain; charset="US-ASCII" With regard to A Session Initiation Protocol (SIP) Load Control Event Package draft-shen-sipping-load-control-event-package-03.txt I have concerns about a number of the basic premises. First, the approach seems to depend on landline "telephone numbers" and "Tel URIs". 1- It seems that load control should apply to ALL SIP sessions, not just voice calls with an associated phone number (or even a Tel URI) 2-It is no longer reasonable to assume a mapping between "telephone number" and "location" or a particular SIP proxy. A mobile phone could be anywhere- the number is not at all related to which SIP proxy it is using. And even number portability for landline phones makes it a less useful mapping. 3- It might be more practical to invoke the load controls based on the next/previous SIP proxy or SIP server, rather than some representation of the "phone number". Second, the approach propagates the load controls from one SIP Proxy to the adjacent ones. The first example given is an "acceptable call rate" to a TV program "hotline". The SIP proxy then "allocates" the acceptable call rate among its neighbors. I think that propagating the load controls across multiple proxies is likely to create more problems than it solves 1- It is highly unlikely that the actual call rate is uniformly, or even predictably, distributed among the neighbors. This means that it is highly likely that some of the neighbors will have a bigger call rate to the TV hot line, meaning they will block calls, while others will have lower volume, and will not need to block calls. The call rate at the TV hotline will then be below the "acceptable call rate", and there will be many calls that were unnecessarily blocked. This concern also applies to the second example given. Finally, your approach make no mention of exempting SIP requests with particular RPH values form these load controls, as required by Req 13 of RFC 5390. Thanks Janet sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM: > [image removed] > > [sip-overload] Expert Review for Overload Control Drafts > > Volker Hilt > > to: > > sip-overload@ietf.org > > 10/27/2009 10:36 AM > > Sent by: > > sip-overload-bounces@ietf.org > > All, > > We are looking for experts who can do a review for the following two drafts: > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt > > http://tools.ietf.org/html/draft-shen-sipping-load-control-event- > package-03.txt > > Please send me a quick note if you are interested and available to do a > review for one of these drafts (or both of them). Please post the > review on this mailing list. > > We had many people expressing interest in contributing to a SIP overload > control solution. This is a great chance to do so! > > Thanks, > > Volker > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 00835B9D8525766C_= Content-Type: text/html; charset="US-ASCII"

With regard to
A Session Initiation Protocol (SIP) Load Control Event Package
draft-shen-sipping-load-control-event-package-03.txt
I have concerns about a number of the basic premises.

First, the approach seems to depend on landline   "telephone numbers" and "Tel URIs".

1- It seems that load control should apply to ALL SIP sessions, not just  voice calls with an associated phone  number (or even a Tel URI)

2-It is no longer reasonable to assume a mapping between "telephone number" and "location" or a particular SIP  proxy.  A mobile phone could be anywhere- the number is not at all related to which SIP proxy it is  using.  And even number portability for landline phones makes it a less useful mapping.

3- It might be more practical to invoke the load controls based on the next/previous SIP proxy or SIP server, rather than some representation of the "phone number".


Second, the approach propagates the load controls from one  SIP Proxy to the adjacent ones.  The first example given  is an "acceptable call rate"  to a TV program "hotline".  The SIP proxy then "allocates" the acceptable call rate  among its neighbors. I think that propagating the load controls across multiple proxies is likely to create more problems than it solves

1- It is highly unlikely that the actual call rate is uniformly, or even predictably, distributed among the  neighbors.  This means that it is highly likely that some of the neighbors will have a bigger call rate to the TV  hot line, meaning they will block calls, while others will have lower volume, and will not need to block calls.  The  call rate at the TV hotline will then be below the "acceptable call rate", and there will be many calls that were unnecessarily blocked.  This concern also applies to the second example given.

Finally, your approach make no mention of exempting SIP requests with particular RPH values form these load controls, as required by  Req 13 of  RFC 5390.

Thanks

Janet

sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM:

> [image removed]
>
> [sip-overload] Expert Review for Overload Control Drafts
>
> Volker Hilt
>
> to:
>
> sip-overload@ietf.org
>
> 10/27/2009 10:36 AM
>
> Sent by:
>
> sip-overload-bounces@ietf.org
>
> All,
>
> We are looking for experts who can do a review for the following two drafts:
>
> http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt
>
> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-
> package-03.txt
>
> Please send me a quick note if you are interested and available to do a
> review for one of these drafts (or both of them). Please post the
> review on this mailing list.
>
> We had many people expressing interest in contributing to a SIP overload
> control solution. This is a great chance to do so!
>
> Thanks,
>
> Volker
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 00835B9D8525766C_=-- From nick.m.stewart@bt.com Wed Nov 18 07:46:18 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A799028C101 for ; Wed, 18 Nov 2009 07:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaCB8MOFkVWO for ; Wed, 18 Nov 2009 07:46:17 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D2DAD28C0FD for ; Wed, 18 Nov 2009 07:46:16 -0800 (PST) Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.57]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 15:46:14 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6866.41EA105D" Date: Wed, 18 Nov 2009 15:46:13 -0000 Message-ID: <5ACFADE7CFA7BF43A6B64DEED0ED918A0949BD1F@E03MVY2-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GOCAP Thread-Index: AcpoZBVHHOohJOrxTmO6ArvigBDjSw== From: To: X-OriginalArrivalTime: 18 Nov 2009 15:46:14.0096 (UTC) FILETIME=[42408D00:01CA6866] Subject: [sip-overload] GOCAP X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:46:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6866.41EA105D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to let you know that the ETSI GOCAP work on generic overload control has reached the member vote stage of approval. This spec describes a framework for overload control which may be applied to SIP. The draft is available from http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=3D23855 Regards, Nick Nick Stewart BT Innovate & Design Tel: +44 (0)1473 629428 Mob: +44 (0)7962 103572 Email: nick.m.stewart@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 ------_=_NextPart_001_01CA6866.41EA105D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable GOCAP

Just to let you know that = the ETSI GOCAP work on generic = overload control has reached the member vote stage of = approval.  This spec describes a framework for overload control = which may be applied to SIP.

The draft is available from http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI= _ID=3D23855

Regards,

Nick

Nick = Stewart
BT Innovate & = Design

Tel: +44 (0)1473 = 629428
Mob: +44 (0)7962 = 103572
Email: = nick.m.stewart@bt.com
Web: www.bt.com

This email contains BT = information, which may be privileged or confidential. It's meant only = for the individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If = you've received this email in error, please let me know immediately on = the email address above. Thank you.
We monitor our email system, and may record your = emails.

British = Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

------_=_NextPart_001_01CA6866.41EA105D-- From charles.newyork@gmail.com Mon Nov 23 06:27:29 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6F53A690D for ; Mon, 23 Nov 2009 06:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tLogQzkFfgM for ; Mon, 23 Nov 2009 06:27:25 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id BC5353A67F4 for ; Mon, 23 Nov 2009 06:27:25 -0800 (PST) Received: by pzk6 with SMTP id 6so3776846pzk.29 for ; Mon, 23 Nov 2009 06:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=u36xVmlLvDEfcr2YkxtlbHpDhGDlRRs86Ke8UNtldIY=; b=RJ7izaRGoLMRYcyGJ17jKA//Xn75ffcONz69wJi0VpWJJAStZPgbMJCAGeFQEyqIfh 7+XXAInQW1dFkl0aLjQq48uSvWOkd7vyJ37A/AP+aVwcGoMhoDbfJycxdbYUtcS1o8R+ na5lW6PYzyBy+ev7HXGxWPaX6/UgAV5p8hH8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qW6PAhCvxwtFd9LKw9U9rzIBO4gAgVEFiNqjZDHe8QQN+y6arDozc138GRZ79N7jhx HEWid2+aYS4CjiRXBHq8xVPfx+paumBBAE7mIB5F+GFmDSpAv67uBzv400q9d30uB/IQ S+cDOyyVDToQ44oO6VNaFQkwao5TsM7cR0sls= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.142.60.8 with SMTP id i8mr506644wfa.326.1258986439387; Mon, 23 Nov 2009 06:27:19 -0800 (PST) In-Reply-To: <618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> References: <4AE5BE5C.1050803@alcatel-lucent.com> <5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com> <618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> Date: Mon, 23 Nov 2009 09:27:19 -0500 X-Google-Sender-Auth: 8cebe2a65d274303 Message-ID: From: Charles Shen To: Victor Pascual Avila Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org, "NOEL, ERIC C \(ATTLABS\)" , Henning Schulzrinne Subject: Re: [sip-overload] [Fwd: I-D Action:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:27:29 -0000 Hi Victor: The document itself does not preclude schemas other than the one defined in= it. Thanks Charles On Tue, Oct 27, 2009 at 9:41 AM, Victor Pascual Avila wrote: > Hi, > > On Tue, Oct 27, 2009 at 2:13 PM, NOEL, ERIC C (ATTLABS) = wrote: > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-package > > Is the goal to define a SIP event package enabling notification > according to various XML schema (please see [1]) or rather mandating > the support of a particular schema? > > [1] Draft ETSI ES 283 039-2 V3.0.0 (2009-06), Section 6 > > Thanks, > -- > Victor Pascual =C3=81vila > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From bruno.chatras@orange-ftgroup.com Mon Nov 23 06:40:25 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE0F3A6A69 for ; Mon, 23 Nov 2009 06:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkF7IE554Kmb for ; Mon, 23 Nov 2009 06:40:25 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 94C7B3A686E for ; Mon, 23 Nov 2009 06:40:24 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 15:40:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 15:40:17 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsSRWhnnTEooNbQXCc6mPSmKPqHQAABHiw References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> From: To: , X-OriginalArrivalTime: 23 Nov 2009 14:40:19.0062 (UTC) FILETIME=[E0EF0160:01CA6C4A] Cc: en5192@att.com, sip-overload@ietf.org, hgs@cs.columbia.edu Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:40:25 -0000 =20 Well, it does not preclude other schemas to be used in addition to the = schema defined in it but it precludes using another schema exclusively. = This restriction comes from clause 5.5: "If the Accept header field is = present, it MUST include "application/load-control+xml" and MAY include = any other types. I believe it would be more flexible to consider the schema defined in = the document as a default schema (i.e. in case the SUBSCRIBE request = does not include an Accept header field) but not mandate its support. Bruno -----Message d'origine----- De : sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] De la part de Charles Shen Envoy=E9 : lundi 23 novembre 2009 15:27 =C0 : Victor Pascual Avila Cc : sip-overload@ietf.org; NOEL, ERIC C (ATTLABS); Henning Schulzrinne Objet : Re: [sip-overload] [Fwd: = I-DAction:draft-hilt-sipping-overload-07.txt] Hi Victor: The document itself does not preclude schemas other than the one defined = in it. Thanks Charles On Tue, Oct 27, 2009 at 9:41 AM, Victor Pascual Avila = wrote: > Hi, > > On Tue, Oct 27, 2009 at 2:13 PM, NOEL, ERIC C (ATTLABS) = wrote: > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-pack >> age > > Is the goal to define a SIP event package enabling notification=20 > according to various XML schema (please see [1]) or rather mandating=20 > the support of a particular schema? > > [1] Draft ETSI ES 283 039-2 V3.0.0 (2009-06), Section 6 > > Thanks, > -- > Victor Pascual =C1vila > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From charles.newyork@gmail.com Mon Nov 23 06:50:16 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1725D3A6AA8 for ; Mon, 23 Nov 2009 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixf02KPd15mv for ; Mon, 23 Nov 2009 06:50:13 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id EB1B93A6A88 for ; Mon, 23 Nov 2009 06:50:12 -0800 (PST) Received: by pxi1 with SMTP id 1so4072168pxi.32 for ; Mon, 23 Nov 2009 06:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=9zoBPkclRvzUr875pm1U5BlZsgMAKtNqpB0trT//T2k=; b=ZCKdco8RZcci0U//7ENYYXBfMybADS532wYgj58GCy8uq8le72R+xe+NBnznN0rnR8 w2cFvHkSJXepWRqiuTEo7WyroxBxXYUS+kGWDkP5sDEzbjvX1puWBT8B/EcDKUCgpDt2 8tSIAx1Z3NUyt7KEyHpLQVzWHzJKAH6OMGG0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=geEFJxAO27W7/Zz9K6yzMXv2eAtDn0CZZ4akd7gwTvbeHXSc6d0d8Vh3z0yjT21fCT lPioSyaJKXaWm93b8xzncQMUfM9pDtpTql/Bc/kgRJYecqhU5yJTHbdKYB37i0YliOOb Uqs1FdtKL0hpTBD5jfyu1pw/IwUal7TL0fFOw= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.143.27.42 with SMTP id e42mr518446wfj.220.1258987805327; Mon, 23 Nov 2009 06:50:05 -0800 (PST) In-Reply-To: References: <4AE7055E.9060208@alcatel-lucent.com> Date: Mon, 23 Nov 2009 09:50:04 -0500 X-Google-Sender-Auth: 14c6c0e3ef0dfb12 Message-ID: From: Charles Shen To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:50:16 -0000 Hi Janet, thanks for your review. please see comments inline: On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn wrote: > > > With regard to > A Session Initiation Protocol (SIP) Load Control Event Package > draft-shen-sipping-load-control-event-package-03.txt > I have concerns about a number of the basic premises. > > First, the approach seems to depend on landline =C2=A0 "telephone numbers= " and > "Tel URIs". > > 1- It seems that load control should apply to ALL SIP sessions, not just > =C2=A0voice calls with an associated phone =C2=A0number (or even a Tel UR= I) It is a clear goal of this draft *not* to limit on "telephone numbers", but to support SIP URIs, *including* Tel URIs that could be associated to phone numbers. Therefore, as the document suggests, the call identity to be filtered is based on the SIP , header etc., and the examples in the document also include SIP URIs and domain names. Please let me know if you have suggestions to clarify it further. > > 2-It is no longer reasonable to assume a mapping between "telephone numbe= r" > and "location" or a particular SIP =C2=A0proxy. =C2=A0A mobile phone coul= d be > anywhere- the number is not at all related to which SIP proxy it is =C2= =A0using. > =C2=A0And even number portability for landline phones makes it a less use= ful > mapping. Here the typical overload destination would more likely be a call center than a mobile phone. I don't know how exactly number portability would matter, as long as they are forwarded to the correct proxy ... correct me if I were wrong. > > 3- It might be more practical to invoke the load controls based on the > next/previous SIP proxy or SIP server, rather than some representation of > the "phone number". > comments as in 1. > Second, the approach propagates the load controls from one =C2=A0SIP Prox= y to the > adjacent ones. =C2=A0The first example given =C2=A0is an "acceptable call= rate" =C2=A0to a > TV program "hotline". =C2=A0The SIP proxy then "allocates" the acceptable= call > rate =C2=A0among its neighbors. I think that propagating the load control= s across > multiple proxies is likely to create more problems than it solves > > 1- It is highly unlikely that the actual call rate is uniformly, or even > predictably, distributed among the =C2=A0neighbors. =C2=A0This means that= it is highly > likely that some of the neighbors will have a bigger call rate to the TV > =C2=A0hot line, meaning they will block calls, while others will have low= er > volume, and will not need to block calls. =C2=A0The =C2=A0call rate at th= e TV hotline > will then be below the "acceptable call rate", and there will be many cal= ls > that were unnecessarily blocked. =C2=A0This concern also applies to the s= econd > example given. The example shows how the event package, with appropriate input values, could be used. The input values to the event package are outputs of a specific overload algorithm, which may be distributed or centralized, or hybrid. As mentioned, the overload algorithm itself is out of scope of this event package document. But if the algorithm produces a dynamic rate output, there is no reason why the rate distribution by the event package could not be dynamic. I can clarify this in the next revision. > > Finally, your approach make no mention of exempting SIP requests with > particular RPH values form these load controls, as required by =C2=A0Req = 13 of > =C2=A0RFC 5390. Maybe we can add something like the RPH mechanism takes precedence over this filtering in the next revision. Thanks Charles > > Thanks > > Janet > > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM: > >> [image removed] >> >> [sip-overload] Expert Review for Overload Control Drafts >> >> Volker Hilt >> >> to: >> >> sip-overload@ietf.org >> >> 10/27/2009 10:36 AM >> >> Sent by: >> >> sip-overload-bounces@ietf.org >> >> All, >> >> We are looking for experts who can do a review for the following two >> drafts: >> >> > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt >> >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event- >> package-03.txt >> >> Please send me a quick note if you are interested and available to do a >> review for one of these drafts (or both of them). Please post the >> review on this mailing list. >> >> We had many people expressing interest in contributing to a SIP overload >> control solution. This is a great chance to do so! >> >> Thanks, >> >> Volker >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > From hgs@cs.columbia.edu Mon Nov 23 06:59:22 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477F928C162 for ; Mon, 23 Nov 2009 06:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjWZO-PQialn for ; Mon, 23 Nov 2009 06:59:21 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 5C3C928C161 for ; Mon, 23 Nov 2009 06:59:21 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nANExC70021908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2009 09:59:13 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> Date: Mon, 23 Nov 2009 09:59:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 X-Mailman-Approved-At: Mon, 23 Nov 2009 09:19:58 -0800 Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:59:22 -0000 Without a must-support scheme, there is no interoperability, so it kind = of defeats the purpose of a standard. Obviously, private parties can = always agree on anything they want, but they shouldn't be claiming = RFC-overload support, since they won't be able to interoperate. Henning On Nov 23, 2009, at 9:40 AM, = wrote: >=20 > Well, it does not preclude other schemas to be used in addition to the = schema defined in it but it precludes using another schema exclusively. = This restriction comes from clause 5.5: "If the Accept header field is = present, it MUST include "application/load-control+xml" and MAY include = any other types. >=20 > I believe it would be more flexible to consider the schema defined in = the document as a default schema (i.e. in case the SUBSCRIBE request = does not include an Accept header field) but not mandate its support. >=20 > Bruno >=20 >=20 > -----Message d'origine----- > De : sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] De la part de Charles Shen > Envoy=E9 : lundi 23 novembre 2009 15:27 > =C0 : Victor Pascual Avila > Cc : sip-overload@ietf.org; NOEL, ERIC C (ATTLABS); Henning = Schulzrinne > Objet : Re: [sip-overload] [Fwd: = I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Hi Victor: >=20 > The document itself does not preclude schemas other than the one = defined in it. >=20 > Thanks >=20 > Charles >=20 >=20 >=20 >=20 > On Tue, Oct 27, 2009 at 9:41 AM, Victor Pascual Avila = wrote: >> Hi, >>=20 >> On Tue, Oct 27, 2009 at 2:13 PM, NOEL, ERIC C (ATTLABS) = wrote: >>=20 >>> = http://tools.ietf.org/html/draft-shen-sipping-load-control-event-pack >>> age >>=20 >> Is the goal to define a SIP event package enabling notification=20 >> according to various XML schema (please see [1]) or rather mandating=20= >> the support of a particular schema? >>=20 >> [1] Draft ETSI ES 283 039-2 V3.0.0 (2009-06), Section 6 >>=20 >> Thanks, >> -- >> Victor Pascual =C1vila >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >>=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 From drage@alcatel-lucent.com Mon Nov 23 09:43:25 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1373A6ABB for ; Mon, 23 Nov 2009 09:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IuaHcJTADrH for ; Mon, 23 Nov 2009 09:43:24 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AF5F53A67EA for ; Mon, 23 Nov 2009 09:43:23 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nANHh6VG001187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Nov 2009 18:43:06 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 23 Nov 2009 18:43:06 +0100 From: "DRAGE, Keith (Keith)" To: Charles Shen , Janet P Gunn Date: Mon, 23 Nov 2009 18:40:22 +0100 Thread-Topic: [sip-overload] Expert Review for Overload Control Drafts Thread-Index: AcpsTFRFCKoST11CSLOSeyapvsPKPQAFs0UQ Message-ID: References: <4AE7055E.9060208@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:43:25 -0000 WW91IHNhaWQ6DQoNCj4gPiBGaW5hbGx5LCB5b3VyIGFwcHJvYWNoIG1ha2Ugbm8gbWVudGlvbiBv ZiBleGVtcHRpbmcgU0lQIA0KPiByZXF1ZXN0cyB3aXRoIA0KPiA+IHBhcnRpY3VsYXIgUlBIIHZh bHVlcyBmb3JtIHRoZXNlIGxvYWQgY29udHJvbHMsIGFzIHJlcXVpcmVkIA0KPiBieSDCoFJlcSAx MyANCj4gPiBvZg0KPiA+IMKgUkZDIDUzOTAuDQo+IA0KPiBNYXliZSB3ZSBjYW4gYWRkIHNvbWV0 aGluZyBsaWtlIHRoZSBSUEggbWVjaGFuaXNtIHRha2VzIA0KPiBwcmVjZWRlbmNlIG92ZXIgdGhp cyBmaWx0ZXJpbmcgaW4gdGhlIG5leHQgcmV2aXNpb24uDQo+DQoNCkkgbm90IHN1cmUgaXQgaXMg ZW50aXJlbHkgYSBtYXR0ZXIgb2YgZXhlbXB0aW5nLCBvciBwcmVjZWRlbmNlIGludmFsaWRhdGlu ZyB0aGUgZmlsdGVyaW5nLg0KDQpTdXJlbHkgaWYgZm9yIGV4YW1wbGUgaWYgSSBoYXZlIGFuIFJQ SCBmb3IgZW1lcmdlbmN5IGNhbGxzIChwcm9wb3NlZCksIGl0IGlzIHBvc3NpYmxlIHRvIGxvY2Fs bHkgb3ZlcmxvYWQgdGhlIG5ldHdvcmsgd2l0aCBqdXN0IGVtZXJnZW5jeSBjYWxscywgYW5kIHRo ZXJlZm9yZSB3ZSBuZWVkIHRoZSBvdmVybG9hZCBtZWNoYW5pc20gdG8gb3BlcmF0ZSBpbiBzb21l IG1hbm5lci4NCg0KRnVydGhlciBjYWxscyB3aXRoIFJQSCBkbyBub3QgbmVjZXNzYXJpbHkgcmVt b3ZlIHRoZSBhYmlsaXR5IGZvciBvdGhlciBjYWxscyB0byBiZSBtYWRlIGVudGlyZWx5LCBtZXJl bHkgZ3VhcmFudGVlIHRoYXQgYSBjZXJ0YWluIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgaXMg cmVzZXJ2ZWQgZm9yIHByaW9yaXR5IGNhbGxzIChmb3IgZXhhbXBsZSkuDQoNCldoYXQgd2Ugc3Vy ZWx5IG5lZWQgaXMgZm9yIHRoZSBvdmVybG9hZCBhbGdvcml0aG1zIHRvIGFwcGx5LCBidXQgdG8g dGFrZSBpbnRvIGFjY291bnQgdGhlIFJQSCBpbiBwZXJmb3JtaW5nIHRoZWlyIGFjdGl2aXR5Lg0K DQpyZWdhcmRzDQoNCktlaXRoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IFttYWlsdG86c2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaGFybGVzIFNoZW4NCj4gU2VudDogTW9u ZGF5LCBOb3ZlbWJlciAyMywgMjAwOSAyOjUwIFBNDQo+IFRvOiBKYW5ldCBQIEd1bm4NCj4gQ2M6 IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgQXJhdGEgS29pa2U7IEhlbm5pbmcgU2NodWx6cmlubmUN Cj4gU3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIEV4cGVydCBSZXZpZXcgZm9yIE92ZXJsb2Fk IENvbnRyb2wgRHJhZnRzDQo+IA0KPiBIaSBKYW5ldCwgdGhhbmtzIGZvciB5b3VyIHJldmlldy4g cGxlYXNlIHNlZSBjb21tZW50cyBpbmxpbmU6DQo+IA0KPiBPbiBUaHUsIE5vdiAxMiwgMjAwOSBh dCA2OjU0IFBNLCBKYW5ldCBQIEd1bm4gPGpndW5uNkBjc2MuY29tPiB3cm90ZToNCj4gPg0KPiA+ DQo+ID4gV2l0aCByZWdhcmQgdG8NCj4gPiBBIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAo U0lQKSBMb2FkIENvbnRyb2wgRXZlbnQgUGFja2FnZSANCj4gPiBkcmFmdC1zaGVuLXNpcHBpbmct bG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDMudHh0DQo+ID4gSSBoYXZlIGNvbmNlcm5zIGFi b3V0IGEgbnVtYmVyIG9mIHRoZSBiYXNpYyBwcmVtaXNlcy4NCj4gPg0KPiA+IEZpcnN0LCB0aGUg YXBwcm9hY2ggc2VlbXMgdG8gZGVwZW5kIG9uIGxhbmRsaW5lIMKgIA0KPiAidGVsZXBob25lIG51 bWJlcnMiIA0KPiA+IGFuZCAiVGVsIFVSSXMiLg0KPiA+DQo+ID4gMS0gSXQgc2VlbXMgdGhhdCBs b2FkIGNvbnRyb2wgc2hvdWxkIGFwcGx5IHRvIEFMTCBTSVAgc2Vzc2lvbnMsIG5vdCANCj4gPiBq dXN0DQo+ID4gwqB2b2ljZSBjYWxscyB3aXRoIGFuIGFzc29jaWF0ZWQgcGhvbmUgwqBudW1iZXIg KG9yIGV2ZW4gYSBUZWwgVVJJKQ0KPiANCj4gSXQgaXMgYSBjbGVhciBnb2FsIG9mIHRoaXMgZHJh ZnQgKm5vdCogdG8gbGltaXQgb24gInRlbGVwaG9uZSANCj4gbnVtYmVycyIsIGJ1dCB0byBzdXBw b3J0IFNJUCBVUklzLCAqaW5jbHVkaW5nKiBUZWwgVVJJcyB0aGF0IA0KPiBjb3VsZCBiZSBhc3Nv Y2lhdGVkIHRvIHBob25lIG51bWJlcnMuIFRoZXJlZm9yZSwgYXMgdGhlIA0KPiBkb2N1bWVudCBz dWdnZXN0cywgdGhlIGNhbGwgaWRlbnRpdHkgdG8gYmUgZmlsdGVyZWQgaXMgYmFzZWQgDQo+IG9u IHRoZSBTSVAgPGZyb20+LCA8dG8+IGhlYWRlciBldGMuLCBhbmQgdGhlIGV4YW1wbGVzIGluIHRo ZSANCj4gZG9jdW1lbnQgYWxzbyBpbmNsdWRlIFNJUCBVUklzIGFuZCBkb21haW4gbmFtZXMuIFBs ZWFzZSBsZXQgDQo+IG1lIGtub3cgaWYgeW91IGhhdmUgc3VnZ2VzdGlvbnMgdG8gY2xhcmlmeSBp dCBmdXJ0aGVyLg0KPiANCj4gPg0KPiA+IDItSXQgaXMgbm8gbG9uZ2VyIHJlYXNvbmFibGUgdG8g YXNzdW1lIGEgbWFwcGluZyBiZXR3ZWVuIA0KPiAidGVsZXBob25lIG51bWJlciINCj4gPiBhbmQg ImxvY2F0aW9uIiBvciBhIHBhcnRpY3VsYXIgU0lQIMKgcHJveHkuIMKgQSBtb2JpbGUgcGhvbmUg Y291bGQgYmUNCj4gPiBhbnl3aGVyZS0gdGhlIG51bWJlciBpcyBub3QgYXQgYWxsIHJlbGF0ZWQg dG8gd2hpY2ggU0lQIA0KPiBwcm94eSBpdCBpcyDCoHVzaW5nLg0KPiA+IMKgQW5kIGV2ZW4gbnVt YmVyIHBvcnRhYmlsaXR5IGZvciBsYW5kbGluZSBwaG9uZXMgbWFrZXMgaXQgYSBsZXNzIA0KPiA+ IHVzZWZ1bCBtYXBwaW5nLg0KPiANCj4gSGVyZSB0aGUgdHlwaWNhbCBvdmVybG9hZCBkZXN0aW5h dGlvbiB3b3VsZCBtb3JlIGxpa2VseSBiZSBhIA0KPiBjYWxsIGNlbnRlciB0aGFuIGEgbW9iaWxl IHBob25lLiBJIGRvbid0IGtub3cgaG93IGV4YWN0bHkgDQo+IG51bWJlciBwb3J0YWJpbGl0eSB3 b3VsZCBtYXR0ZXIsIGFzIGxvbmcgYXMgdGhleSBhcmUgDQo+IGZvcndhcmRlZCB0byB0aGUgY29y cmVjdCBwcm94eSAuLi4gY29ycmVjdCBtZSBpZiBJIHdlcmUgd3JvbmcuDQo+IA0KPiA+DQo+ID4g My0gSXQgbWlnaHQgYmUgbW9yZSBwcmFjdGljYWwgdG8gaW52b2tlIHRoZSBsb2FkIGNvbnRyb2xz IA0KPiBiYXNlZCBvbiB0aGUgDQo+ID4gbmV4dC9wcmV2aW91cyBTSVAgcHJveHkgb3IgU0lQIHNl cnZlciwgcmF0aGVyIHRoYW4gc29tZSANCj4gcmVwcmVzZW50YXRpb24gDQo+ID4gb2YgdGhlICJw aG9uZSBudW1iZXIiLg0KPiA+DQo+IA0KPiBjb21tZW50cyBhcyBpbiAxLg0KPiANCj4gPiBTZWNv bmQsIHRoZSBhcHByb2FjaCBwcm9wYWdhdGVzIHRoZSBsb2FkIGNvbnRyb2xzIGZyb20gb25lIMKg DQo+IFNJUCBQcm94eSANCj4gPiB0byB0aGUgYWRqYWNlbnQgb25lcy4gwqBUaGUgZmlyc3QgZXhh bXBsZSBnaXZlbiDCoGlzIGFuIA0KPiAiYWNjZXB0YWJsZSBjYWxsIA0KPiA+IHJhdGUiIMKgdG8g YSBUViBwcm9ncmFtICJob3RsaW5lIi4gwqBUaGUgU0lQIHByb3h5IHRoZW4gDQo+ICJhbGxvY2F0 ZXMiIHRoZSANCj4gPiBhY2NlcHRhYmxlIGNhbGwgcmF0ZSDCoGFtb25nIGl0cyBuZWlnaGJvcnMu IEkgdGhpbmsgdGhhdCBwcm9wYWdhdGluZyANCj4gPiB0aGUgbG9hZCBjb250cm9scyBhY3Jvc3Mg bXVsdGlwbGUgcHJveGllcyBpcyBsaWtlbHkgdG8gY3JlYXRlIG1vcmUgDQo+ID4gcHJvYmxlbXMg dGhhbiBpdCBzb2x2ZXMNCj4gPg0KPiA+IDEtIEl0IGlzIGhpZ2hseSB1bmxpa2VseSB0aGF0IHRo ZSBhY3R1YWwgY2FsbCByYXRlIGlzIHVuaWZvcm1seSwgb3IgDQo+ID4gZXZlbiBwcmVkaWN0YWJs eSwgZGlzdHJpYnV0ZWQgYW1vbmcgdGhlIMKgbmVpZ2hib3JzLiDCoFRoaXMgDQo+IG1lYW5zIHRo YXQgDQo+ID4gaXQgaXMgaGlnaGx5IGxpa2VseSB0aGF0IHNvbWUgb2YgdGhlIG5laWdoYm9ycyB3 aWxsIGhhdmUgYSANCj4gYmlnZ2VyIGNhbGwgDQo+ID4gcmF0ZSB0byB0aGUgVFYNCj4gPiDCoGhv dCBsaW5lLCBtZWFuaW5nIHRoZXkgd2lsbCBibG9jayBjYWxscywgd2hpbGUgb3RoZXJzIHdpbGwg DQo+IGhhdmUgbG93ZXIgDQo+ID4gdm9sdW1lLCBhbmQgd2lsbCBub3QgbmVlZCB0byBibG9jayBj YWxscy4gwqBUaGUgwqBjYWxsIHJhdGUgYXQgdGhlIFRWIA0KPiA+IGhvdGxpbmUgd2lsbCB0aGVu IGJlIGJlbG93IHRoZSAiYWNjZXB0YWJsZSBjYWxsIHJhdGUiLCBhbmQgDQo+IHRoZXJlIHdpbGwg DQo+ID4gYmUgbWFueSBjYWxscyB0aGF0IHdlcmUgdW5uZWNlc3NhcmlseSBibG9ja2VkLiDCoFRo aXMgY29uY2VybiBhbHNvIA0KPiA+IGFwcGxpZXMgdG8gdGhlIHNlY29uZCBleGFtcGxlIGdpdmVu Lg0KPiANCj4gVGhlIGV4YW1wbGUgc2hvd3MgaG93IHRoZSBldmVudCBwYWNrYWdlLCB3aXRoIGFw cHJvcHJpYXRlIA0KPiBpbnB1dCB2YWx1ZXMsIGNvdWxkIGJlIHVzZWQuIFRoZSBpbnB1dCB2YWx1 ZXMgdG8gdGhlIGV2ZW50IA0KPiBwYWNrYWdlIGFyZSBvdXRwdXRzIG9mIGEgc3BlY2lmaWMgb3Zl cmxvYWQgYWxnb3JpdGhtLCB3aGljaCANCj4gbWF5IGJlIGRpc3RyaWJ1dGVkIG9yIGNlbnRyYWxp emVkLCBvciBoeWJyaWQuIEFzIG1lbnRpb25lZCwgDQo+IHRoZSBvdmVybG9hZCBhbGdvcml0aG0g aXRzZWxmIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGV2ZW50IA0KPiBwYWNrYWdlIGRvY3VtZW50 LiBCdXQgaWYgdGhlIGFsZ29yaXRobSBwcm9kdWNlcyBhIGR5bmFtaWMgDQo+IHJhdGUgb3V0cHV0 LCB0aGVyZSBpcyBubyByZWFzb24gd2h5IHRoZSByYXRlIGRpc3RyaWJ1dGlvbiBieSANCj4gdGhl IGV2ZW50IHBhY2thZ2UgY291bGQgbm90IGJlIGR5bmFtaWMuIEkgY2FuIGNsYXJpZnkgdGhpcyBp biANCj4gdGhlIG5leHQgcmV2aXNpb24uDQo+IA0KPiA+DQo+ID4gRmluYWxseSwgeW91ciBhcHBy b2FjaCBtYWtlIG5vIG1lbnRpb24gb2YgZXhlbXB0aW5nIFNJUCANCj4gcmVxdWVzdHMgd2l0aCAN Cj4gPiBwYXJ0aWN1bGFyIFJQSCB2YWx1ZXMgZm9ybSB0aGVzZSBsb2FkIGNvbnRyb2xzLCBhcyBy ZXF1aXJlZCANCj4gYnkgwqBSZXEgMTMgDQo+ID4gb2YNCj4gPiDCoFJGQyA1MzkwLg0KPiANCj4g TWF5YmUgd2UgY2FuIGFkZCBzb21ldGhpbmcgbGlrZSB0aGUgUlBIIG1lY2hhbmlzbSB0YWtlcyAN Cj4gcHJlY2VkZW5jZSBvdmVyIHRoaXMgZmlsdGVyaW5nIGluIHRoZSBuZXh0IHJldmlzaW9uLg0K PiANCj4gVGhhbmtzDQo+IA0KPiBDaGFybGVzDQo+IA0KPiANCj4gPg0KPiA+IFRoYW5rcw0KPiA+ DQo+ID4gSmFuZXQNCj4gPg0KPiA+IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIHdyb3Rl IG9uIDEwLzI3LzIwMDkgMTA6MzY6MTQgQU06DQo+ID4NCj4gPj4gW2ltYWdlIHJlbW92ZWRdDQo+ ID4+DQo+ID4+IFtzaXAtb3ZlcmxvYWRdIEV4cGVydCBSZXZpZXcgZm9yIE92ZXJsb2FkIENvbnRy b2wgRHJhZnRzDQo+ID4+DQo+ID4+IFZvbGtlciBIaWx0DQo+ID4+DQo+ID4+IHRvOg0KPiA+Pg0K PiA+PiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcNCj4gPj4NCj4gPj4gMTAvMjcvMjAwOSAxMDozNiBB TQ0KPiA+Pg0KPiA+PiBTZW50IGJ5Og0KPiA+Pg0KPiA+PiBzaXAtb3ZlcmxvYWQtYm91bmNlc0Bp ZXRmLm9yZw0KPiA+Pg0KPiA+PiBBbGwsDQo+ID4+DQo+ID4+IFdlIGFyZSBsb29raW5nIGZvciBl eHBlcnRzIHdobyBjYW4gZG8gYSByZXZpZXcgZm9yIHRoZSANCj4gZm9sbG93aW5nIHR3bw0KPiA+ PiBkcmFmdHM6DQo+ID4+DQo+ID4+DQo+ID4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWhpbHQtc2lwcGluZy1vdmVybG9hZC0wNy50eHQNCj4gPj4NCj4gPj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2hlbi1zaXBwaW5nLWxvYWQtY29udHJv bC1ldmVudC0NCj4gPj4gcGFja2FnZS0wMy50eHQNCj4gPj4NCj4gPj4gUGxlYXNlIHNlbmQgbWUg YSBxdWljayBub3RlIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBhbmQgDQo+IGF2YWlsYWJsZSB0byBk byANCj4gPj4gYSByZXZpZXcgZm9yIG9uZSBvZiB0aGVzZSBkcmFmdHMgKG9yIGJvdGggb2YgdGhl bSkuIFBsZWFzZSANCj4gcG9zdCB0aGUgDQo+ID4+IHJldmlldyBvbiB0aGlzIG1haWxpbmcgbGlz dC4NCj4gPj4NCj4gPj4gV2UgaGFkIG1hbnkgcGVvcGxlIGV4cHJlc3NpbmcgaW50ZXJlc3QgaW4g Y29udHJpYnV0aW5nIHRvIGEgU0lQIA0KPiA+PiBvdmVybG9hZCBjb250cm9sIHNvbHV0aW9uLiBU aGlzIGlzIGEgZ3JlYXQgY2hhbmNlIHRvIGRvIHNvIQ0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+ DQo+ID4+IFZvbGtlcg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+ID4+IHNp cC1vdmVybG9hZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcC1vdmVybG9hZA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+ID4g c2lwLW92ZXJsb2FkQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXAtb3ZlcmxvYWQNCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcC1vdmVybG9hZCBtYWlsaW5nIGxpc3QNCj4g c2lwLW92ZXJsb2FkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwLW92ZXJsb2FkDQo+IA== From bruno.chatras@orange-ftgroup.com Mon Nov 23 10:40:12 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA123A68E9 for ; Mon, 23 Nov 2009 10:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5PoQWcCcByM for ; Mon, 23 Nov 2009 10:40:11 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id C00993A6781 for ; Mon, 23 Nov 2009 10:40:10 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 19:40:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 19:39:59 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsTayr/g9ufyppRuCbEwCnTB7aZQACD+vQ References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> From: To: X-OriginalArrivalTime: 23 Nov 2009 18:40:02.0185 (UTC) FILETIME=[5DF16790:01CA6C6C] Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:40:12 -0000 Why not splitting the document into two RFCs? RFC-X would define the = event package but not mandate any schema. RFC-Y would specify an IETF = default schema. Anyone using the event package with exclusively a = different schema would claim conformance to RFC-X but not to RFC-Y. Bruno -----Message d'origine----- De : Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Envoy=E9 : lundi 23 novembre 2009 15:59 =C0 : CHATRAS Bruno RD-CORE-ISS Cc : charles@cs.columbia.edu; victor.pascual.avila@gmail.com; = sip-overload@ietf.org; en5192@att.com Objet : Re: [sip-overload] [Fwd: = I-DAction:draft-hilt-sipping-overload-07.txt] Without a must-support scheme, there is no interoperability, so it kind = of defeats the purpose of a standard. Obviously, private parties can = always agree on anything they want, but they shouldn't be claiming = RFC-overload support, since they won't be able to interoperate. Henning On Nov 23, 2009, at 9:40 AM, = wrote: >=20 > Well, it does not preclude other schemas to be used in addition to the = schema defined in it but it precludes using another schema exclusively. = This restriction comes from clause 5.5: "If the Accept header field is = present, it MUST include "application/load-control+xml" and MAY include = any other types. >=20 > I believe it would be more flexible to consider the schema defined in = the document as a default schema (i.e. in case the SUBSCRIBE request = does not include an Accept header field) but not mandate its support. >=20 > Bruno >=20 >=20 > -----Message d'origine----- > De : sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] De la part de Charles Shen=20 > Envoy=E9 : lundi 23 novembre 2009 15:27 =C0 : Victor Pascual Avila Cc = :=20 > sip-overload@ietf.org; NOEL, ERIC C (ATTLABS); Henning Schulzrinne=20 > Objet : Re: [sip-overload] [Fwd:=20 > I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Hi Victor: >=20 > The document itself does not preclude schemas other than the one = defined in it. >=20 > Thanks >=20 > Charles >=20 >=20 >=20 >=20 > On Tue, Oct 27, 2009 at 9:41 AM, Victor Pascual Avila = wrote: >> Hi, >>=20 >> On Tue, Oct 27, 2009 at 2:13 PM, NOEL, ERIC C (ATTLABS) = wrote: >>=20 >>> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-pac >>> k >>> age >>=20 >> Is the goal to define a SIP event package enabling notification=20 >> according to various XML schema (please see [1]) or rather mandating=20 >> the support of a particular schema? >>=20 >> [1] Draft ETSI ES 283 039-2 V3.0.0 (2009-06), Section 6 >>=20 >> Thanks, >> -- >> Victor Pascual =C1vila >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload >>=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 From jgunn6@csc.com Mon Nov 23 10:41:12 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD633A6947 for ; Mon, 23 Nov 2009 10:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DylIPsx8VixM for ; Mon, 23 Nov 2009 10:41:10 -0800 (PST) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id 7D72A3A6781 for ; Mon, 23 Nov 2009 10:41:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-8.tower-145.messagelabs.com!1259001662!10104727!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 8934 invoked from network); 23 Nov 2009 18:41:02 -0000 Received: from unknown (HELO amer-mta102.csc.com) (20.137.2.88) by server-8.tower-145.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2009 18:41:02 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nANIeHlO008623; Mon, 23 Nov 2009 13:40:18 -0500 In-Reply-To: References: <4AE7055E.9060208@alcatel-lucent.com> To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 X-KeepSent: 962F3668:A7E724B8-85257677:00654ED5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Mon, 23 Nov 2009 13:40:21 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 11/23/2009 01:41:52 PM, Serialize complete at 11/23/2009 01:41:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0066930785257677_=" Cc: Charles Shen , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:41:12 -0000 This is a multipart message in MIME format. --=_alternative 0066930785257677_= Content-Type: text/plain; charset="US-ASCII" I agree, We don't need a blanket "exemption for anything with RPH". We need the ability (using configuration) to exempt SIP messages with particular RPH values from particular aspects of the network controls. To go back to the SS7 world, we do NOT want GETS calls (equivalent to RPH namespaces ets and wps) to be exempt from "100% cancel-to" (which typically is associated with equipment failure), but we DO (in general) want them exempt from "x% cancel-to" for X not equal 100. There may very well also be cases where you want a network control to apply specifically to a particular RPH namespace, as in the RPH for 911-type emergency calls. What we need is for the overload mechanism to have the ability to distinguish, and give different treatment to, messages with specific RPH values. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "DRAGE, Keith (Keith)" To: Charles Shen , Janet P Gunn/USA/CSC@CSC Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Date: 11/23/2009 12:43 PM Subject: RE: [sip-overload] Expert Review for Overload Control Drafts You said: > > Finally, your approach make no mention of exempting SIP > requests with > > particular RPH values form these load controls, as required > by Req 13 > > of > > RFC 5390. > > Maybe we can add something like the RPH mechanism takes > precedence over this filtering in the next revision. > I not sure it is entirely a matter of exempting, or precedence invalidating the filtering. Surely if for example if I have an RPH for emergency calls (proposed), it is possible to locally overload the network with just emergency calls, and therefore we need the overload mechanism to operate in some manner. Further calls with RPH do not necessarily remove the ability for other calls to be made entirely, merely guarantee that a certain percentage of the traffic is reserved for priority calls (for example). What we surely need is for the overload algorithms to apply, but to take into account the RPH in performing their activity. regards Keith > -----Original Message----- > From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen > Sent: Monday, November 23, 2009 2:50 PM > To: Janet P Gunn > Cc: sip-overload@ietf.org; Arata Koike; Henning Schulzrinne > Subject: Re: [sip-overload] Expert Review for Overload Control Drafts > > Hi Janet, thanks for your review. please see comments inline: > > On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn wrote: > > > > > > With regard to > > A Session Initiation Protocol (SIP) Load Control Event Package > > draft-shen-sipping-load-control-event-package-03.txt > > I have concerns about a number of the basic premises. > > > > First, the approach seems to depend on landline > "telephone numbers" > > and "Tel URIs". > > > > 1- It seems that load control should apply to ALL SIP sessions, not > > just > > voice calls with an associated phone number (or even a Tel URI) > > It is a clear goal of this draft *not* to limit on "telephone > numbers", but to support SIP URIs, *including* Tel URIs that > could be associated to phone numbers. Therefore, as the > document suggests, the call identity to be filtered is based > on the SIP , header etc., and the examples in the > document also include SIP URIs and domain names. Please let > me know if you have suggestions to clarify it further. > > > > > 2-It is no longer reasonable to assume a mapping between > "telephone number" > > and "location" or a particular SIP proxy. A mobile phone could be > > anywhere- the number is not at all related to which SIP > proxy it is using. > > And even number portability for landline phones makes it a less > > useful mapping. > > Here the typical overload destination would more likely be a > call center than a mobile phone. I don't know how exactly > number portability would matter, as long as they are > forwarded to the correct proxy ... correct me if I were wrong. > > > > > 3- It might be more practical to invoke the load controls > based on the > > next/previous SIP proxy or SIP server, rather than some > representation > > of the "phone number". > > > > comments as in 1. > > > Second, the approach propagates the load controls from one > SIP Proxy > > to the adjacent ones. The first example given is an > "acceptable call > > rate" to a TV program "hotline". The SIP proxy then > "allocates" the > > acceptable call rate among its neighbors. I think that propagating > > the load controls across multiple proxies is likely to create more > > problems than it solves > > > > 1- It is highly unlikely that the actual call rate is uniformly, or > > even predictably, distributed among the neighbors. This > means that > > it is highly likely that some of the neighbors will have a > bigger call > > rate to the TV > > hot line, meaning they will block calls, while others will > have lower > > volume, and will not need to block calls. The call rate at the TV > > hotline will then be below the "acceptable call rate", and > there will > > be many calls that were unnecessarily blocked. This concern also > > applies to the second example given. > > The example shows how the event package, with appropriate > input values, could be used. The input values to the event > package are outputs of a specific overload algorithm, which > may be distributed or centralized, or hybrid. As mentioned, > the overload algorithm itself is out of scope of this event > package document. But if the algorithm produces a dynamic > rate output, there is no reason why the rate distribution by > the event package could not be dynamic. I can clarify this in > the next revision. > > > > > Finally, your approach make no mention of exempting SIP > requests with > > particular RPH values form these load controls, as required > by Req 13 > > of > > RFC 5390. > > Maybe we can add something like the RPH mechanism takes > precedence over this filtering in the next revision. > > Thanks > > Charles > > > > > > Thanks > > > > Janet > > > > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM: > > > >> [image removed] > >> > >> [sip-overload] Expert Review for Overload Control Drafts > >> > >> Volker Hilt > >> > >> to: > >> > >> sip-overload@ietf.org > >> > >> 10/27/2009 10:36 AM > >> > >> Sent by: > >> > >> sip-overload-bounces@ietf.org > >> > >> All, > >> > >> We are looking for experts who can do a review for the > following two > >> drafts: > >> > >> > > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt > >> > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event- > >> package-03.txt > >> > >> Please send me a quick note if you are interested and > available to do > >> a review for one of these drafts (or both of them). Please > post the > >> review on this mailing list. > >> > >> We had many people expressing interest in contributing to a SIP > >> overload control solution. This is a great chance to do so! > >> > >> Thanks, > >> > >> Volker > >> > >> _______________________________________________ > >> sip-overload mailing list > >> sip-overload@ietf.org > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > --=_alternative 0066930785257677_= Content-Type: text/html; charset="US-ASCII"
I agree,

We don't need a blanket "exemption for anything with RPH".  We need the ability (using configuration) to exempt SIP messages with particular RPH values from particular aspects of the network controls.

To go back to the SS7 world, we do NOT want GETS calls (equivalent to RPH namespaces ets and wps) to be exempt from "100% cancel-to" (which typically is associated with equipment failure), but we DO (in general) want them exempt from "x% cancel-to" for X not equal 100.

There may very well also  be cases where you want a network control to apply specifically to a particular RPH namespace, as in the RPH for 911-type emergency calls.

What we need is for the overload mechanism to have the ability to distinguish, and give different treatment to, messages with specific RPH values.

Janet

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


From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: Charles Shen <charles@cs.columbia.edu>, Janet P Gunn/USA/CSC@CSC
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata Koike <koike.arata@lab.ntt.co.jp>, Henning Schulzrinne <hgs@cs.columbia.edu>
Date: 11/23/2009 12:43 PM
Subject: RE: [sip-overload] Expert Review for Overload Control Drafts




You said:

> > Finally, your approach make no mention of exempting SIP
> requests with
> > particular RPH values form these load controls, as required
> by  Req 13
> > of
> >  RFC 5390.
>
> Maybe we can add something like the RPH mechanism takes
> precedence over this filtering in the next revision.
>

I not sure it is entirely a matter of exempting, or precedence invalidating the filtering.

Surely if for example if I have an RPH for emergency calls (proposed), it is possible to locally overload the network with just emergency calls, and therefore we need the overload mechanism to operate in some manner.

Further calls with RPH do not necessarily remove the ability for other calls to be made entirely, merely guarantee that a certain percentage of the traffic is reserved for priority calls (for example).

What we surely need is for the overload algorithms to apply, but to take into account the RPH in performing their activity.

regards

Keith

> -----Original Message-----
> From: sip-overload-bounces@ietf.org
> [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen
> Sent: Monday, November 23, 2009 2:50 PM
> To: Janet P Gunn
> Cc: sip-overload@ietf.org; Arata Koike; Henning Schulzrinne
> Subject: Re: [sip-overload] Expert Review for Overload Control Drafts
>
> Hi Janet, thanks for your review. please see comments inline:
>
> On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn <jgunn6@csc.com> wrote:
> >
> >
> > With regard to
> > A Session Initiation Protocol (SIP) Load Control Event Package
> > draft-shen-sipping-load-control-event-package-03.txt
> > I have concerns about a number of the basic premises.
> >
> > First, the approach seems to depend on landline  
> "telephone numbers"
> > and "Tel URIs".
> >
> > 1- It seems that load control should apply to ALL SIP sessions, not
> > just
> >  voice calls with an associated phone  number (or even a Tel URI)
>
> It is a clear goal of this draft *not* to limit on "telephone
> numbers", but to support SIP URIs, *including* Tel URIs that
> could be associated to phone numbers. Therefore, as the
> document suggests, the call identity to be filtered is based
> on the SIP <from>, <to> header etc., and the examples in the
> document also include SIP URIs and domain names. Please let
> me know if you have suggestions to clarify it further.
>
> >
> > 2-It is no longer reasonable to assume a mapping between
> "telephone number"
> > and "location" or a particular SIP  proxy.  A mobile phone could be
> > anywhere- the number is not at all related to which SIP
> proxy it is  using.
> >  And even number portability for landline phones makes it a less
> > useful mapping.
>
> Here the typical overload destination would more likely be a
> call center than a mobile phone. I don't know how exactly
> number portability would matter, as long as they are
> forwarded to the correct proxy ... correct me if I were wrong.
>
> >
> > 3- It might be more practical to invoke the load controls
> based on the
> > next/previous SIP proxy or SIP server, rather than some
> representation
> > of the "phone number".
> >
>
> comments as in 1.
>
> > Second, the approach propagates the load controls from one  
> SIP Proxy
> > to the adjacent ones.  The first example given  is an
> "acceptable call
> > rate"  to a TV program "hotline".  The SIP proxy then
> "allocates" the
> > acceptable call rate  among its neighbors. I think that propagating
> > the load controls across multiple proxies is likely to create more
> > problems than it solves
> >
> > 1- It is highly unlikely that the actual call rate is uniformly, or
> > even predictably, distributed among the  neighbors.  This
> means that
> > it is highly likely that some of the neighbors will have a
> bigger call
> > rate to the TV
> >  hot line, meaning they will block calls, while others will
> have lower
> > volume, and will not need to block calls.  The  call rate at the TV
> > hotline will then be below the "acceptable call rate", and
> there will
> > be many calls that were unnecessarily blocked.  This concern also
> > applies to the second example given.
>
> The example shows how the event package, with appropriate
> input values, could be used. The input values to the event
> package are outputs of a specific overload algorithm, which
> may be distributed or centralized, or hybrid. As mentioned,
> the overload algorithm itself is out of scope of this event
> package document. But if the algorithm produces a dynamic
> rate output, there is no reason why the rate distribution by
> the event package could not be dynamic. I can clarify this in
> the next revision.
>
> >
> > Finally, your approach make no mention of exempting SIP
> requests with
> > particular RPH values form these load controls, as required
> by  Req 13
> > of
> >  RFC 5390.
>
> Maybe we can add something like the RPH mechanism takes
> precedence over this filtering in the next revision.
>
> Thanks
>
> Charles
>
>
> >
> > Thanks
> >
> > Janet
> >
> > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM:
> >
> >> [image removed]
> >>
> >> [sip-overload] Expert Review for Overload Control Drafts
> >>
> >> Volker Hilt
> >>
> >> to:
> >>
> >> sip-overload@ietf.org
> >>
> >> 10/27/2009 10:36 AM
> >>
> >> Sent by:
> >>
> >> sip-overload-bounces@ietf.org
> >>
> >> All,
> >>
> >> We are looking for experts who can do a review for the
> following two
> >> drafts:
> >>
> >>
> >
> http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt
> >>
> >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-
> >> package-03.txt
> >>
> >> Please send me a quick note if you are interested and
> available to do
> >> a review for one of these drafts (or both of them). Please
> post the
> >> review on this mailing list.
> >>
> >> We had many people expressing interest in contributing to a SIP
> >> overload control solution. This is a great chance to do so!
> >>
> >> Thanks,
> >>
> >> Volker
> >>
> >> _______________________________________________
> >> sip-overload mailing list
> >> sip-overload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sip-overload
> >
> > _______________________________________________
> > sip-overload mailing list
> > sip-overload@ietf.org
> > https://www.ietf.org/mailman/listinfo/sip-overload
> >
> >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>

--=_alternative 0066930785257677_=-- From hgs@cs.columbia.edu Mon Nov 23 10:55:25 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482C03A6819 for ; Mon, 23 Nov 2009 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbySweJ09cFy for ; Mon, 23 Nov 2009 10:55:24 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 897583A695D for ; Mon, 23 Nov 2009 10:55:24 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nANItHU5008469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2009 13:55:18 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> Date: Mon, 23 Nov 2009 13:55:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:55:25 -0000 So far, event packages come with a schema. Without it, you don't get = meaningful interoperability. I'm afraid I just don't understand the = problem. Do you have a problem with the current proposal on a technical = level? On Nov 23, 2009, at 1:39 PM, = wrote: > Why not splitting the document into two RFCs? RFC-X would define the = event package but not mandate any schema. RFC-Y would specify an IETF = default schema. Anyone using the event package with exclusively a = different schema would claim conformance to RFC-X but not to RFC-Y. > Bruno From charles.newyork@gmail.com Mon Nov 23 11:44:31 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F6C3A6984 for ; Mon, 23 Nov 2009 11:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoZoh3GLZhHj for ; Mon, 23 Nov 2009 11:44:29 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id D38BB3A6A14 for ; Mon, 23 Nov 2009 11:44:29 -0800 (PST) Received: by pxi1 with SMTP id 1so4295088pxi.32 for ; Mon, 23 Nov 2009 11:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=8H5RcQfLCeD70QtVj6JK6mpdh+wSBdRnl2zvAd82m60=; b=tePPoMosdBSaOlKpS/9nM5ppPbVcDPr1U8aLaAQf7KrMhxzpb1fj7/N9L2FycXwtXN lrc1lHX1Clno1NrBLwGnNZz3m9S2zGMg5645KkSQNPZXijfI71BiEHjczrfE4Zf2DkBp Xaq1ILN/bFCUi9mpeCRiYaSsXjsa2qhe61TmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KBL/kk+iQirIAsYMCOHSkmttlhcBxT2j+MgLGc9ssTAdZqNcFZijoISfXxS2q+Jz2P 4zODeXbnhOSa2ge/6iPp8eJI6tzhwXUI/tR//yvjAfdVwoQp2qNbynHiHaWAYw7twA4G dg5M6vpCb+1ulMe25NiEIfoSmsPKXoGEPoyL4= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.143.129.7 with SMTP id g7mr569279wfn.336.1259005462033; Mon, 23 Nov 2009 11:44:22 -0800 (PST) In-Reply-To: References: <4AE7055E.9060208@alcatel-lucent.com> Date: Mon, 23 Nov 2009 14:44:21 -0500 X-Google-Sender-Auth: fe71781faa15a01f Message-ID: From: Charles Shen To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:44:31 -0000 I agree too that appropriate treatment of the RPH (not simply an exclusive exemption) needs to be defined. But I am not sure whether the detailing of such treatment is in the scope of the event package document. We might want a somewhat unified RPH treatment to be applicable to the general overload handling scenarios, regardless of how the overload information is conveyed. Note that the related draft, draft-hilt-sipping-overload-07 currently has the following description. **** 4.1. Message Prioritization During an overload condition, a SIP server needs to prioritize messages and select messages that need to be rejected or redirected. The selection is largely a matter of local policy. A SIP server SHOULD honor the Resource-Priority header field as defined in RFC4412 [RFC4412] if it is present in a SIP request. The Resource-Priority header field enables a proxy to identify high- priority requests, such as emergency service requests, and preserve them as much as possible during times of overload. **** Thanks Charles On Mon, Nov 23, 2009 at 1:40 PM, Janet P Gunn wrote: > > I agree, > > We don't need a blanket "exemption for anything with RPH". =C2=A0We need = the ability (using configuration) to exempt SIP messages with particular RP= H values from particular aspects of the network controls. > > To go back to the SS7 world, we do NOT want GETS calls (equivalent to RPH= namespaces ets and wps) to be exempt from "100% cancel-to" (which typicall= y is associated with equipment failure), but we DO (in general) want them e= xempt from "x% cancel-to" for X not equal 100. > > There may very well also =C2=A0be cases where you want a network control = to apply specifically to a particular RPH namespace, as in the RPH for 911-= type emergency calls. > > What we need is for the overload mechanism to have the ability to disting= uish, and give different treatment to, messages with specific RPH values. > > Janet > > This is a PRIVATE message. If you are not the intended recipient, please = delete without copying and kindly advise us by e-mail of the mistake in del= ivery. > NOTE: Regardless of content, this e-mail shall not operate to bind CSC to= any order or other contract unless pursuant to explicit written agreement = or government initiative expressly permitting the use of e-mail for such pu= rpose. > > > From: "DRAGE, Keith (Keith)" > To: Charles Shen , Janet P Gunn/USA/CSC@CSC > Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne > Date: 11/23/2009 12:43 PM > Subject: RE: [sip-overload] Expert Review for Overload Control Drafts > ________________________________ > > > You said: > > > > Finally, your approach make no mention of exempting SIP > > requests with > > > particular RPH values form these load controls, as required > > by =C2=A0Req 13 > > > of > > > =C2=A0RFC 5390. > > > > Maybe we can add something like the RPH mechanism takes > > precedence over this filtering in the next revision. > > > > I not sure it is entirely a matter of exempting, or precedence invalidati= ng the filtering. > > Surely if for example if I have an RPH for emergency calls (proposed), it= is possible to locally overload the network with just emergency calls, and= therefore we need the overload mechanism to operate in some manner. > > Further calls with RPH do not necessarily remove the ability for other ca= lls to be made entirely, merely guarantee that a certain percentage of the = traffic is reserved for priority calls (for example). > > What we surely need is for the overload algorithms to apply, but to take = into account the RPH in performing their activity. > > regards > > Keith > > > -----Original Message----- > > From: sip-overload-bounces@ietf.org > > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen > > Sent: Monday, November 23, 2009 2:50 PM > > To: Janet P Gunn > > Cc: sip-overload@ietf.org; Arata Koike; Henning Schulzrinne > > Subject: Re: [sip-overload] Expert Review for Overload Control Drafts > > > > Hi Janet, thanks for your review. please see comments inline: > > > > On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn wrote: > > > > > > > > > With regard to > > > A Session Initiation Protocol (SIP) Load Control Event Package > > > draft-shen-sipping-load-control-event-package-03.txt > > > I have concerns about a number of the basic premises. > > > > > > First, the approach seems to depend on landline > > "telephone numbers" > > > and "Tel URIs". > > > > > > 1- It seems that load control should apply to ALL SIP sessions, not > > > just > > > =C2=A0voice calls with an associated phone =C2=A0number (or even a Te= l URI) > > > > It is a clear goal of this draft *not* to limit on "telephone > > numbers", but to support SIP URIs, *including* Tel URIs that > > could be associated to phone numbers. Therefore, as the > > document suggests, the call identity to be filtered is based > > on the SIP , header etc., and the examples in the > > document also include SIP URIs and domain names. Please let > > me know if you have suggestions to clarify it further. > > > > > > > > 2-It is no longer reasonable to assume a mapping between > > "telephone number" > > > and "location" or a particular SIP =C2=A0proxy. =C2=A0A mobile phone = could be > > > anywhere- the number is not at all related to which SIP > > proxy it is =C2=A0using. > > > =C2=A0And even number portability for landline phones makes it a less > > > useful mapping. > > > > Here the typical overload destination would more likely be a > > call center than a mobile phone. I don't know how exactly > > number portability would matter, as long as they are > > forwarded to the correct proxy ... correct me if I were wrong. > > > > > > > > 3- It might be more practical to invoke the load controls > > based on the > > > next/previous SIP proxy or SIP server, rather than some > > representation > > > of the "phone number". > > > > > > > comments as in 1. > > > > > Second, the approach propagates the load controls from one > > SIP Proxy > > > to the adjacent ones. =C2=A0The first example given =C2=A0is an > > "acceptable call > > > rate" =C2=A0to a TV program "hotline". =C2=A0The SIP proxy then > > "allocates" the > > > acceptable call rate =C2=A0among its neighbors. I think that propagat= ing > > > the load controls across multiple proxies is likely to create more > > > problems than it solves > > > > > > 1- It is highly unlikely that the actual call rate is uniformly, or > > > even predictably, distributed among the =C2=A0neighbors. =C2=A0This > > means that > > > it is highly likely that some of the neighbors will have a > > bigger call > > > rate to the TV > > > =C2=A0hot line, meaning they will block calls, while others will > > have lower > > > volume, and will not need to block calls. =C2=A0The =C2=A0call rate a= t the TV > > > hotline will then be below the "acceptable call rate", and > > there will > > > be many calls that were unnecessarily blocked. =C2=A0This concern als= o > > > applies to the second example given. > > > > The example shows how the event package, with appropriate > > input values, could be used. The input values to the event > > package are outputs of a specific overload algorithm, which > > may be distributed or centralized, or hybrid. As mentioned, > > the overload algorithm itself is out of scope of this event > > package document. But if the algorithm produces a dynamic > > rate output, there is no reason why the rate distribution by > > the event package could not be dynamic. I can clarify this in > > the next revision. > > > > > > > > Finally, your approach make no mention of exempting SIP > > requests with > > > particular RPH values form these load controls, as required > > by =C2=A0Req 13 > > > of > > > =C2=A0RFC 5390. > > > > Maybe we can add something like the RPH mechanism takes > > precedence over this filtering in the next revision. > > > > Thanks > > > > Charles > > > > > > > > > > Thanks > > > > > > Janet > > > > > > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM: > > > > > >> [image removed] > > >> > > >> [sip-overload] Expert Review for Overload Control Drafts > > >> > > >> Volker Hilt > > >> > > >> to: > > >> > > >> sip-overload@ietf.org > > >> > > >> 10/27/2009 10:36 AM > > >> > > >> Sent by: > > >> > > >> sip-overload-bounces@ietf.org > > >> > > >> All, > > >> > > >> We are looking for experts who can do a review for the > > following two > > >> drafts: > > >> > > >> > > > > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt > > >> > > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event- > > >> package-03.txt > > >> > > >> Please send me a quick note if you are interested and > > available to do > > >> a review for one of these drafts (or both of them). Please > > post the > > >> review on this mailing list. > > >> > > >> We had many people expressing interest in contributing to a SIP > > >> overload control solution. This is a great chance to do so! > > >> > > >> Thanks, > > >> > > >> Volker > > >> > > >> _______________________________________________ > > >> sip-overload mailing list > > >> sip-overload@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > _______________________________________________ > > > sip-overload mailing list > > > sip-overload@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > _______________________________________________ > > sip-overload mailing list > > sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload > > > From jgunn6@csc.com Mon Nov 23 11:56:59 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21263A6837 for ; Mon, 23 Nov 2009 11:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggwRwfycCQSa for ; Mon, 23 Nov 2009 11:56:57 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id 12C8A3A6781 for ; Mon, 23 Nov 2009 11:56:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-86.messagelabs.com!1259006211!11213481!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 5608 invoked from network); 23 Nov 2009 19:56:51 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-10.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2009 19:56:51 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nANJuiAP020355; Mon, 23 Nov 2009 14:56:44 -0500 In-Reply-To: References: <4AE7055E.9060208@alcatel-lucent.com> To: Charles Shen MIME-Version: 1.0 X-KeepSent: FC33AFF7:A2DBD5E8-85257677:006D8C0C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Mon, 23 Nov 2009 14:56:48 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 11/23/2009 02:58:18 PM, Serialize complete at 11/23/2009 02:58:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006D933385257677_=" Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Expert Review for Overload Control Drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:56:59 -0000 This is a multipart message in MIME format. --=_alternative 006D933385257677_= Content-Type: text/plain; charset="US-ASCII" I agree This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. charles.newyork@gmail.com wrote on 11/23/2009 02:44:21 PM: > [image removed] > > Re: [sip-overload] Expert Review for Overload Control Drafts > > Charles Shen > > to: > > Janet P Gunn > > 11/23/2009 02:44 PM > > Sent by: > > charles.newyork@gmail.com > > Cc: > > "DRAGE, Keith (Keith)", Henning Schulzrinne, Arata Koike, "sip- > overload@ietf.org" > > I agree too that appropriate treatment of the RPH (not simply an > exclusive exemption) needs to be defined. But I am not sure whether > the detailing of such treatment is in the scope of the event package > document. We might want a somewhat unified RPH treatment to be > applicable to the general overload handling scenarios, regardless of > how the overload information is conveyed. > > Note that the related draft, draft-hilt-sipping-overload-07 currently > has the following description. > > **** > 4.1. Message Prioritization > > During an overload condition, a SIP server needs to prioritize > messages and select messages that need to be rejected or redirected. > The selection is largely a matter of local policy. > > A SIP server SHOULD honor the Resource-Priority header field as > defined in RFC4412 [RFC4412] if it is present in a SIP request. The > Resource-Priority header field enables a proxy to identify high- > priority requests, such as emergency service requests, and preserve > them as much as possible during times of overload. > **** > > > > > > Thanks > > Charles > > > > On Mon, Nov 23, 2009 at 1:40 PM, Janet P Gunn wrote: > > > > I agree, > > > > We don't need a blanket "exemption for anything with RPH". We > need the ability (using configuration) to exempt SIP messages with > particular RPH values from particular aspects of the network controls. > > > > To go back to the SS7 world, we do NOT want GETS calls (equivalent > to RPH namespaces ets and wps) to be exempt from "100% cancel-to" > (which typically is associated with equipment failure), but we DO > (in general) want them exempt from "x% cancel-to" for X not equal 100. > > > > There may very well also be cases where you want a network > control to apply specifically to a particular RPH namespace, as in > the RPH for 911-type emergency calls. > > > > What we need is for the overload mechanism to have the ability to > distinguish, and give different treatment to, messages with specific > RPH values. > > > > Janet > > > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. > > NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the > use of e-mail for such purpose. > > > > > > From: "DRAGE, Keith (Keith)" > > To: Charles Shen , Janet P Gunn/USA/CSC@CSC > > Cc: "sip-overload@ietf.org" , Arata Koike > , Henning Schulzrinne > > Date: 11/23/2009 12:43 PM > > Subject: RE: [sip-overload] Expert Review for Overload Control Drafts > > ________________________________ > > > > > > You said: > > > > > > Finally, your approach make no mention of exempting SIP > > > requests with > > > > particular RPH values form these load controls, as required > > > by Req 13 > > > > of > > > > RFC 5390. > > > > > > Maybe we can add something like the RPH mechanism takes > > > precedence over this filtering in the next revision. > > > > > > > I not sure it is entirely a matter of exempting, or precedence > invalidating the filtering. > > > > Surely if for example if I have an RPH for emergency calls > (proposed), it is possible to locally overload the network with just > emergency calls, and therefore we need the overload mechanism to > operate in some manner. > > > > Further calls with RPH do not necessarily remove the ability for > other calls to be made entirely, merely guarantee that a certain > percentage of the traffic is reserved for priority calls (for example). > > > > What we surely need is for the overload algorithms to apply, but > to take into account the RPH in performing their activity. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: sip-overload-bounces@ietf.org > > > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen > > > Sent: Monday, November 23, 2009 2:50 PM > > > To: Janet P Gunn > > > Cc: sip-overload@ietf.org; Arata Koike; Henning Schulzrinne > > > Subject: Re: [sip-overload] Expert Review for Overload Control Drafts > > > > > > Hi Janet, thanks for your review. please see comments inline: > > > > > > On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn wrote: > > > > > > > > > > > > With regard to > > > > A Session Initiation Protocol (SIP) Load Control Event Package > > > > draft-shen-sipping-load-control-event-package-03.txt > > > > I have concerns about a number of the basic premises. > > > > > > > > First, the approach seems to depend on landline > > > "telephone numbers" > > > > and "Tel URIs". > > > > > > > > 1- It seems that load control should apply to ALL SIP sessions, not > > > > just > > > > voice calls with an associated phone number (or even a Tel URI) > > > > > > It is a clear goal of this draft *not* to limit on "telephone > > > numbers", but to support SIP URIs, *including* Tel URIs that > > > could be associated to phone numbers. Therefore, as the > > > document suggests, the call identity to be filtered is based > > > on the SIP , header etc., and the examples in the > > > document also include SIP URIs and domain names. Please let > > > me know if you have suggestions to clarify it further. > > > > > > > > > > > 2-It is no longer reasonable to assume a mapping between > > > "telephone number" > > > > and "location" or a particular SIP proxy. A mobile phone could be > > > > anywhere- the number is not at all related to which SIP > > > proxy it is using. > > > > And even number portability for landline phones makes it a less > > > > useful mapping. > > > > > > Here the typical overload destination would more likely be a > > > call center than a mobile phone. I don't know how exactly > > > number portability would matter, as long as they are > > > forwarded to the correct proxy ... correct me if I were wrong. > > > > > > > > > > > 3- It might be more practical to invoke the load controls > > > based on the > > > > next/previous SIP proxy or SIP server, rather than some > > > representation > > > > of the "phone number". > > > > > > > > > > comments as in 1. > > > > > > > Second, the approach propagates the load controls from one > > > SIP Proxy > > > > to the adjacent ones. The first example given is an > > > "acceptable call > > > > rate" to a TV program "hotline". The SIP proxy then > > > "allocates" the > > > > acceptable call rate among its neighbors. I think that propagating > > > > the load controls across multiple proxies is likely to create more > > > > problems than it solves > > > > > > > > 1- It is highly unlikely that the actual call rate is uniformly, or > > > > even predictably, distributed among the neighbors. This > > > means that > > > > it is highly likely that some of the neighbors will have a > > > bigger call > > > > rate to the TV > > > > hot line, meaning they will block calls, while others will > > > have lower > > > > volume, and will not need to block calls. The call rate at the TV > > > > hotline will then be below the "acceptable call rate", and > > > there will > > > > be many calls that were unnecessarily blocked. This concern also > > > > applies to the second example given. > > > > > > The example shows how the event package, with appropriate > > > input values, could be used. The input values to the event > > > package are outputs of a specific overload algorithm, which > > > may be distributed or centralized, or hybrid. As mentioned, > > > the overload algorithm itself is out of scope of this event > > > package document. But if the algorithm produces a dynamic > > > rate output, there is no reason why the rate distribution by > > > the event package could not be dynamic. I can clarify this in > > > the next revision. > > > > > > > > > > > Finally, your approach make no mention of exempting SIP > > > requests with > > > > particular RPH values form these load controls, as required > > > by Req 13 > > > > of > > > > RFC 5390. > > > > > > Maybe we can add something like the RPH mechanism takes > > > precedence over this filtering in the next revision. > > > > > > Thanks > > > > > > Charles > > > > > > > > > > > > > > Thanks > > > > > > > > Janet > > > > > > > > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM: > > > > > > > >> [image removed] > > > >> > > > >> [sip-overload] Expert Review for Overload Control Drafts > > > >> > > > >> Volker Hilt > > > >> > > > >> to: > > > >> > > > >> sip-overload@ietf.org > > > >> > > > >> 10/27/2009 10:36 AM > > > >> > > > >> Sent by: > > > >> > > > >> sip-overload-bounces@ietf.org > > > >> > > > >> All, > > > >> > > > >> We are looking for experts who can do a review for the > > > following two > > > >> drafts: > > > >> > > > >> > > > > > > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt > > > >> > > > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event- > > > >> package-03.txt > > > >> > > > >> Please send me a quick note if you are interested and > > > available to do > > > >> a review for one of these drafts (or both of them). Please > > > post the > > > >> review on this mailing list. > > > >> > > > >> We had many people expressing interest in contributing to a SIP > > > >> overload control solution. This is a great chance to do so! > > > >> > > > >> Thanks, > > > >> > > > >> Volker > > > >> > > > >> _______________________________________________ > > > >> sip-overload mailing list > > > >> sip-overload@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > _______________________________________________ > > > > sip-overload mailing list > > > > sip-overload@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > > > > > > > _______________________________________________ > > > sip-overload mailing list > > > sip-overload@ietf.org > > > https://www.ietf.org/mailman/listinfo/sip-overload > > > > > --=_alternative 006D933385257677_= Content-Type: text/html; charset="US-ASCII"
I agree

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

charles.newyork@gmail.com wrote on 11/23/2009 02:44:21 PM:

> [image removed]
>
> Re: [sip-overload] Expert Review for Overload Control Drafts
>
> Charles Shen
>
> to:
>
> Janet P Gunn
>
> 11/23/2009 02:44 PM
>
> Sent by:
>
> charles.newyork@gmail.com
>
> Cc:
>
> "DRAGE, Keith (Keith)", Henning Schulzrinne, Arata Koike, "sip-
> overload@ietf.org"
>
> I agree too that appropriate treatment of the RPH (not simply an
> exclusive exemption) needs to be defined. But I am not sure whether
> the detailing of such treatment is in the scope of the event package
> document. We might want a somewhat unified RPH treatment to be
> applicable to the general overload handling scenarios, regardless of
> how the overload information is conveyed.
>
> Note that the related draft, draft-hilt-sipping-overload-07 currently
> has the following description.
>
> ****
> 4.1.  Message Prioritization
>
>    During an overload condition, a SIP server needs to prioritize
>    messages and select messages that need to be rejected or redirected.
>    The selection is largely a matter of local policy.
>
>    A SIP server SHOULD honor the Resource-Priority header field as
>    defined in RFC4412 [RFC4412] if it is present in a SIP request.  The
>    Resource-Priority header field enables a proxy to identify high-
>    priority requests, such as emergency service requests, and preserve
>    them as much as possible during times of overload.
> ****
>
>
>
>
>
> Thanks
>
> Charles
>
>
>
> On Mon, Nov 23, 2009 at 1:40 PM, Janet P Gunn <jgunn6@csc.com> wrote:
> >
> > I agree,
> >
> > We don't need a blanket "exemption for anything with RPH".  We
> need the ability (using configuration) to exempt SIP messages with
> particular RPH values from particular aspects of the network controls.
> >
> > To go back to the SS7 world, we do NOT want GETS calls (equivalent
> to RPH namespaces ets and wps) to be exempt from "100% cancel-to"
> (which typically is associated with equipment failure), but we DO
> (in general) want them exempt from "x% cancel-to" for X not equal 100.
> >
> > There may very well also  be cases where you want a network
> control to apply specifically to a particular RPH namespace, as in
> the RPH for 911-type emergency calls.
> >
> > What we need is for the overload mechanism to have the ability to
> distinguish, and give different treatment to, messages with specific
> RPH values.
> >
> > Janet
> >
> > This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.
> > NOTE: Regardless of content, this e-mail shall not operate to bind
> CSC to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the
> use of e-mail for such purpose.
> >
> >
> > From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
> > To: Charles Shen <charles@cs.columbia.edu>, Janet P Gunn/USA/CSC@CSC
> > Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, Arata Koike
> <koike.arata@lab.ntt.co.jp>, Henning Schulzrinne <hgs@cs.columbia.edu>
> > Date: 11/23/2009 12:43 PM
> > Subject: RE: [sip-overload] Expert Review for Overload Control Drafts
> > ________________________________
> >
> >
> > You said:
> >
> > > > Finally, your approach make no mention of exempting SIP
> > > requests with
> > > > particular RPH values form these load controls, as required
> > > by  Req 13
> > > > of
> > > >  RFC 5390.
> > >
> > > Maybe we can add something like the RPH mechanism takes
> > > precedence over this filtering in the next revision.
> > >
> >
> > I not sure it is entirely a matter of exempting, or precedence
> invalidating the filtering.
> >
> > Surely if for example if I have an RPH for emergency calls
> (proposed), it is possible to locally overload the network with just
> emergency calls, and therefore we need the overload mechanism to
> operate in some manner.
> >
> > Further calls with RPH do not necessarily remove the ability for
> other calls to be made entirely, merely guarantee that a certain
> percentage of the traffic is reserved for priority calls (for example).
> >
> > What we surely need is for the overload algorithms to apply, but
> to take into account the RPH in performing their activity.
> >
> > regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: sip-overload-bounces@ietf.org
> > > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Charles Shen
> > > Sent: Monday, November 23, 2009 2:50 PM
> > > To: Janet P Gunn
> > > Cc: sip-overload@ietf.org; Arata Koike; Henning Schulzrinne
> > > Subject: Re: [sip-overload] Expert Review for Overload Control Drafts
> > >
> > > Hi Janet, thanks for your review. please see comments inline:
> > >
> > > On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn <jgunn6@csc.com> wrote:
> > > >
> > > >
> > > > With regard to
> > > > A Session Initiation Protocol (SIP) Load Control Event Package
> > > > draft-shen-sipping-load-control-event-package-03.txt
> > > > I have concerns about a number of the basic premises.
> > > >
> > > > First, the approach seems to depend on landline
> > > "telephone numbers"
> > > > and "Tel URIs".
> > > >
> > > > 1- It seems that load control should apply to ALL SIP sessions, not
> > > > just
> > > >  voice calls with an associated phone  number (or even a Tel URI)
> > >
> > > It is a clear goal of this draft *not* to limit on "telephone
> > > numbers", but to support SIP URIs, *including* Tel URIs that
> > > could be associated to phone numbers. Therefore, as the
> > > document suggests, the call identity to be filtered is based
> > > on the SIP <from>, <to> header etc., and the examples in the
> > > document also include SIP URIs and domain names. Please let
> > > me know if you have suggestions to clarify it further.
> > >
> > > >
> > > > 2-It is no longer reasonable to assume a mapping between
> > > "telephone number"
> > > > and "location" or a particular SIP  proxy.  A mobile phone could be
> > > > anywhere- the number is not at all related to which SIP
> > > proxy it is  using.
> > > >  And even number portability for landline phones makes it a less
> > > > useful mapping.
> > >
> > > Here the typical overload destination would more likely be a
> > > call center than a mobile phone. I don't know how exactly
> > > number portability would matter, as long as they are
> > > forwarded to the correct proxy ... correct me if I were wrong.
> > >
> > > >
> > > > 3- It might be more practical to invoke the load controls
> > > based on the
> > > > next/previous SIP proxy or SIP server, rather than some
> > > representation
> > > > of the "phone number".
> > > >
> > >
> > > comments as in 1.
> > >
> > > > Second, the approach propagates the load controls from one
> > > SIP Proxy
> > > > to the adjacent ones.  The first example given  is an
> > > "acceptable call
> > > > rate"  to a TV program "hotline".  The SIP proxy then
> > > "allocates" the
> > > > acceptable call rate  among its neighbors. I think that propagating
> > > > the load controls across multiple proxies is likely to create more
> > > > problems than it solves
> > > >
> > > > 1- It is highly unlikely that the actual call rate is uniformly, or
> > > > even predictably, distributed among the  neighbors.  This
> > > means that
> > > > it is highly likely that some of the neighbors will have a
> > > bigger call
> > > > rate to the TV
> > > >  hot line, meaning they will block calls, while others will
> > > have lower
> > > > volume, and will not need to block calls.  The  call rate at the TV
> > > > hotline will then be below the "acceptable call rate", and
> > > there will
> > > > be many calls that were unnecessarily blocked.  This concern also
> > > > applies to the second example given.
> > >
> > > The example shows how the event package, with appropriate
> > > input values, could be used. The input values to the event
> > > package are outputs of a specific overload algorithm, which
> > > may be distributed or centralized, or hybrid. As mentioned,
> > > the overload algorithm itself is out of scope of this event
> > > package document. But if the algorithm produces a dynamic
> > > rate output, there is no reason why the rate distribution by
> > > the event package could not be dynamic. I can clarify this in
> > > the next revision.
> > >
> > > >
> > > > Finally, your approach make no mention of exempting SIP
> > > requests with
> > > > particular RPH values form these load controls, as required
> > > by  Req 13
> > > > of
> > > >  RFC 5390.
> > >
> > > Maybe we can add something like the RPH mechanism takes
> > > precedence over this filtering in the next revision.
> > >
> > > Thanks
> > >
> > > Charles
> > >
> > >
> > > >
> > > > Thanks
> > > >
> > > > Janet
> > > >
> > > > sip-overload-bounces@ietf.org wrote on 10/27/2009 10:36:14 AM:
> > > >
> > > >> [image removed]
> > > >>
> > > >> [sip-overload] Expert Review for Overload Control Drafts
> > > >>
> > > >> Volker Hilt
> > > >>
> > > >> to:
> > > >>
> > > >> sip-overload@ietf.org
> > > >>
> > > >> 10/27/2009 10:36 AM
> > > >>
> > > >> Sent by:
> > > >>
> > > >> sip-overload-bounces@ietf.org
> > > >>
> > > >> All,
> > > >>
> > > >> We are looking for experts who can do a review for the
> > > following two
> > > >> drafts:
> > > >>
> > > >>
> > > >
> > > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt
> > > >>
> > > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-
> > > >> package-03.txt
> > > >>
> > > >> Please send me a quick note if you are interested and
> > > available to do
> > > >> a review for one of these drafts (or both of them). Please
> > > post the
> > > >> review on this mailing list.
> > > >>
> > > >> We had many people expressing interest in contributing to a SIP
> > > >> overload control solution. This is a great chance to do so!
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Volker
> > > >>
> > > >> _______________________________________________
> > > >> sip-overload mailing list
> > > >> sip-overload@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/sip-overload
> > > >
> > > > _______________________________________________
> > > > sip-overload mailing list
> > > > sip-overload@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sip-overload
> > > >
> > > >
> > > _______________________________________________
> > > sip-overload mailing list
> > > sip-overload@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> >
 --=_alternative 006D933385257677_=-- From TIMOTHY.L.MORAN@saic.com Mon Nov 23 17:54:40 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F84828C1D5 for ; Mon, 23 Nov 2009 17:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RULOaSDqtG0G for ; Mon, 23 Nov 2009 17:54:35 -0800 (PST) Received: from mclmx.mail.saic.com (mclmx.mail.saic.com [149.8.64.10]) by core3.amsl.com (Postfix) with ESMTP id DE2B128C1D7 for ; Mon, 23 Nov 2009 17:54:34 -0800 (PST) Received: from 0015-its-sbg01.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP id BT-MMP-6919923; Mon, 23 Nov 2009 20:54:27 -0500 X-AuditID: 9508401a-b7cb7ae000001ff8-12-4b0b3cd3a369 Received: from 0015-its-exbh03.us.saic.com (mcl-sixl-nat.saic.com [149.8.64.21]) by (Symantec Brightmail Gateway) with SMTP id 64.B9.08184.3DC3B0B4; Mon, 23 Nov 2009 20:54:27 -0500 (EST) Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-exbh03.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 20:54:27 -0500 Received: from 0256-its-exmp02.us.saic.com ([10.40.16.18]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 20:54:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6CA9.0D7D5837" Date: Mon, 23 Nov 2009 20:54:25 -0500 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A few comments/questions on the overload drafts Thread-Index: AcpgmOercH+vDBNRS/CLgzWhsPvuQwMD4mkQ From: "Moran, Timothy L." To: X-OriginalArrivalTime: 24 Nov 2009 01:54:27.0187 (UTC) FILETIME=[0DE51430:01CA6CA9] X-Brightmail-Tracker: AAAAAA== Cc: Volker Hilt Subject: [sip-overload] FW: A few comments/questions on the overload drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:54:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6CA9.0D7D5837 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops - wrong email address. No wonder these comments never showed up on the list. Timothy Moran _____________________________________________ From: Moran, Timothy L.=20 Sent: Sunday, November 08, 2009 12:29 PM To: sip-overload-bounces@ietf.org Subject: A few comments/questions on the overload drafts A couple of questions/comments on the current SIP Overload Drafts Draft-hilt-sipping-overload-07.txt - 3.5 and 4.0: It is not clear what an "element" should do if it has exhausted all of its downstream elements (ran the oc test on multiple servers with no success). Should it send a 500 or oc or 503 ??? What is the answer for an upstream element that supports oc vs. one that does not? - 3.6 Self Limiting: "The SIP server SHOULD occasionally forward a single request to probe ..." Is a default value for "occasionally" needed? - 4.1 Message Prioritization: "A SIP server should honor the Resource-Priority header ..." Could this be restated to something like: "A SIP server that supports resource priority as defined in RFC 4412, SHALL honor the Resource-Priority header field if it is present in a SIP message." Draft-shen-sipping-load-control-event-package-03.txt - 8.2: "When the user is identified by the source and a favorable action is specified, the result may be comparable to identifying a priority user based on authorized Resource Priority Headers {RFC 4412} in the requests." I'm not sure this is comparable since the invocation of priority calls is regulated to be for emergency purposes only. Thus, a fire chief ordering pizza does not constitute the need for priority treatment - even though the source is an authorized priority service user. - 4.4: "Therefore, the entity that initiates the filter needs to take counter-measures towards any non-conforming neighbors. A simple mode is to just drop excessive requests..." Should this section (paragraph) note the possibility of using priority policy as in RFC 4412 before "dropping" requests? It is recognized that section 8.1 mentions this, but this section especially warrants reference to 4412 (IMHO). Is it possible (in the future) to provide an example scenario (or two) of how the shen and hilt drafts are complementary - a BCP for their combined use so to speak? BR, Timothy Moran=20 703-676-2334 (W) 571-268-0858 (C) ------_=_NextPart_001_01CA6CA9.0D7D5837 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: A few comments/questions on the overload drafts

Oops – = wrong email = address. No wonder these comments never showed up on the = list.

Timothy = Moran

_____________________________________________
From: Moran, Timothy L.
Sent: Sunday, November 08, 2009 = 12:29 PM
To: sip-overload-bounces@ietf.org
Subject: A few comments/questions on the overload = drafts

A couple of questions/comments on the current = SIP Overload Drafts

Draft-hilt-sipping-overload-07.txt

-       3.5 and 4.0: It is not clear what an = “element” should do if it has exhausted all of its downstream elements (ran the oc test on = multiple servers with no success).  Should it send a 500 or oc or = 503 ??? What is the answer for an upstream element that supports oc vs. = one that does not?

-       3.6 Self Limiting:  “The SIP server = SHOULD occasionally forward a = single request to probe …” Is a default value for = “occasionally” needed?

-       4.1 Message Prioritization: “A SIP server = should honor the Resource-Priority header …”  Could = this be restated to something like: ”A SIP server that supports resource priority as defined in = RFC 4412, SHALL honor the Resource-Priority header field if it is = present in a SIP message.”

Draft-shen-sipping-load-control-event-package-03.txt

-       8.2: “When the user is identified by the source and = a favorable action is specified, = the result may be comparable to identifying a priority user based on = authorized Resource Priority Headers {RFC 4412} in the requests.”    I’m = not sure this is comparable since the invocation of priority calls is = regulated to be for emergency purposes only.  Thus, a fire = chief ordering pizza does not constitute the need for priority = treatment – even though the source is an authorized = priority service user.

-       4.4: “Therefore, the entity that initiates = the filter needs to take counter-measures towards any non-conforming neighbors. A simple = mode is to just drop excessive requests…”  Should this = section (paragraph) note the possibility of using priority policy as in = RFC 4412 before “dropping” requests?  It is recognized = that section 8.1 mentions this, but this section especially = warrants reference to 4412 (IMHO).

Is it = possible (in the future) to provide an example scenario (or two) of how = the shen and hilt drafts are complementary – a BCP for = their combined use so to speak?

BR,

Timothy = Moran

703-676-2334 (W)

571-268-0858 (C)

------_=_NextPart_001_01CA6CA9.0D7D5837-- From bruno.chatras@orange-ftgroup.com Wed Nov 25 04:48:02 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4763A6A24 for ; Wed, 25 Nov 2009 04:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xail-rbBX9UQ for ; Wed, 25 Nov 2009 04:48:01 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C127D3A6A39 for ; Wed, 25 Nov 2009 04:48:00 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 13:47:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 13:47:51 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsbpR1lJQqxpJISxqATZHegPkYjgAbVNwA References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> <17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> From: To: X-OriginalArrivalTime: 25 Nov 2009 12:47:53.0995 (UTC) FILETIME=[8162F5B0:01CA6DCD] Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:48:02 -0000 -----Message d'origine----- De : Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Envoy=E9 : lundi 23 novembre 2009 19:55 =C0 : CHATRAS Bruno RD-CORE-ISS Cc : charles@cs.columbia.edu; victor.pascual.avila@gmail.com; = sip-overload@ietf.org; en5192@att.com Objet : Re: [sip-overload] [Fwd: = I-DAction:draft-hilt-sipping-overload-07.txt] So far, event packages come with a schema. Without it, you don't get = meaningful interoperability.=20 =3D=3D>BC: Yes indeed so far all RFCs defining an event package come = with a schema. That's fact but this is not required by RFC3265 nor is = the need for a must-support syntax. Actually, if the following document = becomes an RFC, there will be at least one case where the event = specification (ua-profile) does not come with any schema. http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16 I'm afraid I just don't understand the problem. Do you have a problem = with the current proposal on a technical level? =3D=3D> BC: I don't have any fundamental technical problem with the = current proposal and I think the schema it defines is a good default = schema. However other schema exists. There is at least one alternative = schema documented in an ETSI standard which I believe is likely to be = used at the interface between SIP-based networks managed by Telcos, = while the default package may well be used in other circumstances, = including inside some Telcos' networks.=20 On Nov 23, 2009, at 1:39 PM, = wrote: > Why not splitting the document into two RFCs? RFC-X would define the = event package but not mandate any schema. RFC-Y would specify an IETF = default schema. Anyone using the event package with exclusively a = different schema would claim conformance to RFC-X but not to RFC-Y. > Bruno From bruno.chatras@orange-ftgroup.com Wed Nov 25 05:06:55 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812183A6A24 for ; Wed, 25 Nov 2009 05:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP6ugP1myL1A for ; Wed, 25 Nov 2009 05:06:54 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 1718C3A6935 for ; Wed, 25 Nov 2009 05:06:53 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:06:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 14:06:43 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C7908F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA04F79A23@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsbpR1lJQqxpJISxqATZHegPkYjgAbVNwAADyDFhAAAGQPIA== References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com><9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr><848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu><9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr><17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA04F79A23@gaalpa1msgusr7e.ugd.att.com> From: To: , X-OriginalArrivalTime: 25 Nov 2009 13:06:47.0851 (UTC) FILETIME=[2537A7B0:01CA6DD0] Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:06:55 -0000 Hi Martin, IMS and similar architectures bordered with a set of B2BUA/SBC. Anyway I = should have said "between ***some of the *** SIP-based networks managed = by Telcos" Bruno -----Message d'origine----- De : DOLLY, MARTIN C (ATTLABS) [mailto:md3135@att.com]=20 Envoy=E9 : mercredi 25 novembre 2009 13:53 =C0 : CHATRAS Bruno RD-CORE-ISS; hgs@cs.columbia.edu Cc : charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS); = sip-overload@ietf.org Objet : RE: [sip-overload] = [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] Bruno, What SIP-based networks managed by telcos are you speaking of? Martin -----Original Message----- From: sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com Sent: Wednesday, November 25, 2009 7:48 AM To: hgs@cs.columbia.edu Cc: charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS); = sip-overload@ietf.org Subject: Re: [sip-overload] = [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] -----Message d'origine----- De : Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Envoy=E9 : lundi = 23 novembre 2009 19:55 =C0 : CHATRAS Bruno RD-CORE-ISS Cc : = charles@cs.columbia.edu; victor.pascual.avila@gmail.com; = sip-overload@ietf.org; en5192@att.com Objet : Re: [sip-overload] [Fwd: = I-DAction:draft-hilt-sipping-overload-07.txt] So far, event packages come with a schema. Without it, you don't get = meaningful interoperability.=20 =3D=3D>BC: Yes indeed so far all RFCs defining an event package come = with a schema. That's fact but this is not required by RFC3265 nor is = the need for a must-support syntax. Actually, if the following document = becomes an RFC, there will be at least one case where the event = specification (ua-profile) does not come with any schema. http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16 I'm afraid I just don't understand the problem. Do you have a problem = with the current proposal on a technical level? =3D=3D> BC: I don't have any fundamental technical problem with the = current proposal and I think the schema it defines is a good default = schema. However other schema exists. There is at least one alternative = schema documented in an ETSI standard which I believe is likely to be = used at the interface between SIP-based networks managed by Telcos, = while the default package may well be used in other circumstances, = including inside some Telcos' networks.=20 On Nov 23, 2009, at 1:39 PM, = wrote: > Why not splitting the document into two RFCs? RFC-X would define the = event package but not mandate any schema. RFC-Y would specify an IETF = default schema. Anyone using the event package with exclusively a = different schema would claim conformance to RFC-X but not to RFC-Y. > Bruno _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From hgs@cs.columbia.edu Wed Nov 25 05:21:13 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D103A690A for ; Wed, 25 Nov 2009 05:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCQqEUC4qlhx for ; Wed, 25 Nov 2009 05:21:13 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id E18853A6899 for ; Wed, 25 Nov 2009 05:21:12 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nAPDL5r5003761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2009 08:21:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> Date: Wed, 25 Nov 2009 08:21:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA2582B-597E-4005-8640-0FE686DE1D27@cs.columbia.edu> References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> <17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:21:13 -0000 On Nov 25, 2009, at 7:47 AM, = wrote: > syntax. Actually, if the following document becomes an RFC, there will = be at least one case where the event specification (ua-profile) does not = come with any schema. > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16 >=20 >=20 =46rom my understanding, that draft is essentially dead, having been = replaced by the SIP Forum effort (fortunately, given the former effort's = complexity). > I'm afraid I just don't understand the problem. Do you have a problem = with the current proposal on a technical level? > =3D=3D> BC: I don't have any fundamental technical problem with the = current proposal and I think the schema it defines is a good default = schema. However other schema exists. There is at least one alternative = schema documented in an ETSI standard which I believe is likely to be = used at the interface between SIP-based networks managed by Telcos, = while the default package may well be used in other circumstances, = including inside some Telcos' networks.=20 Nothing prevents the usage of that schema, as far as I can tell. Henning= From drage@alcatel-lucent.com Wed Nov 25 05:25:51 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD5B3A6A24 for ; Wed, 25 Nov 2009 05:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY78JI5vyI7n for ; Wed, 25 Nov 2009 05:25:50 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 0CC6A3A69C3 for ; Wed, 25 Nov 2009 05:25:49 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPDPBtB008362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 14:25:29 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 Nov 2009 14:25:29 +0100 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange-ftgroup.com" , "md3135@att.com" , "hgs@cs.columbia.edu" Date: Wed, 25 Nov 2009 14:25:28 +0100 Thread-Topic: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsbpR1lJQqxpJISxqATZHegPkYjgAbVNwAADyDFhAAAGQPIAAAw9hw Message-ID: References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com><9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr><848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu><9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr><17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA04F79A23@gaalpa1msgusr7e.ugd.att.com> <9ECCF01B52E7AB408A7EB85352642141C7908F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141C7908F@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "charles@cs.columbia.edu" , "en5192@att.com" , "sip-overload@ietf.org" Subject: Re: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:25:51 -0000 There is nothing special about IMS in this respect. There is no greater req= uirement to use SBC in an IMS than there is in any other SIP based network. regards Keith=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Wednesday, November 25, 2009 1:07 PM > To: md3135@att.com; hgs@cs.columbia.edu > Cc: charles@cs.columbia.edu; en5192@att.com; sip-overload@ietf.org > Subject: Re: [sip-overload]=20 > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Hi Martin, >=20 > IMS and similar architectures bordered with a set of=20 > B2BUA/SBC. Anyway I should have said "between ***some of the=20 > *** SIP-based networks managed by Telcos" >=20 > Bruno >=20 > -----Message d'origine----- > De : DOLLY, MARTIN C (ATTLABS) [mailto:md3135@att.com] Envoy=E9=20 > : mercredi 25 novembre 2009 13:53 =C0 : CHATRAS Bruno=20 > RD-CORE-ISS; hgs@cs.columbia.edu Cc :=20 > charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS);=20 > sip-overload@ietf.org Objet : RE: [sip-overload]=20 > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Bruno, >=20 > What SIP-based networks managed by telcos are you speaking of? >=20 > Martin >=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org=20 > [mailto:sip-overload-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Wednesday, November 25, 2009 7:48 AM > To: hgs@cs.columbia.edu > Cc: charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS);=20 > sip-overload@ietf.org > Subject: Re: [sip-overload]=20 > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > -----Message d'origine----- > De : Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Envoy=E9=20 > : lundi 23 novembre 2009 19:55 =C0 : CHATRAS Bruno RD-CORE-ISS=20 > Cc : charles@cs.columbia.edu; victor.pascual.avila@gmail.com;=20 > sip-overload@ietf.org; en5192@att.com Objet : Re:=20 > [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > So far, event packages come with a schema. Without it, you=20 > don't get meaningful interoperability.=20 > =3D=3D>BC: Yes indeed so far all RFCs defining an event package=20 > come with a schema. That's fact but this is not required by=20 > RFC3265 nor is the need for a must-support syntax. Actually,=20 > if the following document becomes an RFC, there will be at=20 > least one case where the event specification (ua-profile)=20 > does not come with any schema. > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16 >=20 >=20 > I'm afraid I just don't understand the problem. Do you have a=20 > problem with the current proposal on a technical level? > =3D=3D> BC: I don't have any fundamental technical problem with=20 > the current proposal and I think the schema it defines is a=20 > good default schema. However other schema exists. There is at=20 > least one alternative schema documented in an ETSI standard=20 > which I believe is likely to be used at the interface between=20 > SIP-based networks managed by Telcos, while the default=20 > package may well be used in other circumstances, including=20 > inside some Telcos' networks.=20 >=20 >=20 > On Nov 23, 2009, at 1:39 PM,=20 > =20 > wrote: >=20 > > Why not splitting the document into two RFCs? RFC-X would=20 > define the event package but not mandate any schema. RFC-Y=20 > would specify an IETF default schema. Anyone using the event=20 > package with exclusively a different schema would claim=20 > conformance to RFC-X but not to RFC-Y. > > Bruno >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > = From bruno.chatras@orange-ftgroup.com Wed Nov 25 05:40:39 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546C428C233 for ; Wed, 25 Nov 2009 05:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiXum5elqhkD for ; Wed, 25 Nov 2009 05:40:38 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E21AD28C236 for ; Wed, 25 Nov 2009 05:40:37 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:40:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 14:40:29 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C790F1@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload][Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: AcpsbpR1lJQqxpJISxqATZHegPkYjgAbVNwAADyDFhAAAGQPIAAAw9hwAAAiuDA= References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com><9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr><848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu><9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr><17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu><9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr><14C85D6CCBE92743AF33663BF5D24EBA04F79A23@gaalpa1msgusr7e.ugd.att.com> <9ECCF01B52E7AB408A7EB85352642141C7908F@ftrdmel0.rd.francetelecom.fr> From: To: , , X-OriginalArrivalTime: 25 Nov 2009 13:40:30.0616 (UTC) FILETIME=[DAE11980:01CA6DD4] Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:40:39 -0000 Keith, That's not what I meant. Of course one can roll-out an IMS without any = SBC. I don't dispute that. I was just trying to answer Martin's = question: "What SIP-based networks managed by telcos are you speaking = of?". In the context of my previous message "SIP-based networks managed = by Telcos" was a shortcut to refer to networks such as: - IMS-based networks (with or without SBC/IBCF..) - Operator controlled SIP-based networks including typically a number of = application servers and a set of SBCs - ... Anyway, this discussion is a bit aside from my initial point... Bruno -----Message d'origine----- De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 novembre 2009 14:25 =C0 : CHATRAS Bruno RD-CORE-ISS; md3135@att.com; hgs@cs.columbia.edu Cc : charles@cs.columbia.edu; en5192@att.com; sip-overload@ietf.org Objet : RE: = [sip-overload][Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] There is nothing special about IMS in this respect. There is no greater = requirement to use SBC in an IMS than there is in any other SIP based = network. regards Keith=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Wednesday, November 25, 2009 1:07 PM > To: md3135@att.com; hgs@cs.columbia.edu > Cc: charles@cs.columbia.edu; en5192@att.com; sip-overload@ietf.org > Subject: Re: [sip-overload] > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Hi Martin, >=20 > IMS and similar architectures bordered with a set of B2BUA/SBC. Anyway = > I should have said "between ***some of the > *** SIP-based networks managed by Telcos" >=20 > Bruno >=20 > -----Message d'origine----- > De : DOLLY, MARTIN C (ATTLABS) [mailto:md3135@att.com] Envoy=E9 > : mercredi 25 novembre 2009 13:53 =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > hgs@cs.columbia.edu Cc : > charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS); sip-overload@ietf.org = > Objet : RE: [sip-overload]=20 > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > Bruno, >=20 > What SIP-based networks managed by telcos are you speaking of? >=20 > Martin >=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Wednesday, November 25, 2009 7:48 AM > To: hgs@cs.columbia.edu > Cc: charles@cs.columbia.edu; NOEL, ERIC C (ATTLABS);=20 > sip-overload@ietf.org > Subject: Re: [sip-overload] > [Fwd:I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > -----Message d'origine----- > De : Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Envoy=E9 > : lundi 23 novembre 2009 19:55 =C0 : CHATRAS Bruno RD-CORE-ISS Cc :=20 > charles@cs.columbia.edu; victor.pascual.avila@gmail.com;=20 > sip-overload@ietf.org; en5192@att.com Objet : Re: > [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] >=20 > So far, event packages come with a schema. Without it, you don't get=20 > meaningful interoperability. > =3D=3D>BC: Yes indeed so far all RFCs defining an event package come = with=20 > a schema. That's fact but this is not required by > RFC3265 nor is the need for a must-support syntax. Actually, if the=20 > following document becomes an RFC, there will be at least one case=20 > where the event specification (ua-profile) does not come with any=20 > schema. > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-16 >=20 >=20 > I'm afraid I just don't understand the problem. Do you have a problem=20 > with the current proposal on a technical level? > =3D=3D> BC: I don't have any fundamental technical problem with the=20 > current proposal and I think the schema it defines is a good default=20 > schema. However other schema exists. There is at least one alternative = > schema documented in an ETSI standard which I believe is likely to be=20 > used at the interface between SIP-based networks managed by Telcos,=20 > while the default package may well be used in other circumstances,=20 > including inside some Telcos' networks. >=20 >=20 > On Nov 23, 2009, at 1:39 PM, > > wrote: >=20 > > Why not splitting the document into two RFCs? RFC-X would > define the event package but not mandate any schema. RFC-Y would=20 > specify an IETF default schema. Anyone using the event package with=20 > exclusively a different schema would claim conformance to RFC-X but=20 > not to RFC-Y. > > Bruno >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >=20 From bruno.chatras@orange-ftgroup.com Wed Nov 25 05:41:26 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE9A28C232 for ; Wed, 25 Nov 2009 05:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVCL3Z4dVBJn for ; Wed, 25 Nov 2009 05:41:25 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 3891528C11A for ; Wed, 25 Nov 2009 05:41:22 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:41:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 14:41:13 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141C790F8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <3EA2582B-597E-4005-8640-0FE686DE1D27@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] Thread-Index: Acpt0ihvlaZTXGHWQtOX/hazqcHhTwAAav/g References: <4AE5BE5C.1050803@alcatel-lucent.com><5DA01D2CA74FAF40ADF71DB4177D345A02684F69@misout7msgusr7b.ugd.att.com><618e24240910270741i6176eae7n83c5ef983ee31402@mail.gmail.com> <9ECCF01B52E7AB408A7EB85352642141C4B7D2@ftrdmel0.rd.francetelecom.fr> <848C937F-3775-4F0E-91A6-7DDE9E45DA70@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C4BB00@ftrdmel0.rd.francetelecom.fr> <17C02AB2-0C9B-4931-8A55-7E23880B8A18@cs.columbia.edu> <9ECCF01B52E7AB408A7EB85352642141C7905F@ftrdmel0.rd.francetelecom.fr> <3EA2582B-597E-4005-8640-0FE686DE1D27@cs.columbia.edu> From: To: X-OriginalArrivalTime: 25 Nov 2009 13:41:14.0696 (UTC) FILETIME=[F5272C80:01CA6DD4] Cc: charles@cs.columbia.edu, en5192@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] [Fwd: I-DAction:draft-hilt-sipping-overload-07.txt] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:41:26 -0000 =20 > I'm afraid I just don't understand the problem. Do you have a problem with the current proposal on a technical level? > =3D=3D> BC: I don't have any fundamental technical problem with the current proposal and I think the schema it defines is a good default schema. However other schema exists. There is at least one alternative schema documented in an ETSI standard which I believe is likely to be used at the interface between SIP-based networks managed by Telcos, while the default package may well be used in other circumstances, including inside some Telcos' networks.=20 Nothing prevents the usage of that schema, as far as I can tell. =3D=3D>BC: I agree. Nothing prevents the use of that schema. However, according to the current draft, the SIP server sending the SUBSCRIBE request will have to include both schema identifiers in the Allow-Events header field although it may not support the default schema (or at least it does not want to use it towards this peer). Of course in practice this may not be an issue because in such configurations the other SIP server will not support it either (or at least will not be willing to use it) but it sounds more like a trick than a clean solution. From volkerh@bell-labs.com Wed Nov 25 13:45:46 2009 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF493A6B7B for ; Wed, 25 Nov 2009 13:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61OhiMab9WtO for ; Wed, 25 Nov 2009 13:45:45 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 333CC3A6B80 for ; Wed, 25 Nov 2009 13:45:44 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id nAPLjd4v013856; Wed, 25 Nov 2009 15:45:39 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id nAPLjcZq014242; Wed, 25 Nov 2009 15:45:39 -0600 (CST) Received: from [127.0.0.1] (135.3.63.243) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 25 Nov 2009 15:45:38 -0600 Message-ID: <4B0DA57A.5070506@bell-labs.com> Date: Wed, 25 Nov 2009 16:45:30 -0500 From: Volker Hilt User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Moran, Timothy L." References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] FW: A few comments/questions on the overload drafts X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:45:46 -0000 Timothy, some clarifications inline. > > A couple of questions/comments on the current SIP Overload Drafts > > Draft-hilt-sipping-overload-07.txt > > - 3.5 and 4.0: It is not clear what an “element” should do if it > has exhausted all of its downstream elements (ran the oc test on > multiple servers with no success). Should it send a 500 or oc or 503 > ??? Section 4.2. Rejecting Requests has text for this case. It defines the use of the 503 code for these cases. > What is the answer for an upstream element that supports oc vs. one > that does not? > This case is also described in Section 4.2 (second an third paragraph). > - 3.6 Self Limiting: “The SIP server SHOULD occasionally forward > a single request to probe …” Is a default value for “occasionally” needed? > Yes, it makes sense to give a recommendation. I would assume 3 seconds is reasonable. > - 4.1 Message Prioritization: “A SIP server should honor the > Resource-Priority header …” Could this be restated to something like: > ”A SIP server that supports resource priority as defined in RFC 4412, > SHALL honor the Resource-Priority header field if it is present in a SIP > message.” > The current wording is SHOULD. I'm not sure what would be changed by the new wording. Thanks, Volker > Draft-shen-sipping-load-control-event-package-03.txt > > - 8.2: “When the user is identified by the source and a favorable > action is specified, the result may be comparable to identifying a > priority user based on authorized Resource Priority Headers {RFC 4412} > in the requests.” I’m not sure this is comparable since the > invocation of priority calls is regulated to be for emergency purposes > only. Thus, a fire chief ordering pizza does not constitute the need > for priority treatment – even though the source is an authorized > priority service user. > > - 4.4: “Therefore, the entity that initiates the filter needs to > take counter-measures towards any non-conforming neighbors. A simple > mode is to just drop excessive requests…” Should this section > (paragraph) note the possibility of using priority policy as in RFC 4412 > before “dropping” requests? It is recognized that section 8.1 mentions > this, but this section especially warrants reference to 4412 (IMHO). > > Is it possible (in the future) to provide an example scenario (or two) > of how the shen and hilt drafts are complementary – a BCP for their > combined use so to speak? > > BR, > > Timothy Moran > > 703-676-2334 (W) > > 571-268-0858 (C) >