Subject: [dispatch] [Fwd: Re: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03]

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 15:17:30 -0500

-------- Original Message --------
Subject: 	Re: [dispatch] Preliminary version of Expert review
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: 	Thu, 18 Feb 2010 14:00:29 -0600
From: 	Adam Roach <[email-masked]>
To: 	Avasarala Ranjit-A20990 <[email-masked]>
CC: 	Paul Kyzivat <[email-masked]>, John-Luc Bakker <[email-masked]>
References: 	<[email-masked]>
<[email-masked]><[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>
<[email-masked]>

Paul is correct. The real thrust of RFC 3265 is monitoring the state of
something. State becomes interesting at transitions (hence the focus on
events), but the events are inherently talking about the state of something.

In your case, I agree that it won't be call state. It appears to be
related to some combination of call diversion preferences and proxy (?)
processing state? I agree with Paul that the overall model is ill
defined (even after reading 24.604), so I can't provide any concrete
suggestions here. The best I can do is recommend you examine the
existing corpus of event packages and come to an understanding about how
they work:

conference                  package           IETF SIPPING Working Group 
   [RFC4575]
consent-pending-additions   package           Gonzalo Camarillo 
    [RFC5362]
dialog                      package           IETF SIPPING Working Group 
   [RFC4235]
kpml                        package           Eric Burger 
    [RFC4730]
message-summary             package           Rohan Mahy 
    [RFC3842]
poc-settings                package           Miguel A. Garcia-Martin 
    [RFC4354]
presence                    package           Jonathan Rosenberg 
    [RFC3856]
reg                         package           Jonathan Rosenberg 
    [RFC3680]
refer                       package           Robert Sparks 
    [RFC3515]
spirits-INDPs               package           Vijay K. Gurbani 
    [RFC3910]
spirits-user-prof           package           Vijay K. Gurbani 
    [RFC3910]
winfo                       template-package  Jonathan Rosenberg 
    [RFC3857]
xcap-diff                   package           IETF Real-time 
Applications  [RFC-ietf-sip-xcapevent-08.txt]
                                               and Infrastructure Area

You'll note that every one of these event packages actually talks about
the *state* of something, and describes sending notifications when that
*state* changes. And, with the exception of the dialog event package
(and arguably the spirits-INDPs event package),  you'll note that none
of these states are actual call state -- they're the state of the
resource as it pertains to the aspect that the event package monitors.

For your proposed div-notification event package, you need to define
what this state is and how it changes. If you can't do that, then an
RFC3265 event package probably isn't the right tool for the job you have
in mind.

/a

On 2/18/10 11:08, Feb 18, Avasarala Ranjit-A20990 wrote:
> Hi Paul, Adam
>
> Since communication diversion notification information is not related to
> any state of the actual communication, I feel there is no need to
> maintain state for this. Also the Communication diversion notification
> message gets triggered after the communication diversion has occurred.
>
> The main intent of CDIVN is to notify the subscriber of a communication
> diversion that occurred on their behalf in the network. This
> notification is not part of any communication dialog or part of the
> communication state machine and is completely independent of the actual
> communication (or call).
>
> Comments?
>
> Thanks
>
> Regards
> Ranjit
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, February 18, 2010 8:05 AM
> To: Avasarala Ranjit-A20990
> Cc: Adam Roach; John-Luc Bakker
> Subject: Re: [dispatch] Preliminary version of Expert review
> ofdraft-avasarala-dispatch-comm-div-notification-03
>
> Ranjit,
>
> [ taking IESG off the dist list for now, and adding Adam as the sub/not
> author. Perhaps we should take this back to the dispatch list. ]
>
> I haven't had time to read through the revised document yet, but I
> skimmed through your comments. There is one that I think we need to talk
> about because it potentially has significant impact. (I've picked the
> first place it came up, but its also mentioned in other parts of my
> issues and your responses.)
>
> Adam: Is this enough for you to understand the issue?
>
> Avasarala Ranjit-A20990 wrote:
>
>   
>>> ISSUE: The document details the notification body, and some 
>>> inferences
>>>       
>>     
>>> can be drawn about the state from the syntax of the notification
>>>       
> body.
>   
>>> But this is tenuous. There should be an explicit specification of the
>>>       
>   
>>> state maintained, and how it is mapped onto the notification body.
>>>       
>> <Ranjit-Feb16> The notifications for communication diversions are sent
>>     
>   
>> as and when they occur depending on the filter criteria set by the 
>> subscribers. So there is no need of maintaining any state information 
>> for the package.
>>     
> That doesn't fit my understanding of how event packages are defined.
>
> IIUC, the semantics of event packages are described relative to some
> sort of "state", not against another incoming event. (Whether this is
> literally true in the implementation or not.)
>
> So minimally, when a diversion happens, some particular information is
> culled from it, and becomes the new state. Then that causes
> notifications to the existing subscriptions.
>
> After that it either sticks around, or else the state transitions back
> to "none". But if it transitions back to "none" then that would trigger
> another round of notifications - which you clearly don't want.
>
> So it makes sense that it sticks around, in which case, when a new
> subscription comes in it will get a notification about that last
> diversion. (Unless there can be some sort of "implicit" filter that
> suppresses notification when the state becomes "none".)
>
> Adam - is that valid???
>
> 	Thanks,
> 	Paul
>

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 19 Feb 2010 14:40:40 -0800

What is the state model for KPML? Seems to me that that's just as 
stateless as this CDIV package.

Thanks,
Anders

On 2/19/2010 12:17 PM, Paul Kyzivat wrote:
> conference package IETF SIPPING Working Group [RFC4575]
> consent-pending-additions package Gonzalo Camarillo [RFC5362]
> dialog package IETF SIPPING Working Group [RFC4235]
> kpml package Eric Burger [RFC4730]
> message-summary package Rohan Mahy [RFC3842]
> poc-settings package Miguel A. Garcia-Martin [RFC4354]
> presence package Jonathan Rosenberg [RFC3856]
> reg package Jonathan Rosenberg [RFC3680]
> refer package Robert Sparks [RFC3515]
> spirits-INDPs package Vijay K. Gurbani [RFC3910]
> spirits-user-prof package Vijay K. Gurbani [RFC3910]
> winfo template-package Jonathan Rosenberg [RFC3857]
> xcap-diff package IETF Real-time Applications
> [RFC-ietf-sip-xcapevent-08.txt]
> and Infrastructure Area
>
>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Thursday,
>> February 18, 2010 8:05 AM
>>>> ISSUE: The document details the notification body, and some inferences
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 18:43:57 -0500

> stateless as this CDIV package.

Sure it does. The state consists of zero or more buffered DTMF characters.

Depending on how you look at it, there may be separate state for each 
subscriber - which is populated with incoming dtmf characters - or else 
you can think of it as a single buffer with a separate starting point 
for each subscriber.

The state is essential for the handling of resubscribes that change the 
filter.

	Thanks,
	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 19 Feb 2010 16:29:49 -0800

> you can think of it as a single buffer with a separate starting point

Well, to me all the talk of buffering feels just as a way to make it 
appear state oriented when really these are just events. ISTM that the 
KPML model of buffers could be applied to *any* non-state based event 
package to make it comply with the 3265 requirement that there must be 
some actual state underneath. (I haven't read the KPML spec in years so 
admittedly the details escape me.)

Would you say entity tags are a good match for KPML?

The notion of different state per observer or different views of the 
same state also doesn't make sense to me. There's just one resource 
being observed so it doesn't seem right that two subscriptions should 
have different views of the resource's state.

> The state is essential for the handling of resubscribes that change the

Why can't a filter apply to events without there being any state (beyond 
event attributes)?

