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

[Paul Kyzivat <[e-mail]>]

WORLEY, Dale R (Dale) wrote:
> 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.

Not exactly. The notifications each receive may differ due to filtering. 
The filter may have been supplied by the subscriber, or it may be 
supplied by the notifier as a result of policy decisions.

Hence, different subscribers may see differing subsets of the state.

> 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

Another solution to this is:

Formulate the state of the queue as a list of the entries in the queue, 
each containing identifying information and an indicator for whether it 
is "active".

Then have a default filter for "normal" subscribers that only allows 
them to see entries for themself.

As a result, normal subscribers will get an initial notification with 
their own entry, indicating "inactive". Then they will get no further 
notification until the part of the state visible to them changes, which 
is when they become "active".

More "privileged" subscribers might be able to see the complete list.

	Thanks,
	Paul

> 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:[e-mail];m=BS;u=28k0a6b3d7e8f25a> and the other caller
> would subscribe to <sip:[e-mail];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
> _______________________________________________
> BLISS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bliss
>