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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 7 Jul 2006 11:21:19 +0200

Yes, the SUB method is used for requesting ccbs/ccnr queue operations because it enables to create call unrelated state and that these operations influence the notification behavior. This seems pragmatic to me.

Regards,
sébastien

-----Message d'origine-----
De : Gonzalo Camarillo [mailto:[email-masked]] 
Envoyé : vendredi 7 juillet 2006 09:41
À : GARCIN Sebastien RD-CORE-ISS
Cc : Alexeitsev, D; Jesske, R; Poetzl,Joachim; [email-masked]
Objet : 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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 7 Jul 2006 14:30:50 -0400

Gonzalo,

I don't think it was modeled exactly this way, but a queue is a
resource.  The state of the queue is the ordered list of users waiting
in the queue, along with their active/suspend status.  An event
mechanisms could report the state of that queue filtered to each
requestor.  (Each sees the status of his position in the queue.)  Upon
getting notification that one is at the front of the queue, one
initiates a call to the formerly busy party.  One could be accepted,
suspended, resumed, rejected or leave the queue based on how the
Subscribe is handled.

One could theoretically model a conference this way too.  Member monitor
the status of the conference bridge, the bridge monitors the status of
the members.  Bridge and members take action based on the status
visible.  But, that is another matter.

I think your main complaint is not that an Event packages is used, but
how it is used.  The current draft seems to just embed signaling into
Event parameters leading you to think that a new method is better.  I
think a little work on the model and the text would correct that.

BTW, a picture with multiple callers and a call flow that intermingles
INVITEs with SUBSCRIBES and NOTIFYs along with the message annotation of
SUB/NOT would help increase the understanding of the state changes, e.g.
busy/no q -> 
busy/1 active -> 
busy/2 active -> 
busy/3 active ->
busy/2 active/1 suspended ->
free/2 active/1 suspended -> 
busy/1 active/1 suspended -> 
busy/2 active -> 
etc.

Mike

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 2:36 AM
> To: Dolly, Martin C, ALABS
> Cc: Jesske, R; sipping; [email-masked]; 
> [email-masked]
> Subject: Re: [Sipping] Comments on 
> draft-poetzl-sipping-call-completion-00.txt
> 
> Hi Martin,
> 
> note that I am not proposing to use a floor control protocol 
> for conferences for this application. I was providing an 
> example to clarify what these event packages are trying to do 
> beyond notifying changes in the state of a resource.
> 
> Yes, I agree. Having a good solution in a timely fashion 
> should be our priority. That's why I have initiated 
> discussions on this topic.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
> Dolly, Martin C, ALABS wrote:
> > Gonzalo,
> > 
> > Your conferencing example seems to be an over kill to me, and that 
> > path would seem to be a timely one to me.
> > 
> > Cheers, Martin
> > 
> > -----Original Message----- From: Gonzalo Camarillo 
> > [mailto:[email-masked]] Sent: Thursday, 
> July 06, 2006 
> > 9:20 AM To: [email-masked]; [email-masked]; 
> > Jesske, R Cc: sipping Subject: [Sipping] Comments on 
> > draft-poetzl-sipping-call-completion-00.txt
> > 
> > Hi,
> > 
> > this draft defines a couple of SIP event packages and uses them to 
> > perform queue management. Event packages are typically used 
> to obtain  
> > information about the state of a resource. However, this 
> draft seems 
> > to be using them in order to perform a set of operations on that 
> > resource.
> > 
> > It may not be a good design choice to embed those operations in the 
> > event package. A more explicit method may be a better option. For 
> > example, in a conference, when several user agents want to 
> gain access 
> > to a resource (the right to speak), they implement a floor control 
> > protocol (which is not SIP).
> > 
> > In any case, as noted by other reviewers, the draft should 
> try and do 
> > a better job explaining the proposed mechanism. A couple of more 
> > detailed examples would be beneficial.
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > _______________________________________________ Sipping 
> mailing list 
> > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW 
> > development of the application of SIP Use 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>