Thanks,
Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Feb 2010 10:05:15 -0500

Anders,

I think I will leave it to Adam, as the expert, to explain this.
I have found the state model the easiest way to conceptualize the 
behavior. I don't think there is any fundamental requirement that this 
force the unnecessary retention of state - its an abstract model rather 
than a concrete one.

In any case, for the draft at hand, I found that without such a 
description I can't fully understand the semantics of the package in a 
deterministic way.

Regarding kpml - it could have been described more clearly. I agree it 
suggests per-subscriber state, but as I noted earlier, it can also be 
understood in terms of common state. These views are functionally 
equivalent.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 22 Feb 2010 16:57:05 +0800

Hi all

Actually for the state information to be included, I can think of state
for a communication diversion notification information from either
subscriber point of view or from the notifier (server) point of view.

>From the subscriber point of view, the states could be whether the
subscriber is subscribed and if the notifications are being generated or
not. So here the state model would be

Subscribed->terminated

When in subscribed, the notifier can transition from idle to generate
notification and to send notification and finally to idle

Something like idle->generate->send->idle  OR idle->generate->idle
               
In IDLE state, the notifier waits for diversions to occur. Once a
diversion occurs, the notifier transitions to "GENERATE" state and looks
for any filter criteria. If it finds one and it matches, then it
generates the notification and transitions to "SEND" state. If there is
no filter criteria, then the notifier transitions back to "IDLE" state
and does not send any notification.
 
