[BLISS] Call-completion issue 1010: The event model

"WORLEY, Dale R (Dale)" <dworley@avaya.com> Fri, 09 July 2010 03:32 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 255593A6B5D for <bliss@core3.amsl.com>; Thu, 8 Jul 2010 20:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Level:
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_40=-0.185, US_DOLLARS_3=0.63]
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 e5cXFFoZGzc3 for <bliss@core3.amsl.com>; Thu, 8 Jul 2010 20:32:56 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 2D9483A688C for <bliss@ietf.org>; Thu, 8 Jul 2010 20:32:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,561,1272859200"; d="scan'208";a="24336211"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 08 Jul 2010 23:32:58 -0400
X-IronPort-AV: E=Sophos;i="4.53,562,1272859200"; d="scan'208";a="490145034"
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; 08 Jul 2010 23:32:58 -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, 8 Jul 2010 23:32:57 -0400
From: "WORLEY, Dale R (Dale)" <dworley@avaya.com>
To: "bliss@ietf.org" <bliss@ietf.org>
Date: Thu, 08 Jul 2010 23:32:18 -0400
Thread-Topic: Call-completion issue 1010: The event model
Thread-Index: AQHLHxdsKihp3v6cxUmNO2O5IPZ9AQ==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FE98EE8B@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 1010: The event model
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: Fri, 09 Jul 2010 03:32:59 -0000

The discussion so far:

> > * 1010  Effect of non-correlation on the event model
> > 
> > In principle, each SUBSCRIBE that arrives identifies some 
> > particular state data.  This is problematic in CC, because we 
> > really want to have each SUBSCRIBE (or rather, each group of 
> > SUBSCRIBEs with the same
> > Call-Id) to identify one "state" (whether that CC request is 
> > chosen for callback), even if there is no overt difference 
> > between two SUBSCRIBEs (other than a different Call-Id).  If 
> > we are doing correlation, then each SUBSCRIBE can be modeled 
> > as monitoring the state associated with the original call.  
> > But if we do not do correlation, SUBSCRIBEs do not map into 
> > original calls, even in theory, and we need to construct a 
> > new event subscription model.  This is probably not 
> > difficult, but does need to be done.
> > 
> >     Section 5 discusses this.  I think this has not been fully
> >     clarified, though, as section 5 says that the SUBSCRIBE is
> >     "addressed to the managed URI" but that the CECE it refers to is
> >     "identified by the request URI".
> 
> Also here I would need some more details.

This is a an extremely technical issue that may affect
implementability of CC.  At the heart of the CC mechanism, we want to
keep a queue of callers, each caller being represented by a
subscription.  The difficulty arises that the structure and use of the
queue isn't well aligned with the official definition of the SIP
subscription and event mechanism.  (See RFC 3265.)  The event
mechanism assumes:

- There is a set of URIs, each of which has a state value.  The state
  values change from time to time due to some external process.

- Each subscription to a URI receives notifications of the state for
  its URI.  As a consequence, two subscriptions to the same URI will
  always receive the same notifications.

In principle, it is a Good Thing if the CC queue subscriptions follow
the official model.  But more importantly, if a SIP implementation has
a "toolkit" for subscriptions and notifications, the toolkit may
*enforce* the official model in that event models that do not fit
within the RFC 3265 model cannot be implemented with the toolkit.  So
if we can, we should adjust the CC queueing mechanism to work within
the official model.

The problem we run into is that if we have two callers awaiting CC for
the same callee, under the current I-D, they will both subscribe to
the same monitor URI.  This makes it impossible (in theory) for the
monitor to send an "active" notification to one of the callers without
sending an "active" notification to the other caller, which isn't what
we want to do.

One solution to this is to have callers subscribe to slightly
different URIs.  Since the URIs are different, each of them can have
different state values.  In order to implement this idea, we would
have to have each caller add a suitably unique parameter to the
monitor URI.  (Or we could instead have each caller add a unique
parameter to the Event header of the SUBSCRIBE, as Event header
parameters are allowed to modify the information returned to the
subscriber.  Or as a third choice, the caller could provide unique
information in the SUBSCRIBE body.  I will discuss those choices
below.)

Since we need the callers to choose the parameter value uniquely, and
there is no way for them to coordinate their choices with each other,
they need to choose statistically random values from a suitably large
set.  By the birthday paradox, the set of random values must have more
values than the square of the largest queue size we expect to support.
As a design goal, I want the protocol to allow supporting CC for the
National Lottery of China, so we need to support 2^32 queue entries,
and the unique value set needs to have at least 2^64 values.  (Which
reminds me that I've received e-mail from the National Lottery of
China saying that I've won the $10,000,000 prize.  I need to call them
about that.)  The simplest value set of this size is 16 lower-case
hexadecimal digits.

Thus, one caller would subscribe to
<sip:carol@example.com;m=BS;u=28k0a6b3d7e8f25a> and the other caller
would subscribe to <sip:carol@example.com;m=BS;u=82ka063bde782fa5>.
(I've chosen 'u' as the name of the parameter, meaning 'unique'.)  A
subscribe/notify toolkit can provide different values for these two
URIs, because they are not the same.

The monitor process needs to pay attention to which URIs are
subscribed to (so that it can choose one and change its value to
"active").  The toolkit must make that information available via the
"watcher" package (RFC 3857/3858), and in principle the monitor can
subscribe to the watcher package for its own URI to find that out.

We can further exploit these unique URIs by the fact that two
SUBSCRIBE requests with the same unique parameter value will have come
from the same agent, and we can safely reject one of them with a 482
response, even if they don't have the same Call-Id.  This helps agents
that aren't able to issue SUBSCRIBEs with the same Call-Id to two
different URIs.  (See issue 1011.)

In regard to where to put the unique parameter in the SUBSCRIBE, there
are at least three choices:  (1) request-URI parameter, (2) Event
header parameter, and (3) request body.  In terms of byte-efficiency
and intrinsic complexity, all choices seem to be the same, but it
seems to me that a subscribe/notify toolkit is more likely to consider
request-URI parameters than Event header parameters or request bodies.

On the other hand, we require the agent to include a SUBSCRIBE to the
original callee URI among the SUBSCRIBEs it generates.  This URI is
likely to be retargeted one or more times.  Whatever mechanism we use
to carry the unique parameter, we want the unique parameter to be
preserved through the retargeting.  Unfortunately, request-URI
parameters are likely to be lost during retargeting.

These considerations suggest that an Event header parameter is
probably the best choice.

Dale