Re: [XCON] draft-ietf-xcon-common-data-model

["Duddy, Sean (Sean)" <duddy at avaya.com>]

Hi Oscar,

   Thanks for your reply. I am concerned that some key conferencing data items are missing from the model and instead addressed via extensions.

Specifically I am talking about:-

 

1. <conference-password.>

    This is a one-one mapping with the conference URI. Based on the IETF 68 minutes Re:policies, why is this field still there?

Basically every conference needs at least two passwords - one for particpants  & one or more for moderators.

If these fields are going to be provided via some policy schema, then I think that needs to be somehow described so there is a common definition...

2. Demand conferences

   On Demand conferences are an industry wide recognised type of conference and therefore should be part of the model.

3. The pool/lines pool is not specific to PSTN. It is applicable to VOIP also and not the same as <maximun-user-count>.

Basically they are used to divide up conferencing capacity. e.g. scheduled conferences would typically use one pool and

demand another in order to guarantee resources for the scheduled ones...

 

On the recurring conference, the model doesnt seem to allow modfication of a particular instance in a recurrence pattern.

e.g. I have a weekly recurring conference, on a Friday. However next Friday, the meeting needs to be moved forward by an hour.

How can this be achieved via the model? It would be essential to be able to view/modify individual instances of a conference.

 

Sean

---

From: Oscar Novo [mailto:oscar.novo at ericsson.com]
Sent: Wed 02/07/2008 12:25
To: Duddy, Sean (Sean); xcon at ietf.org
Subject: RE: [XCON] draft-ietf-xcon-common-data-model

Sean,

 

The controls defined in the data model are really basic ones as we agreed in the WG. The controls you suggested in your e-mail can be added to the document in future extensions. Note that the data model is not specific to one protocol (e.g. PSTN, SIP), that's why many times the data model uses general naming in order to fullfil the requirements of all the protocols.

 

Regarding your comment number 4, the <participant-passcode> and <administrator-passcode> elements were defined in previous versions of the document. However, the WG decided (check the minutes from IETF 68) to leave out the common policy from the data model. The element <conference-password> is used to specify the PIN code of the conference. So, your comment number 5 is fullfil with this element. Concerning your comment number 6, the data model does define a outbound dial list, check the <allowed-users-list> element and its 'method 'attribute. 

 

Answering your general questions briefly:

 

Number 1: The definition of on-demand conference in the data model it depends pretty much from the implementor. One option it would be not to defined the DTSTART and the DTEND in the <base> element.

Number 2: The pool/lines pool is quiet specific to PSTN. The data model defines the <maximum-user-count> element that it could be used for the same purpose. Extension to this element can be done later.

Number 3: The information for recurring conference can be defined in the <base> element. I suggested you to check RFC 2445. For instance, the example defined in the data model is a recurring conference. Check the example below:

 PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
 VERSION:2.0
 BEGIN:VEVENT
 DTSTAMP:20071003T140728Z
 UID:20071003T140728Z-345FDA-carol at example.com
 ORGANIZER:MAILTO:carol at example.com
 DTSTART:20071017T143000Z
 RRULE:FREQ=WEEKLY
 DTEND:20071217T163000Z

 END:VEVENT
 END:VCALENDAR

 

Cheers,

 

Oscar

---

From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of Duddy, Sean (Sean)
Sent: 30. kesäkuuta 2008 13:17
To: xcon at ietf.org
Subject: [XCON] draft-ietf-xcon-common-data-model

Hi,

    Some comments on the content of this data model re: audio conferencing

(I know these could be accomodated using extensions but maybe they should be part of the standard model as they do seem central to any conferencing solution)

 

1. Conference recording is missing. Need attribute(s) to indicate if recording is allowed and how it is triggered (automatic or manual)

2. Conference playback is missing. Need attribute to indicate if playback is allowed.

3. Music source selection is missing. Need to be able to set the music source to be played to particpants

waiting to get into the conference.

4. Moderator and conferee passcode. I think the model calls this the <conference-password>, but there needs

to be two, one for moderator and one for conferee. Also as these are DTMF digits, I think the term 'passcode'

is more appropriate than 'password'.

5. Apart from the access control lists, the model seems to be lacking in security, specifically there needs to be a

method to specify PIN codes associated with a conference i.e. user needs to enter this PIN to gain entry to conference

6. Outbound dial list is missing. Need to be able to configure URIs that the moderator/operator can dial out to when conference opens.

Also need to configure how the people on the list get dialled e.g. manually by operator or automatic when moderator joins.

Need to configure what message gets played to them initially also.

7. Entry/Exit tone configuration is missing. Need to be able to specify what should get played when particpants enter/leave

e.g. tone,message,tone&message,none 

 

General questions:

1. How would on-demand conferences be modelled? (Demand conferences are conferences that people can dial into any time i.e. there would be no scheduling information).

2. There is no mention of port/line pools. e.g. scheduled conferences would typically use ports from a reserved pool so one is guaranteed to get into the conference

at conference start time. I think there should be an attribute to specify what pool to use - reserved,unreserved,other.

3. For recurring conferences, where does the original recurrence info get stored? i.e. there is a <conference-time> entry for each recurrence which I assume

will have the start/end timing info for that particular recurrence, but where does the original pattern get stored and how does the model maintain the releationship

between the conferences that make up the pattern? This relationship would be handy to apply a modification to all conferences that make up a recurrence pattern.

 

Sean

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon