[BLISS] Issue with CC possible indication and forking proxies
"Alexeitsev, D" <D.Alexeitsev@telekom.de> Mon, 16 June 2008 13:45 UTC
Return-Path: <bliss-bounces@ietf.org>
X-Original-To: bliss-archive@optimus.ietf.org
Delivered-To: ietfarch-bliss-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10593A6ADC; Mon, 16 Jun 2008 06:45:56 -0700 (PDT)
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657D83A67A2 for <bliss@core3.amsl.com>; Mon, 16 Jun 2008 06:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 uQCE5HF3DEtV for <bliss@core3.amsl.com>; Mon, 16 Jun 2008 06:45:48 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 9C7743A6AE4 for <bliss@ietf.org>; Mon, 16 Jun 2008 06:45:45 -0700 (PDT)
Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP for bliss@ietf.org; Mon, 16 Jun 2008 15:46:23 +0200
Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 15:46:05 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 16 Jun 2008 15:46:04 +0200
Message-Id: <F452BB3496398949B9D6634F9B6B1557042782FB@S4DE9JSAAMW.ost.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Issue with CC possible indication and forking proxies
Thread-Index: AcjPrdQXZa277irUSBCwK5P0zM9Qfg==
From: "Alexeitsev, D" <D.Alexeitsev@telekom.de>
To: bliss@ietf.org
X-OriginalArrivalTime: 16 Jun 2008 13:46:05.0147 (UTC) FILETIME=[52943AB0:01C8CFB7]
Subject: [BLISS] Issue with CC possible indication and forking proxies
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0556393263=="
Sender: bliss-bounces@ietf.org
Errors-To: bliss-bounces@ietf.org
Hi, There is an issue with the transport of the CC possible indication in the 486 response and the forking proxies. The issue is following - consider an INVITE from A to AOR-B that gets forked by a proxy to AOR-C and AOR-D. If any of the targets AOR-C and AOR-D is busy the possible CCBS possible indication in any of the 486 responses will not survive the response aggregation in proxy and will not make it's way to the A. Let's call this scenario A) proxy with no monitor forking to foreign AORs. In my opinion there is no issues, as there is no possible way to make such a scenario function fair, so there is not problem is the CC service will not function in this case at all. In the following scenarios the assumption is that there are no proxies from the scenario A) preceding the acting proxy. If there are any than the scenario A) applies. Consider an INVITE from A to AOR-B that gets forked by the proxy with monitor to the Contact-B and AOR-C. If the Contact-B is busy and AOR-C is ringing, the 486 and 180 responses get aggregated to 180 with no CCNR. If both Contact-B and AOR-C are busy the proxy with the monitor will provide the 486 with CCBS possible indication monitoring the status of the Contact-B. If Contact-B is ringing than independent from the state of the AOR-C the proxy with the monitor will provide the 180 with the CCNR possible indication. Let's call this scenario B) proxy with monitor forking to local contacts and foreign AORs Scenario C) would be proxy with monitor forking to local contacts only. This is where the local policy for the aggregation and generation of the CC possible indication would apply. To sum-up - the scenario B and C will function properly, the scenario A will not function, but this is acceptable from my point of view as the A) scenario is not the common case. This all means that we do not have to do anything special to support the transport of 486 or 180 messages carrying the CC possible indication from B to A. Comments, questions? Greetings, Denis
_______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss
- [BLISS] Issue with CC possible indication and for… Alexeitsev, D
- Re: [BLISS] Issue with CC possible indication and… Paul Kyzivat
- Re: [BLISS] Issue with CC possible indication and… Dale.Worley