Comments?

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Saturday, February 20, 2010 8:35 PM
To: Anders Kristensen
Cc: [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review
ofdraft-avasarala-dispatch-comm-div-notification-03]

Anders,

	Thanks,
	Paul

>> subscriber - which is populated with incoming dtmf characters - or 
>> else you can think of it as a single buffer with a separate starting 
>> point for each subscriber.
> 

> some actual state underneath. (I haven't read the KPML spec in years 
> so admittedly the details escape me.)
> 
>> The state is essential for the handling of resubscribes that change 
>> the filter.
> 
> Why can't a filter apply to events without there being any state 
> (beyond event attributes)?
> 
> Thanks,
> Anders
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 19:29:29 -0500

> subscriber point of view or from the notifier (server) point of view.

I really think the state ought to be per subscribed resource (identified 
by the R-URI of the SUBSCRIBE when it reaches the notifier plus the 
event type.) The subscriber point of view really is a *view* of that. If 
it differs from one subscriber to another, then that really ought to be 
considered a filter, whether an explicit one supplied by the subscriber 
or an implicit one provided by the notifier based on policy.

> and does not send any notification.

I think you are not understanding the kind of state model we are talking 
about.

Think of the state as a collection of data that may change over time, 
that is visible to the notifier. When something in the state changes in 
that state, the notifier sends a NOTIFY to subscribers, saying "the 
state of the resource changed, here is the new value."

In the simplistic form, you could view that state as exactly the data 
needed to populate the body of your NOTIFY.

It gets a more complicated if there can be multiple subscribers, and you 
don't allow them all to see all of the data. (I'm not certain if you 
have restrictions like that or not.) If you do, then there might be data 
in the state that come subscribers get and others do not.

In your case, it appears from your xml, that your state consists of zero 
or more diversions. (Specifically it can be more than one.) And for each 
there an originating URI, a diverting URI, a diverted-to URI, a 
diverting time, and a diverting reason.

But the diverting-URI is redundant - its equivalent to the resource that 
is the target of the subscription, and so will be constant throughout 
the subscription. I don't understand why it is present. My suspicion is 
that you have in mind that the server will serve more than one diverting 
user and so the *server* state consists of info for each diverting user 
it serves. But unless you allow a subscription to address the *server* 
rather than a particular diverting user, this is invisible to the state 
of a given resource subscription target.

If I have that right, then this state changes over time as calls are 
diverted. In particular, a new diversion is added. Then, simplistically, 
each notify would contain not only the most recent diversion, but all 
the prior diversions as well.

Or you could define it so that older diversions are removed, using any 
of a variety of algorithms. E.g. you might keep the most recent N of 
them, or all that have occurred in the last N minutes. (E.g. you might 
keep only the single most recent one.) But that does imply that somebody 
subscribing *after* a diversion has occurred will get a notification 
immediately with whatever that state is - say the most recent diversion, 
even if that occurred a long time ago. (This could be a feature, but the 
implementation needs to support it by retaining the state.)

It starts to get messy if you don't want to retain the state. Then you 
must pretend that the new diversion was added to the (previously empty) 
state, caused notification(s), and then was immediately removed from the 
state. If viewed that way, the removal would also cause a notification. 
I suggested how that might be handled, but Adam thought it improper.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 23 Feb 2010 18:53:38 +0800

Hi Paul

My comments <Ranjit-Feb23> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 5:59 AM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

Avasarala Ranjit-A20990 wrote:
> Hi all
> 
> Actually for the state information to be included, I can think of 
> state for a communication diversion notification information from 
> either subscriber point of view or from the notifier (server) point of
view.

> subscriber is subscribed and if the notifications are being generated 
> or not. So here the state model would be
> 
> Subscribed->terminated
> 
> diversion occurs, the notifier transitions to "GENERATE" state and 
> looks for any filter criteria. If it finds one and it matches, then it

> generates the notification and transitions to "SEND" state. If there 
> is no filter criteria, then the notifier transitions back to "IDLE" 
> state and does not send any notification.

<Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when ever
a diversion occurs and the filter criteria matches. So there is no
resource as such whose value changes - except that notifier can maintain
the count of number of diversions that have occurred and how many times
the filter criteria matched and how many notifications were sent. So
every time a notification is sent, these values get incremented.

In the simplistic form, you could view that state as exactly the data
needed to populate the body of your NOTIFY.
<Ranjit-Feb23> Then the state needs to contain the caller details,
diversion time, reason for diversion and if filter criteria matched or
not.

It gets a more complicated if there can be multiple subscribers, and you
don't allow them all to see all of the data. (I'm not certain if you
have restrictions like that or not.) If you do, then there might be data
in the state that come subscribers get and others do not.
<Ranjit-Feb23> No need of such a thing because a particular subscriber
can only subscribe to his or her diversions and not others.

<Ranjit-Feb23> could be. 

<Ranjit-Feb23> Yes there is no need of diverting-URI. 

If I have that right, then this state changes over time as calls are
diverted. In particular, a new diversion is added. Then, simplistically,
each notify would contain not only the most recent diversion, but all
the prior diversions as well.
<Ranjit-Feb23> the set of previous diversions can be taken care of by
use of History-Info header. Each notification will contain information
about only one diversion which gets triggered when the diversion occurs.

<Ranjit-Feb23> ok.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2010 09:10:28 -0500

Inline. I've trimmed out irrelevant stuff

> every time a notification is sent, these values get incremented.

I'm trying to find another way to conceptualize your situation - one 
that works better with the 3265 way of describing events.

> can only subscribe to his or her diversions and not others.

OK. Then we won't worry about that.

> <Ranjit-Feb23> Yes there is no need of diverting-URI. 

OK. Then it could be removed from the notification body, and the filter 
too, because it is redundant. Right?

Its being there confuses people like me, who assume that if its there it 
must have a purpose.

> use of History-Info header.

You are thinking of something different than I am.
You are talking about previous diversions of the *same call*.
I'm talking about diversions of previous calls by the same diverting user.

IOW,
- at 2:00 a call from alice was diverted to bob.
- at 3:00 a call from carol was diverted to ted.
...

Its certainly possible to *imagine* such a state, gradually increasing 
with time as other calls are diverted.

> Each notification will contain information

So, if my phone has been *off*, when I turn it on I won't get a 
notification about a diversion that occurred while it was off? Is that a 
feature, or a limitation of the design?

If notifications of diversions are only delivered in realtime as they 
occur, then why do you bother to include the time of the diversion in 
the notification?

> I suggested how that might be handled, but Adam thought it improper.

The trick here is to find a way to model the state, and the implicit and 
explicit filters, to achieve the sort of results you want and permit the 
sort of implementation you want. There are no doubt several ways that 
may work.

I think what you need is something like:

- the state consists (abstractly) of x, y, z
- the state is adjusted in the following way when
   another call is diverted
- the manner of matching a particular component in a
   filter against the state is ...
- the manner of dealing with multiple components in
   a filter is ...
- the manner of populating the notification body from
   the state is ...

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 24 Feb 2010 00:43:05 +0800

Hi Paul.

