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:20:04 -0500

-------- Original Message --------
Subject: Re: [dispatch] Preliminary version of Expert review 
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: Fri, 19 Feb 2010 08:20:28 -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]> 
<[email-masked]> <[email-masked]> 
<[email-masked]>

On 2/19/10 03:59, Feb 19, Avasarala Ranjit-A20990 wrote:
> 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?
>    

I don't think so. See my other notes on the topic.

/a