[BLISS] Call-completion issue 2005: PUBLISH destination

"WORLEY, Dale R (Dale)" <dworley@avaya.com> Thu, 22 July 2010 20:42 UTC

Return-Path: <dworley@avaya.com>
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 AE0C93A685F for <bliss@core3.amsl.com>; Thu, 22 Jul 2010 13:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599]
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 SmzK-NNSF0Ne for <bliss@core3.amsl.com>; Thu, 22 Jul 2010 13:42:45 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 3A25D3A67A1 for <bliss@ietf.org>; Thu, 22 Jul 2010 13:42:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.55,245,1278302400"; d="scan'208";a="229184215"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jul 2010 16:42:57 -0400
X-IronPort-AV: E=Sophos;i="4.55,244,1278302400"; d="scan'208";a="493938387"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jul 2010 16:42:57 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 22 Jul 2010 16:42:57 -0400
From: "WORLEY, Dale R (Dale)" <dworley@avaya.com>
To: "bliss@ietf.org" <bliss@ietf.org>
Date: Thu, 22 Jul 2010 16:42:57 -0400
Thread-Topic: Call-completion issue 2005: PUBLISH destination
Thread-Index: AQHLIghF5ZC7isBRu06YP9hZWt7IPA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FE98EEB4@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [BLISS] Call-completion issue 2005: PUBLISH destination
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/mail-archive/web/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>
X-List-Received-Date: Thu, 22 Jul 2010 20:42:46 -0000

We use PUBLISH to suspend and resume CC requests.  But it seems to me that we haven't got an effective way for the PUBLISH to identify which CC subscription it modifies.

A very effective solution would be to send the PUBLISH in the subscription dialog, as that would make it unambiguous which subscription the PUBLISH was for, but reusing dialogs is not recommended any more.   It also might be hard to implement within a "subscribe/notify toolkit".

If the PUBLISH request is out-of-dialog, there are two general ways for it to carry identification of the CC request:  (1) the presentity in the PIDF body, (2) the headers of the PUBLISH, and (3) the request-URI of the PUBLISH.

The PIDF presentity is probably not going to work, as it is likely to be carried to the monitor unchanged from the agent.  Given what SBCs are known to do, there is no URI in the SUBSCRIBE which is assured of reaching the monitor unchanged, so the monitor cannot effectively compare the PIDF presentity to any feature of the subscriptions.

In regard to the headers of the PUBLISH, they are all subject to modifications by SBCs.  But I think we've previously discussed that SBCs are likely to make *consistent* modifications to the From header, so that a SUBSCRIBE and a PUBLISH coming from the same agent are very likely to arrive at the monitor with the same From header, and requests coming from different agents are very likely to arrive with different From headers.

Using the request-URI of the PUBLISH to identify the subscription has the advantage that the one thing SBCs must preserve is the actual destination of a URI.  But to use it would require that each subscription be associated with a different URI. 

More about this later...

Dale