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:18:53 -0500

-------- Original Message --------
Subject: Re: [dispatch] Preliminary version of Expert review 
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: Thu, 18 Feb 2010 16:58:51 -0500
From: Paul Kyzivat <[email-masked]>
To: Adam Roach <[email-masked]>
CC: Avasarala Ranjit-A20990 <[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]> 
<[email-masked]> <[email-masked]> 
<[email-masked]>

Adam Roach wrote:
> Another way to examine this problem might be to consider the state as 
> being composed of the list of diverted callers. You can age entries out, 
> and reset the list when diversion is shut off. Doing this makes it much 
> clearer what should happen for the near-simultaneous case.
> 
> Note that this is conceptually similar to what the winfo event package 
> template does with its "waiting" state.

I'm just inferring from what Ranjit has said that they envision a server
that doesn't keep *any* state about diverted calls. I'm trying to see if
this can be so and still conform to the 3265 view of the world.

Do you think its a valid approach to have state instantaneously appear
and disappear, and for a filter to block the delivery of the transitions
back to nil state?

	Thanks,
	Paul

> /a
> 
> On 2/18/10 15:30, Feb 18, Paul Kyzivat wrote:
>> 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
>>>
> 
>