[BLISS] Use of the PUBLISH transaction for the SUS/RES procedures

"Huelsemann, Martin" <Martin.Huelsemann@telekom.de> Fri, 16 May 2008 10:01 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 20CC93A6AFB; Fri, 16 May 2008 03:01:05 -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 5B76C28C18B for <bliss@core3.amsl.com>; Fri, 16 May 2008 03:01:03 -0700 (PDT)
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_DE=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 kHll5MHFJ1ro for <bliss@core3.amsl.com>; Fri, 16 May 2008 03:01:02 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id C0D1B28C186 for <bliss@ietf.org>; Fri, 16 May 2008 03:01:01 -0700 (PDT)
Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 16 May 2008 12:00:52 +0200
Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 12:00:52 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 May 2008 12:00:51 +0200
Message-Id: <CCA850DCD3FBE2479D5076C5C187322203F6E6B7@S4DE9JSAAHW.ost.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Use of the PUBLISH transaction for the SUS/RES procedures
Thread-Index: AciQz+r9ng7ld9VUTHukyvTWGnCPHgDC5O1gBVjDBXADfogu4A==
From: "Huelsemann, Martin" <Martin.Huelsemann@telekom.de>
To: bliss@ietf.org, "Alexeitsev, D" <D.Alexeitsev@telekom.de>
X-OriginalArrivalTime: 16 May 2008 10:00:52.0532 (UTC) FILETIME=[B9A08F40:01C8B73B]
Subject: [BLISS] Use of the PUBLISH transaction for the SUS/RES procedures
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: bliss-bounces@ietf.org
Errors-To: bliss-bounces@ietf.org

Hi, 

the use of the PUBLISH transaction to control the suspension and resume of a Call Completion queue position was previously discussed at the mail list. The outcome was, that it is not appropriate to change the state of the queue by targeting the information to the monitor's AOR.

At the last IETF meeting a different approach was discussed off-line. The caller sends it's own status information in PUBLISH with his own AOR in To: and From: headers. The Request-URI of this PUBLISH request contains the monitor AOR as received in the Call-Info header of the 486 response. 

In this case there is no change in the CC monitor (the queue) state done by the PUBLISH request directly, but either an indirect change of the state based on the information about the caller status. The CC monitor acts as a kind of a state composer, composing the state of the queue from the states of the different callers.

This architecture can even be extended to support the presence service directly. The caller (or the CC agent on behalf of the caller) can send the URI of his presence server to the monitor in a parameter of the initial CC SUBSCRIBE request. The monitor would then subscribe to this URI and receive the presence status of the caller from his presence server. The caller UA (CC agent) would than have to send his presence information only to his regular presence server.

The interworking of the SUS/RES procedures from the PSTN/TCAP are also quite simple when the PUBLISH method is used. Appropriate TCAP SUSPEND indication would be mapped to the "closed" presence PIDF state and RESUME to the "open" PIDF state transported in the PUBLISH method.

Comments are welcome. 


BR, Martin




_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss