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:19:50 -0500

-------- Original Message --------
Subject: RE: [dispatch] Preliminary version of Expert review 
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: Fri, 19 Feb 2010 17:59:05 +0800
From: Avasarala Ranjit-A20990 <[email-masked]>
To: Paul Kyzivat <[email-masked]>, Adam Roach <[email-masked]>
CC: John-Luc Bakker <[email-masked]>
References: <[email-masked]> 
<[email-masked]><[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> <[email-masked]>

Hi Paul

In case of IMS, the diverting system would be the Application Server
(AS) that is hosting the CDIVN service. Now if we need the concept of
state, then we need to monitor the state of the AS or the CDIVN service.

So true as you say, we prefer the notification server to be "Stateless"
and hence it would start with "idle" state before sending a notification
information and will transition to "send" state and immediately back to
"idle" state waiting for another diversion to occur. Now when another
diversion occurs, if the notification server needs to send a
notification (depending on filter criteria), then it will transition to
"send" state to send the notification, else it will remain in "idle"
state.

True simultaneous diversions will be serialized and the server needs to
switch back and forth between states to send multiple notifications i.e
idle->send->idle.

Is this ok?

Thanks

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, February 19, 2010 3:00 AM
To: Adam Roach
Cc: Avasarala Ranjit-A20990; John-Luc Bakker
Subject: Re: [dispatch] Preliminary version of Expert review
ofdraft-avasarala-dispatch-comm-div-notification-03

Thanks Adam.

Ranjit - I was thinking that minimally your state could be described as:

1) the incoming sip message to the diverting system
2) the resultant outgoing sip message from the diverting system

Before the first diversion the state would be nil.

After the first diversion, and the resulting notifications, there is a
question whether you retain that state. Its conceptually simpler if you
do. But if you want your server to be "stateless" in this regard, then
maybe you have to think about it immediately transitioning back to nil
state, before another diversion can occur.

As I noted in my prior message, that amounts to another state change,
and hence calls for another set of notifications, unless they are
suppressed by a filter of some sort.

Another issue is what happens with "simultaneous" diversions? Are you
expecting them to be serialized, resulting in distinct back-to-back
notifications? Or in that case do you want a single notification with
both diversions? If you want that, then the "state" needs to
simultaneously include both.

	Thanks,
	Paul

Adam Roach wrote:
> 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
>>   
>