Thanks for the comments. <Ranjit-Feb23-2> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 7:40 PM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

> I think you are not understanding the kind of state model we are 
> talking about.
> 
> that is visible to the notifier. When something in the state changes 
> in that state, the notifier sends a NOTIFY to subscribers, saying "the

> <Ranjit-Feb23> In case of CDIV, the notifier triggers a NOTIFY when 
> ever a diversion occurs and the filter criteria matches. So there is 
> no resource as such whose value changes - except that notifier can 
> maintain the count of number of diversions that have occurred and how 
> many times the filter criteria matched and how many notifications were

> sent. So every time a notification is sent, these values get
incremented.

> not.
> 
> It gets a more complicated if there can be multiple subscribers, and 
> you don't allow them all to see all of the data. (I'm not certain if 
> you have restrictions like that or not.) If you do, then there might 
> be data in the state that come subscribers get and others do not.

> In your case, it appears from your xml, that your state consists of 
> zero or more diversions. (Specifically it can be more than one.) And 
> for each there an originating URI, a diverting URI, a diverted-to URI,

> a diverting time, and a diverting reason.
> <Ranjit-Feb23> could be. 
> 
> But the diverting-URI is redundant - its equivalent to the resource 
> that is the target of the subscription, and so will be constant 
> throughout the subscription. I don't understand why it is present. My 
> suspicion is that you have in mind that the server will serve more 
> than one diverting user and so the *server* state consists of info for

> each diverting user it serves. But unless you allow a subscription to 
> address the *server* rather than a particular diverting user, this is 
> invisible to the state of a given resource subscription target.

> diverted. In particular, a new diversion is added. Then, 
> simplistically, each notify would contain not only the most recent 
> diversion, but all the prior diversions as well.

You are thinking of something different than I am.
You are talking about previous diversions of the *same call*.
I'm talking about diversions of previous calls by the same diverting
user.

IOW,
- at 2:00 a call from alice was diverted to bob.
- at 3:00 a call from carol was diverted to ted.
...
<Ranjit-Feb23-2> Ok here as you said, the notification always contains
the most recent and latest diversion that occurred and the one that
matched the subscriber's filter criteria. 

> Each notification will contain information about only one diversion 
> which gets triggered when the diversion occurs.

So, if my phone has been *off*, when I turn it on I won't get a
notification about a diversion that occurred while it was off? Is that a
feature, or a limitation of the design?
<Ranjit-Feb23-2> The notifications are temporarily stored in the server
when the phone is *off* and they would be sent one by one when the phone
is *on*. So yes it's a feature in the server to monitor phone's status
and store the notifications if required - the amount of storage could
depend on server policy and some may or may not. No hard rule that they
should. If they do not store, then only the latest notification would be
sent.

If notifications of diversions are only delivered in realtime as they
occur, then why do you bother to include the time of the diversion in
the notification?
<Ranjit-Feb23-2> true. This makes sense only when notifications are
stored and sent later (phone off scenario)

> keep only the single most recent one.) But that does imply that 
> somebody subscribing *after* a diversion has occurred will get a 
> notification immediately with whatever that state is - say the most 
> recent diversion, even if that occurred a long time ago. (This could 
> be a feature, but the implementation needs to support it by retaining 
> the state.)
> 

> must pretend that the new diversion was added to the (previously 
> empty) state, caused notification(s), and then was immediately removed

> from the state. If viewed that way, the removal would also cause a
notification.

<Ranjit-Feb23-2> need to think further on this.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2010 13:48:06 -0500

> matched the subscriber's filter criteria. 

Except for what you say below

> should. If they do not store, then only the latest notification would be

See, you really *do* have state!!!

IIUC, you are saying that the server might store history of multiple 
diversions, or just the most recent one, or none.

> stored and sent later (phone off scenario)

When you say "phone off", I presume you mean "phone not subscribed to 
this event package". Is that right?

What do you do about multiple phones (extensions) on the same AOR? E.g. 
one at the office and another at home. Consider that case, and that I 
have been out of the office for some time, and arrive home without 
visiting the office. My home phone has been off, but the office phone 
has been on the whole time. Will I see the diversions that have occurred 
while I was out?

