[MEDIACTRL] FW: [dispatch] SIP based Media overload control draft
"Parthasarathi R (partr)" <partr@cisco.com> Thu, 03 February 2011 05:48 UTC
Return-Path: <partr@cisco.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA243A6875 for <mediactrl@core3.amsl.com>; Wed, 2 Feb 2011 21:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.201
X-Spam-Level:
X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 h2uQO7EzJYVw for <mediactrl@core3.amsl.com>; Wed, 2 Feb 2011 21:47:59 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id EC6673A6874 for <mediactrl@ietf.org>; Wed, 2 Feb 2011 21:47:58 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMBAIvRSU2Q/khNgWdsb2JhbACWS45kFQEBFiIkoHSbJoJ7glwEhHeKIA
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 Feb 2011 05:51:18 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p135pCIk030182 for <mediactrl@ietf.org>; Thu, 3 Feb 2011 05:51:19 GMT
Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 11:21:16 +0530
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: Thu, 03 Feb 2011 11:21:17 +0530
Message-ID: <A11921905DA1564D9BCF64A6430A623904594D38@XMB-BGL-411.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] SIP based Media overload control draft
Thread-Index: Acu7+lyOL6q/0agWRuinGl+8LnohWAAACHagABtidVAAA6oooAAFAN1AAYvtnVAAJY1L4A==
From: "Parthasarathi R (partr)" <partr@cisco.com>
To: mediactrl@ietf.org
X-OriginalArrivalTime: 03 Feb 2011 05:51:16.0323 (UTC) FILETIME=[5F4E2B30:01CBC366]
Subject: [MEDIACTRL] FW: [dispatch] SIP based Media overload control draft
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2011 05:48:01 -0000
Hi all, draft-partha-dispatch-sip-media-overload-control-00 (http://tools.ietf.org/search/draft-partha-dispatch-sip-media-overload-c ontrol-00) is created to define the problem statement for SIP based Media overload control. AFAIK, Media Resource Broker (MRB) in mediactrl does not solve this issue. Please let me know in case my understanding is wrong. I'm interested in hearing from you whether this problem has to be solved in mediactrl if it is not solved already. Also, Please provide any specific usecase related to mediactrl. I forward the earlier mail thread on dispatch to provide more context. Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Wednesday, February 02, 2011 3:01 PM To: DRAGE, Keith (Keith); Elwell, John; dispatch@ietf.org; dworley@avaya.com Subject: Re: [dispatch] SIP based Media overload control draft Keith/John/Dale, Mediactrl (MRB) discusses about Resource monitoring at media server and currently, there is no mechanism exists for overload control. I attached SoC WG stance on SIP based Media overload control as a note of this mail. As a follow up query, Please let me know your take on whether SIP based media overload has to be solved as part of 1) Mediactrl WG 2) Any other WG exists. If so, Please name it. 3) New WG has to be created. 4) solve as individual draft. 5) or any other IETF way Thanks in advance Partha Note: Sec 1 of draft-ietf-soc-overload-design-04 There are cases in which a SIP server runs other services that do not involve the processing of SIP messages (e.g., processing of RTP packets, database queries, software updates and event handling). These services may, or may not, be correlated with the SIP message volume. These services can use up a substantial share of resources available on the server (e.g., CPU cycles) and leave the server in a condition where it is unable to process all incoming SIP requests. -----Original Message----- From: Parthasarathi R (partr) Sent: Tuesday, January 25, 2011 6:23 PM To: 'DRAGE, Keith (Keith)'; Elwell, John; dispatch@ietf.org Cc: 'dworley@avaya.com' Subject: RE: SIP based Media overload control draft Keith, AFAIK, the mentioned issue is not solved in MRB. Including Dale Worley (Mediactrl WG Chair) in this mail thread to double confirm my understanding. Apart from the Mediactrl Mediaservers, I'm trying to find the solution for devices which acts as both Application server(AS) and Media Server (MS) at the same time. In the deployment, these devices shall be realized as PSTN GW, SBC, IP PBX with media handling. Thanks Partha -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Tuesday, January 25, 2011 3:31 PM To: Elwell, John; Parthasarathi R (partr); dispatch@ietf.org Subject: RE: SIP based Media overload control draft If they are mediaservers, then does not the media resource broker in mediactrl already address this issue. Regards Keith -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Elwell, John Sent: 25 January 2011 08:28 To: Parthasarathi R (partr); dispatch@ietf.org Subject: Re: [dispatch] SIP based Media overload control draft Partha, A fundamental difference between the problem addressed by SOC and the problem stated in your draft is as follows. SOC addresses the problem where a SIP server is so overloaded that receipt of further SIP requests will compound the problem, and therefore it is essential to take steps to reduce the number of SIP requests arriving at the overloaded server. The problem described in your draft is where the server is not overloaded in the sense of being unable to handle further SIP requests, but is overloaded in terms of media it can handle. Therefore it can still receive SIP requests, but it would have to reject some of them if the necessary media resources are not available. There may still be some benefit in preventing SIP requests arriving if media resources are not available. The main benefit would be that those SIP requests can more quickly be rerouted elsewhere, thereby reducing call set-up time. One scenario that might benefit would be where there are several, perhaps 10 or more, candidate media servers for a particular request, and trying each of these in turn would definitely impact call establishment times (or call rejection times on occasions when all candidates are overloaded). Is this the essence of the problem you are trying to address? It seems the document could certainly do with more on use cases and potential benefits that a solution might bring. John > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > Sent: 24 January 2011 19:38 > To: dispatch@ietf.org > Subject: [dispatch] SIP based Media overload control draft > > Hi all, > > IETF SoC WG is created for overload control solution of dedicated SIP > signaling server only. There is an another kind of SIP servers exists > in SIP deployment which handle SIP signaling and its related media > (RTP, > T.38) in the same physical device. Those servers needs separate SIP > based overload control solution. SIP based Media overload control > draft summarizes problem specific to SIP media servers overload, > requirements for SIP based media overload control solution and the > draft is available at > > http://datatracker.ietf.org/doc/draft-partha-dispatch-sip-medi > a-overload > -control/ > > draft-partha-dispatch-resource-availability-00 and > draft-jones-sip-overload-sce-00 are submitted in IETF-78 SoC WG for > addressing the same problem. But, SIP based media overload control is > considered as outside the scope of SoC WG. I'm interested in hearing > from you whether this is a worth solving problem in IETF. > > This draft is in straw-horse proposal state. I post this draft in > dispatch to identify which WG is right place to solve this issue in > IETF in case it is considered as worth solving problem. > > Thanks > Partha > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, January 25, 2011 12:37 AM > To: Parthasarathi R (partr) > Subject: New Version Notification for > draft-partha-dispatch-sip-media-overload-control-00 > > > A new version of I-D, > draft-partha-dispatch-sip-media-overload-control-00.txt has been > successfully submitted by Parthasarathi R and posted to the IETF > repository. > > Filename: draft-partha-dispatch-sip-media-overload-control > Revision: 00 > Title: Session Initiation Protocol (SIP) > based Media overload > control Requirement > Creation_date: 2011-01-24 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > Overload occurs in Session Initiation Protocol (SIP) networks when SIP > servers have insufficient resources to handle all SIP messages they > receive. SIP based overload mechanism exists for dedicated SIP > signaling servers. But there is a need for overload control solution > of SIP based media servers like PSTN GW, Session border controllers > (SBC), Session Recording Server(SRS). This document summarizes > problem specific to SIP media servers, requirements for the solution > of SIP based media overload control. > > > > > The IETF Secretariat. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
- [MEDIACTRL] FW: [dispatch] SIP based Media overlo… Parthasarathi R (partr)
- Re: [MEDIACTRL] FW: [dispatch] SIP based Media ov… MUNSON, GARY A (ATTSI)