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

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 8 Jul 2010 23:32:18 -0400

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:[email-masked];m=BS;u=28k0a6b3d7e8f25a> and the other caller
would subscribe to <sip:[email-masked];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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 09:06:45 -0400

>   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.

> 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
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 09 Jul 2010 09:10:58 -0400

On 2010-07-08 23:32, WORLEY, Dale R (Dale) wrote:
> we want to do
Why not send the notification to all subscribers, but include in the 
notice an explicit indication of which is active?  Rather than send 
'active', send 'active sip:subscriber@domain' where 
'sip:subscriber@domain' is the contact URI from the head of the queue?

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Fri, 9 Jul 2010 13:02:52 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scott Lawrence [[email-masked]]

It certainly simplifies the situation.  In principle there might be privacy problems.  In practice, SBCs modify the Contact URI, so the agent doesn't know what Contact URI the monitor sees.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 14:01:44 -0400

Would I then be able to subscribe, monitor the notifications, and send 
INVITEs to the contacts I see?

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 20 Jul 2010 10:46:01 +0200

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

Hi all,
Perhaps there is a misunderstanding. The caller subscribes to his own CC
state which is a combination of the caller's position in the queue and
busy state of the callee. 

Therefore it is valid that several callers receive the "queued" state at
the same time, but of course only on caller is notified about the
"ready" state per time. 

Best Regards

Roland and Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 10:48:46 -0400

> busy state of the callee. 

You say that, but I don't see anything in the draft supporting it.
That would imply that each caller is subscribing to a *different* 
resource. But the procedures for identifying the resource to subscribe 
to don't differ from caller to caller. So AFAICT all the callers end up 
subscribing to the *same* resource.

That is why Dale and I are trying to create a mechanism/rationale for 
why the subscribers don't all see the same results.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 22 Jul 2010 15:52:48 +0200

Like Dale has already said there are a lot of privacy issues, and with the potential modifying of the Contact URI by SBC this would be difficult to deploy in practice.

And on the other hand the information we want to provide is the call completion state of the subscriber, which might be different from the queue position (even though it shouldn't be). Anyway the information 'queued' or 'ready for recall' is exactly what we need, so my proposal is to leave it at that and work on Dale's porposal to subscribe to slightly different resources. As some CC implementations are advanced meanwhile we should alos consider some 'backward compatibility' if possible.

Because of the mentioned issue with request URI parameters I am also in favour for a event header parameter based solution. At 3G we also experianced a problem with the m-parameter, due to a TEL URI conversion it isn't conveyed e2e. There we decided to add a Call-Info header to CC requests, which repeats the Request URI incl the m-parameter. If this fits also for our BLISS CC solution we could even define a unique URI parameter.

For the uniqueness: I've also been notified that I have won a 10 000 000 $ price at the National Lottery, so this event can't be very seldom. Therefore it seems we have to spring for some other decimal powers, probably 2^128 values would be okay.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Freitag, 9. Juli 2010 20:02
> An: WORLEY, Dale R (Dale)
> Cc: [email-masked]
> Betreff: Re: [BLISS] Call-completion issue 1010: The event model
> 
> 
> 
> > It certainly simplifies the situation.  In principle there 
> might be privacy problems.  In practice, SBCs modify the 
> Contact URI, so the agent doesn't know what Contact URI the 
> monitor sees.
> 
> Would I then be able to subscribe, monitor the notifications, 
> and send INVITEs to the contacts I see?
> 
> 	Thanks,
> 	Paul