If you clear the state as soon as you send one notification with it, 
then when I get home I will see no diversions.

It would all be much cleaner if you kept the most recent N diversions in 
the server, where N>=1. When a new one comes in, if that makes N+1, then 
discard the oldest, and *then* send the notification to whoever is 
subscribed. If somebody else subscribes later, send what you have.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Feb 2010 09:40:13 +0100

I appreciate Paul's efforts to try to sort this out, but it seems to me that we are having to go to great lengths to make this fit the RFC 3265 model. Perhaps HTTP would be a better way of getting call log information, including not only diverted calls but also, say, missed calls that were not diverted (e.g., when no UA registered and no diversion conditions apply). Parameters in the GET request could filter for particular types (e.g., diverted calls only) and indicate how far to go back in history. For the UA to become aware that a state change has occurred, the event package in draft-roach-http-subscribe could be used.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 23 February 2010 18:48
> Subject: Re: [dispatch] [Fwd: Re: Preliminary version 
> ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03]
> 
> 
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 25 Feb 2010 12:56:41 +0800

Hi Paul

My comments <Ranjit-Feb25> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2010 12:18 AM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

> OK. Then we won't worry about that.
<Ranjit-Feb25> Yes

> OK. Then it could be removed from the notification body, and the 
> filter too, because it is redundant. Right?
<Ranjit-Feb25> yes we do not need diverting-URI in the notification
body.
> 
> Its being there confuses people like me, who assume that if its there 
> it must have a purpose.
> 

> notification about a diversion that occurred while it was off? Is that

> a feature, or a limitation of the design?
> <Ranjit-Feb23-2> The notifications are temporarily stored in the 
> server when the phone is *off* and they would be sent one by one when 
> the phone is *on*. So yes it's a feature in the server to monitor 
> phone's status and store the notifications if required - the amount of

> storage could depend on server policy and some may or may not. No hard

> rule that they should. If they do not store, then only the latest 
> notification would be sent.

When you say "phone off", I presume you mean "phone not subscribed to
this event package". Is that right?
<Ranjit-Feb25> True. This is ths phone state - being ON or OFF i.e
registered with the network or not and then if it
Is subscribed to CDIVN service or not. 

<Ranjit-Feb25> Here it depends on the target of the call. i.e if the
call was targetted for your home phone and it was off, and there was a
rule that
Diverts all incoming calls to home be diverted, then you would get a
notification. 

If you clear the state as soon as you send one notification with it,
then when I get home I will see no diversions.
<Ranjit-Feb25> True. Once a notification about a particular diversion is
sent, then the server's state is back to idle as if no diversions have
occurred and nothing to do. 

It would all be much cleaner if you kept the most recent N diversions in
the server, where N>=1. When a new one comes in, if that makes N+1, then
discard the oldest, and *then* send the notification to whoever is
subscribed. If somebody else subscribes later, send what you have.
<Ranjit-Feb25> This actually depends on how many diversions u want to
store, server storage per subscriber - subscription types like silver.
Gold where gold subscriber gets higher storage than silver subscriber

	Thanks,
	Paul

> The trick here is to find a way to model the state, and the implicit 
> and explicit filters, to achieve the sort of results you want and 
> permit the sort of implementation you want. There are no doubt several

> ways that may work.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 16:07:58 -0500

>> Its being there confuses people like me, who assume that if its there 

If you want to leave it there, even though its redundant, the main issue 
is making it *clear* that it is redundant and will always match the 
subscribed-to URI.

The big problem is the potential that it might differ, and what it would 
mean if it did.

> Is subscribed to CDIVN service or not. 

Well, in IMS I guess if you aren't registered you can't be subscribed.
But presumably you can be registered and not subscribed. Its the 
subscription that is the gating factor here, right?

> Diverts all incoming calls to home be diverted, then you would get a

I don't quite understand, and think it may be significant.
I was talking about two phones registered to the same URI. E.g. AOR 
sip:[email-masked] with two contacts: 
sip:[email-masked] and sip:[email-masked].

