Subject: RE: AW: [Sipping] Comments on draft-poetzl-sipping-call-completio n-00.txt

From: "Elwell, John" <[email-masked]>
Date: Sun, 09 Jul 2006 17:27:02 +0100

Gonzalo,

Another example of an event package that is not "standard" use is
policy-package, where the subscription submits a session description and the
notification returns the policy for that session description. Not quite the
same as the proposed call completion use, admittedly, but it illustrates the
richness of applications to which the SIP event framework can be applied. I
think the proposed call completion use is legitimate.

John 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 07 July 2006 08:41
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: Jesske, R; [email-masked]; Poetzl, Joachim
> Subject: Re: AW: [Sipping] Comments on 
> draft-poetzl-sipping-call-completion-00.txt
> 
> Hi,
> 
> this service needs to have clients introduce and remove entries on a 
> FIFO queue, right? Now, what mechanism do you propose to 
> perform those 
> introductions and removals? The draft seems to propose to use 
> the event 
> package for that.
> 
> Cheers,
> 
> Gonzalo
> 
> GARCIN Sebastien RD-CORE-ISS wrote:
> > Hi Gonzallo,
> > 
> > "..., but you are effectively extending an event package to 
> perform floor control (or FIFO queue management if you prefer 
> to call it like that), and that should be discussed, because 
> it is not the typical behavior of an event package."
> > 
> > The FIFO management is part of the ccbs/ccnr service logic 
> which is not really in the scope of this I-D since IETF does 
> not define service logic. However this service logic relies 
> on a notification mechanism provided by SUB/NOT. As far as I 
> can see, the event packages that have been defined up to now 
> are each unique, and have in common to require a notification 
> mechanism which is controlled by some logic behind that 
> depends on the functionality of the package (e.g. presence 
> logic, message-summary logic...). 
> > 
> > Regards,
> > sébastien 
> > 
> > -----Message d'origine-----
> > De : Gonzalo Camarillo [mailto:[email-masked]] 
> > Envoyé : vendredi 7 juillet 2006 08:33
> > À : Alexeitsev, D
> > Cc : Jesske, R; Poetzl,Joachim; [email-masked]
> > Objet : Re: AW: [Sipping] Comments on 
> draft-poetzl-sipping-call-completion-00.txt
> > 
> > Hi,
> > 
> >> The required functionality is not to manage the access to 
> a specific 
> >> resource, but to manage the processing of the 
> notifications for change 
> >> in the state of a resource.
> > 
> > yes, event packages deal with notifications.
> > 
> >> In the regular case multiple subscribers to the same 
> resource will get 
> >> the notification about the change of the resource state 
> >> simultaneously. This behaviour is required for some 
> applications, but 
> >> not wanted for the ccbs/ccnr service. In order to cope 
> with it, the 
> >> regular notification procedures are extended with the FIFO 
> management 
> >> policy that is initiated during dialog establishment.
> > 
> > The FIFO management you are talking about here consist of 
> managing the "access to a specific resource", statement that 
> you do not agree with in the paragraph at the top of this 
> email. You propose a FIFO queue in order to decide who gets 
> access to the resource (i.e., being able to talk to the user).
> > 
> >> That is in our opinion an event package internal 
> extension, that does 
> >> not required any external interfaces.
> > 
> > It does not require external interfaces, but you are 
> effectively extending an event package to perform floor 
> control (or FIFO queue management if you prefer to call it 
> like that), and that should be discussed, because it is not 
> the typical behavior of an event package.
> > 
> > My opinion is that this type of management should be 
> outside the scope of an event package.
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 10 Jul 2006 20:51:14 +0300

Hi,

yes, I am very familiar with the session policy draft. Actually, one of 
its open issues is exactly this: whether to use SUBSCRIBE or PUBLISH to 
send stuff the policy server. We need to discuss whether or not these 
usages of an event package are OK.

Cheers,

Gonzalo