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:34 -0500

-------- Original Message --------
Subject: Re: [dispatch] Preliminary version of Expert review 
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: Thu, 18 Feb 2010 15:37:44 -0600
From: Adam Roach <[email-masked]>
To: Paul Kyzivat <[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]>

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.

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