All,
Here are our consolidated comments while wearing our
"Avaya" hats.
pg13, Figure 3 & pg 14, S4.2
*
Where do generic / proprietary conference attributes fit in e.g.
pin-list, recording, billing, call flow type , biometric , data, video ,
annunicator msgs?
pg14, S4.2.1
* this assumes only a specific
language is available, what about country variants and fallback e.g. en,
en_gb
pg 15, S4.2.6
* Does this imply a default of
false if not specified ? What about size of sidebars, number of
sidebars
pg 15, S4.2.7
* Does their need to be
anything about demand / scheduled / adhoc
(tui)
* Mandate all date times in
UTC. It's up to a client application to convert to / from local time as
appropriate. How to handle timezones and variation in dst rules or is this a
problem for the OS and main userspace runtime
library?
* Should there be a way of
linking via a uri to the ical object the base element under
conference-time\entry.
* I'm not familiar enough with
ical rfc, but can it specify perpetual conferences, recurring series with odd
exceptions ? Tz / dst changes that are outside normal rules due to political
changes.
* required-participant
attribute under mixing-start-offset has no apparent definitions of the various
roles
* can-join-after-offset
doesn't mention DTSTART and signed integer
*
allowed-extend-mixing-end-offset has no apparent limits on size, duration
, number of extension periods
* Would there be a requirement
for accessing current time and tz on server. How would one handle a distributed
/ dispersed server deployment?
* In the Schema, the *-offset elements are
dates, while in this section they are described as integer
offsets
pg 16, S4.2.8
* Must be able to repesent multiple access numbers to same
logical conference e.g. international, toll free, local access for PSTN users.
Howto represent a conference which spans multiple dispersed
bridges
* There is only one
<conference-password> element. We have at least two levels of
password and can have multiple passwords for the same level. How would this be
represented?
pg17, S4.2.10
* would S4.2.10 depend on S4.2.11, and is
there a way to capture that dependency
* Does this maximum user count refer to the
maximum users supported by the media mixing servers, or the limit for the
conference?
* Is there any way to indicate that the
maximum-user-count can be increased on demand if
necessary?
pg 18, S4.2.11
* No mention of data,
whileboarding. Need a way to indicate bandwidth, preferred audio / image
formats.
* What type of <mute> does
<mute> provide. We differentiate two types of mute: "mute" is a mute
that can be applied by a moderator or by yourself. It can only be removed
by yourself. "silence" is a mute that can only be applied or removed by a
moderator.
* How can other controls be
exposed?
pg19, S4.3
* Failover scenario - tcp-ip possibly
changes
pg 19, S4.4
* Is this data model only
concerned with runtime info? If not need a way to indicate cancelled, billed,
aborted, confirmed and possibly other states
pg 22, S4.6
* Presumably user can have
multiple roles simultaneously.
pg23, S4.6.3
* No definition of roles, format of
uris
pg 24, S4.6.4
*
No definition of roles, format
of uris
pg 24, S4.5.0
* How are user PINs represented, i.e.
the number unique to each user that allows them to identify themselves via the
TUI after entering the conference password
pg 27, S4.6.5.10
* Can multiple users hold the floor
in the same floor at the same time? Can a user hold multiple floors at the same time? An
example of these would be good.
pg28, S4.6.5.10
* Data, whiteboarding in the
from mixer element
pg28, S5
* This section duplicates
Appendix A., shouldn't the schema be
defined in one location only in order to reduce
the posibility of synchronization
errors