Hence both phones would be subscribing to the CDIV service at 
sip:[email-masked].

In that arrangement a caller can't (easily, without callerprefs or 
gruus) target a call to the home or the office. Rather the calls just 
ring both places. And then diversion rules will apply to calls to that 
AOR in general, so that both phones need to know about the diversion so 
that alice will know about it regardless of where she is.

But I think you are talking about some other arrangement, with multiple 
AORs that have some relationship to one another here, that isn't clear 
to me from the text. If that is so, can you explain?

> Gold where gold subscriber gets higher storage than silver subscriber

In the above I was assuming that the value of N is configurable. A given 
AOR has some value. (Or maybe the whole CDIV service has a common 
value.) And maybe its enough for that value to always be one.

The problem case is where the value of N is zero.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 26 Feb 2010 13:35:27 +0800

Hi Paul

My comments <Ranjit-Feb26>

[1] diverting-URI: I plan to remove this field from the list of elements
that can be part of the notification body and filter criteria. 

[2] phone-off and not subscribed-to: Here I mean, phone is off implies
the subscriber is not registered to the IMS network at that moment. But
the
   subcription could still be valid. So when the subscriber's phone is
switched off, the notifier will not be able to send the notification to
the
   subscriber and could store the notifications until the subscriber
re-registers with the IMS network. The number of notifications that the
   notifier would store would be policy dependent. 

   But if the subscriber is registered and not subscribed, then there is
no way the notifier can send any notifications. A case of no
subscription.

[3] in the example u suggested where sip:[email-masked] with two
contacts: sip:[email-masked] and
sip:[email-masked] and
    both the phones ring, then it would be a case of parallel forking.
Now say one or both the phones have set diversion rules, to divert the
call to say 
    sip:[email-masked], then the notifications would get
generated with respect to both the contacts.

[4] Yes the value of N is configurable and depends on how many
diversions the subscribe wants to keep or could be dependent on server
policy (some maximum
    number). If the server policy is to send notifications as and when
they occur and not keep any divsersions information, then the value of
last N 
    diversions will be zero. But if the server chooses to retain the
last diversion always, then the value of N will be 1 and so on.

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 26, 2010 2:38 AM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

Avasarala Ranjit-A20990 wrote:

>>> than one diverting user and so the *server* state consists of info 
>>> for each diverting user it serves. But unless you allow a 
>>> subscription to address the *server* rather than a particular 
>>> diverting user, this is
> 

<Ranjit-Feb26> [1]

> registered with the network or not and then if it Is subscribed to 
> CDIVN service or not.

<Ranjit-Feb26> [2]

> has been on the whole time. Will I see the diversions that have 
> occurred while I was out?
> 

> rule that Diverts all incoming calls to home be diverted, then you 
> would get a notification.

<Ranjit-Feb26> [3]

> <Ranjit-Feb25> True. Once a notification about a particular diversion 
> is sent, then the server's state is back to idle as if no diversions 
> have occurred and nothing to do.
> 
> It would all be much cleaner if you kept the most recent N diversions 
> in the server, where N>=1. When a new one comes in, if that makes N+1,

> then discard the oldest, and *then* send the notification to whoever 
> is subscribed. If somebody else subscribes later, send what you have.

<Ranjit-Feb26> [4]

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2010 09:36:41 -0500

> that can be part of the notification body and filter criteria. 

OK.

> no way the notifier can send any notifications. A case of no

I'm still a little confused here.
If phone is on and subscription is active, then in general notification 
should be possible, regardless of registration. I realize IMS doesn't 
permit that, but from a general standard perspective we shouldn't assume 
it. The manifestation in this case is that the NOTIFY would fail and the 
subscription would eventually be torn down.

So I think the cases are:
- there is a subscription and notification works
- there is a subscription but notification fails
- there is no subscription.

> Now say one or both the phones have set diversion rules, to divert the

In this case, what does it mean for "one or both phones have set 
diversion rules"? Does that somehow imply distinct rules for each phone? 
I don't see how that could work. Aren't the diversion rules for the *AOR*?

