Re: [sip-overload] draft-ietf-soc-overload-design-05

"Vijay K. Gurbani" <> Tue, 19 April 2011 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49F13E0691 for <>; Tue, 19 Apr 2011 07:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1KWE7KK9B82H for <>; Tue, 19 Apr 2011 07:59:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79323E0664 for <>; Tue, 19 Apr 2011 07:59:55 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p3JExsK5004643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Tue, 19 Apr 2011 09:59:55 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p3JExs9i017563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Tue, 19 Apr 2011 09:59:54 -0500
Received: from ( []) by (8.13.8/TPES) with ESMTP id p3JExsiP008128 for <>; Tue, 19 Apr 2011 09:59:54 -0500 (CDT)
Message-ID: <>
Date: Tue, 19 Apr 2011 10:02:00 -0500
From: "Vijay K. Gurbani" <>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2011 14:59:56 -0000

On 04/19/2011 09:30 AM, ken carlberg wrote:
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.

As the editor of draft-ietf-sip-overload-control, I have read this
thread with interest.

So, the question now is: what, if any, from this thread carries over
into the draft-ietf-sip-overload-control draft?  I am certainly not
up to verse with RPH as some of the members of this working group
are, so I will depend on them to point out any text that should be
modified in draft-ietf-sip-overload-control.

For the sake of completeness, here is what
draft-ietf-sip-overload-control has to say about prioritizing
requests containing the RPH header:

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

Do we deem this to be enough?


- vijay
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{,} /