RE: [XCON] CPCP Requirement: Repeat times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [XCON] CPCP Requirement: Repeat times
For that matter, is there a use case for end points (XCON) doing such complicated scheduling? Why don't we just take the bridge out of service?
Wow! Agreeing with Roni twice in one day!!!
> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il]
> Sent: Wednesday, January 07, 2004 4:56 AM
> To: 'hisham.khartabil@nokia.com'; Even, Roni;
> petri.koskelainen@nokia.com; xcon@ietf.org
> Subject: RE: [XCON] CPCP Requirement: Repeat times
>
>
> Hisham,
>
> The conference server is not mentioned in
> draft-ietf-sipping-conferencing-framework-01. The framework
> mentioned the
> conference policy server. As for reservation my view is that
> reservation is
> starting an ad-hoc conference when the schedule time has
> arrived and it
> should not be part of the conference policy. Reservation is a separate
> application from the conference policy. I suggest that if you want to
> address it then we should have a separate element in the
> frame work which
> will be a reservation server.
>
> Roni
>
> *************************************
> Roni Even
>
> Polycom Israel
>
> Tel: +972-3-9251200
> Cell: +972-55-481099
> email:roni.even@polycom.co.il
> *******************************************
>
>
> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Wednesday, January 07, 2004 11:22 AM
> To: roni.even@polycom.co.il; petri.koskelainen@nokia.com;
> xcon@ietf.org
> Subject: RE: [XCON] CPCP Requirement: Repeat times
>
>
> No, the focus host (conference server) is the one that handles the
> reservations. The focus is only created and destroyed by the
> conference
> server according to the start and stop times.
>
> /Hisham
>
> > -----Original Message-----
> > From: ext Even, Roni [mailto:roni.even@polycom.co.il]
> > Sent: 06.January.2004 19:06
> > To: Koskelainen Petri (Nokia-NRC/Tampere); Even, Roni;
> > Khartabil Hisham
> > (Nokia-TP/Helsinki); 'xcon@ietf.org '
> > Subject: RE: [XCON] CPCP Requirement: Repeat times
> >
> >
> > Hi Petri,
> > The CPS is a data storage that is used by the focus, so the
> > focus will have
> > to handle the reservation
> > Roni
> >
> > -----Original Message-----
> > From: petri.koskelainen@nokia.com
> > To: roni.even@polycom.co.il; hisham.khartabil@nokia.com;
> xcon@ietf.org
> > Sent: 06/01/2004 18:50
> > Subject: RE: [XCON] CPCP Requirement: Repeat times
> >
> > Hi Roni,
> >
> > > My opinion is that the conference policy needs only a
> > > conference duration parameter if any.
> > > I think that reservation is an external
> > > application to the focus. According to the conference
> > > framework the focus is using the information in the
> > > conference policy server and the focus is
> > > not the right place for reservation.
> >
> > The reservation is sent to CPS, not to focus.
> > I think it makes sense to have this (repeat time) capability
> > in protocol
> > since we need the feature anyway in real-world (either in CPCP
> > or in some new mystery protocol between the user and the reservation
> > application).
> >
> >
> >
> > --
> > Petri
> >
> >
> > > Regards
> > > Roni Even
> > >
> > > -----Original Message-----
> > > From: hisham.khartabil@nokia.com
[mailto:hisham.khartabil@nokia.com]
> > Sent: Monday, December 15, 2003 4:57 PM
> > To: xcon@ietf.org
> > Subject: [XCON] CPCP Requirement: Repeat times
> >
> >
> > A conference has start and stop times. Although the current proposed
> > solution has repeat times (eg: meeting repeats weekly), there is no
> > requirement for such.
> >
> > Do we see a need for such capability using CPCP? If so, then
> > we need to add
> > a requirement.
>
_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.