IETF Logo Mail Archive

Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 22 March 2013 16:49 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F225B21F8F08 for <sip-overload@ietfa.amsl.com>; Fri, 22 Mar 2013 09:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.549
X-Spam-Level:
X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKb1h+ufMxdz for <sip-overload@ietfa.amsl.com>; Fri, 22 Mar 2013 09:49:56 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3003421F8F06 for <sip-overload@ietf.org>; Fri, 22 Mar 2013 09:49:56 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2MGnsO3021867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 11:49:54 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MGnsMm001425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 11:49:54 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MGnsBX016565; Fri, 22 Mar 2013 11:49:54 -0500 (CDT)
Message-ID: <514C8C5B.30105@bell-labs.com>
Date: Fri, 22 Mar 2013 11:52:43 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: bruno.chatras@orange.com
References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <20305_1360573159_5118B2E6_20305_1921_3_88CAD1D4E8773F42858B58CAA28272A0109278@PEXCVZYM12.corporate.adroot.infra.ftgroup> <514C783E.8000907@bell-labs.com> <20666_1363970510_514C89CD_20666_96_1_88CAD1D4E8773F42858B58CAA28272A015CA29@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <20666_1363970510_514C89CD_20666_96_1_88CAD1D4E8773F42858B58CAA28272A015CA29@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2013 16:49:57 -0000

On 03/22/2013 11:41 AM, bruno.chatras@orange.com wrote:
> Hi Vijay,
>
> I realize that the relation between my question and 5.10.2 was a bit
> confusing. I had in mind the following scenario:
>
> A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has
> to forward it to an overloaded downstream server. This Proxy or B2BUA
> has received overloaded control feedback from the overloaded server.
> Because of that it has to reject some requests received from the
> upstream UAC (It could also send it to another destination but as
> mentioned in clause 5.10: "In many cases, however, it will need to
> reject these requests").
>
> So my question is: Which SIP response to send in this case? I assume
> & "503 (Service Unavailable)" response without the Retry-After header
> would be appropriate but I did not find it explicitly stated in the
> document.

Bruno: OK, I will update as you suggest.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

v2.8.7 | Report a Bug | By Email