[BLISS] Multiple Session Appearances of an AOR using INVITE

Alan Johnston <alan@sipstation.com> Fri, 30 May 2008 19:52 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 233C93A69C5; Fri, 30 May 2008 12:52:14 -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 A6C9A3A69C5 for <bliss@core3.amsl.com>; Fri, 30 May 2008 12:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 DDg2J3+sSj8v for <bliss@core3.amsl.com>; Fri, 30 May 2008 12:52:06 -0700 (PDT)
Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id DF5E33A6812 for <bliss@ietf.org>; Fri, 30 May 2008 12:52:05 -0700 (PDT)
Received: from 71-81-78-129.dhcp.stls.mo.charter.com ([71.81.78.129] helo=alan-johnstons-powerbook-g4-17.local) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <alan@sipstation.com>) id 1K2Adw-000KVJ-W6 for bliss@ietf.org; Fri, 30 May 2008 19:52:05 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 71.81.78.129
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX189XtAJgNIPuTy6LKtTH4JJrE4v2qFVUsQ=
Message-ID: <48405AE4.7070704@sipstation.com>
Date: Fri, 30 May 2008 14:52:04 -0500
From: Alan Johnston <alan@sipstation.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: bliss@ietf.org
Subject: [BLISS] Multiple Session Appearances of an AOR using INVITE
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

All,

Here is an alternative approach that utilizes sending an INVITE to 
select/reserve/seize an appearance number.

A UA that does not need to select a particular appearance number (or 
doesn't care) would just send an INVITE as normal.    The Appearance 
Agent would tell the proxy which appearance number was being used by 
inserting this information in a header field (such as a parameter in the 
Alert-Info header field) in the first non-100 Trying response sent back 
to the calling UA.  The UA would then PUBLISH this appearance number to 
the Dialog Event State Compositor for the AOR which would distribute 
details of the dialog and the appearance number to the other UAs in the 
group.

If an INVITE is sent and no appearance number is available, the proxy 
would reject the INVITE with a suitable response code and perhaps a 
header field indication.

A UA that does need to select a particular appearance number would use 
an approach similar to overlap dialing (multi-stage dialing).  An INVITE 
would be sent when the appearance number is requested (i.e. when the 
button is pressed, before dialing begins).  The appearance number 
selected would be carried in the INVITE, in a header field, for 
example.  The proxy would reject the INVITE with a 484 Address 
Incomplete response (see RFC 3578) if the appearance number is 
available.  The UA could then resend the INVITE after the URI has been 
dialed and then PUBLISH this appearance number to the ESC.  If the 
appearance number is not available, another response code such as 403 
would be sent.  The user could then select a different appearance number 
and resend the INVITE.

Note that this approach does not actually require a B2BUA, but it does 
require a proxy that can act as a UAS and communicate with an Appearance 
Agent which keeps track of appearance number allocations.

Comments and suggestions are most welcome!

Thanks,
Alan

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