I see they could be set/changed from either phone. But its a single set 
of rules isn't it? So I might set the rules from the office, and then 
cancel them from home.

> generated with respect to both the contacts.

Again I'm confused by the terminology you use, and how it relates 
operationally. The diversion happens on the AOR, and the subscriptions 
are on the AOR, and the notifications are sent to the subscribers. I 
don't see where the registered contacts enter into the picture at all.

If you have something else in mind, I hope you can explain it better in 
the draft.

> last diversion always, then the value of N will be 1 and so on.

All is straightforward for N>=1.

For N=0 things are messy. If we are modeling this as state, and 
notifications are about state changes, then the new diversion is added 
to the (previously empty) state and that triggers notifications to all 
current subscriptions. Then if you don't want to retain even this much 
state (because N=0) you immediately remove that version from the state. 
But that is again a state change, so you end up with another 
notification of that state change.

I presume you don't want that behavior. If you can live with N>=1 then 
we don't have the problem at all. If you need to support N=0 and don't 
want the extra notify, then we have to figure out if there is some trick 
to how things are modeled to get the desired effect. I've suggested 
something previously, but Adam didn't like it.

This needs sorting out.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Sat, 27 Feb 2010 00:03:31 +0800

Hi Paul

Comments <Ranjit-Feb26-2> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 26, 2010 8:07 PM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

Avasarala Ranjit-A20990 wrote:
> [1] diverting-URI: I plan to remove this field from the list of 
> elements that can be part of the notification body and filter
criteria.

OK.
<Ranjit-Feb26-2> OK

> the subscriber is not registered to the IMS network at that moment. 
> But the

> switched off, the notifier will not be able to send the notification 
> to the
>    But if the subscriber is registered and not subscribed, then there 
> is no way the notifier can send any notifications. A case of no 
> subscription.

<Ranjit-Feb26-2> Agreed. Actually instead of calling it as Notification
fails, we can say - not sending notification due to (1) no match of
filter criteria (2) phone not registered or outside coverage area due to
which there is no connectivity and hence notification cannot be sent 
Anyway if no subscription, no notification. 

I don't see how that could work. Aren't the diversion rules for the
*AOR*?

<Ranjit-Feb26-2> Yes the diversion rules are for AoR. So when there is a
diversion rule set for the AoR and when diversions occur, the
notifications are
Sent to the AoR.

<Ranjit-Feb26-2> yes single set and could be set from either of the
phones. True.

<Ranjit-Feb26-2> Ya agree with you on this. Sorry for the confusion.

<Ranjit-Feb26-2> True. Actually the notifications are for informing the
subscriber of the call diversions that happen. The notifications are not
for informing the subscriber of state changes in the notifier or the
number of diversions that occurred. As I mentioned in the abstract as
well as 24.604, the main intent of CDIVN service is to inform the
subscribers of communication diversions that occur on their behalf in
the network and this information will help them manage their rules
better. 

<Ranjit-Feb26-2> But if we want to include the information related to
how many diversions have happened till time (say from 12 AM ) till the
time the notification is being sent, then as you say we can store the
diversions. This would be useful when the subscriber specifies in the
filter criteria to send notifications only during certain time like
between 5 and 6 PM and not whenever a diversion occurs. Then N is grater
than 1.

This needs sorting out.

	Thanks,
	Paul

>>>> diverting user, this is invisible to the state of a given resource 
>>>> subscription target.
> If you want to leave it there, even though its redundant, the main 
> issue is making it *clear* that it is redundant and will always match 
> the subscribed-to URI.
> 
> The big problem is the potential that it might differ, and what it 
> would mean if it did.
> <Ranjit-Feb26> [1]
> 

> AOR in general, so that both phones need to know about the diversion 
> so that alice will know about it regardless of where she is.
> 
> But I think you are talking about some other arrangement, with 
> multiple AORs that have some relationship to one another here, that 
> isn't clear to me from the text. If that is so, can you explain?
> 
> <Ranjit-Feb26> [3]
> 

> In the above I was assuming that the value of N is configurable. A 
> given AOR has some value. (Or maybe the whole CDIV service has a 
> common