Below are comments based on my expectations of a Chat Room capability. I don't want to distract focus from what is already targeted - a demo of the base content for 4.2 will be great to see. Also, to aid delivery of a baseline content before worrying about adding more I've separated pieces to consider as future content.
Chat room expectations: - Configuration by admin If it makes sense for the admin to configure a chat room for a user then I don't see as a concern, however, some key points are: i) less admin overhead is generally preferred ii) giving everyone chat room capability as a default is fine iii)Chat room participants should be ad-hoc and not pre-defined (I wasn't clear on if the moderator has to pre-define the participant in their buddy list vs. doing on the fly .. I would like to see on the fly). - Adhoc Chat room participants should be independent of audio/video conf participants User/moderator of chat room should be able to identify who they invite to the chat room *and* do so independent of who is involved in an audio conference they may have occurring in parallel. - mutltiple chat rooms (not req'd day 1) Ideally, from a user perspective, he/she may have multiple chat rooms open at the same time. - name the chat room (not req'd day 1) A title or name for each chat room is desireable - sub-chat withing chat room (not req'd day 1) participants in the chat room should be able to select all or only some (one for example) participant to IM with. IAN -----Original Message----- From: Joly, Robert (CAR:9D30) Sent: Monday, August 31, 2009 12:53 PM To: Steinmann, Martin (BL60:2500); M. Ranganathan; Fowler, Peter (CAR:9D10) Cc: sipX developers Subject: Re: [sipX-dev] Openfire chat room management assumptions / questions > >> > >> > > >As part of the Personal Assistant I support voice conference > related IM > >commands such as > > - who => who is/was talking > > - list => list participants > > - mute/unmute participant > > - disconnect participant > > - lock/unlock > > > >So having chat room IM commands provides consistency. > > > > > > >The question was whether we want to support this in > sipxconfig or can we just rely on the client providing these commands. > I am concluding that sipxconfig support is >not necessary. > > > >Please elaborate on what was implied by your last statement. > > > > > >Thanks > > > >Regards > > > >Ranga > > > > We would like to focus on the Couterpath / SMC client. The first thing > I am not clear about is how the user would enter a personal chat room > that he/she can moderate. By default is seems the client creates an > ad-hoc chat room. How would the client default to the one the user > owns or moderates? I've been focusing on pidgin so far so pardon my ignorance. You say that by default the SMC client seems to create ad-hoc char rooms. I've tried to get my SMC3456 to do that much without success, how did you achieve that? So, as you can see from my question above, I cannot answer your SMC-specific question but I can give you my general view on it based on my pidgin experience. The idea is that the sipXecs, when creating a voice conference for a user, will also be given the opportunity to create an associated chat room for which the user will be the moderator. Once this is done a user can enter a chat room by adding it to its 'buddies' (in pidgin this is done via the 'add chat' option). That will make the chat room appear as a buddy and double-clicking it will put you in that room. > > Once we know that I guess we need to figure out whether we want to > pre-provision personal group chat rooms for every user. I assume all > the nice commands only work if this is your room. For consistency sake I would not do that and instead would keep with the audio conference model, i.e. the admin creates the rooms that are required. > > At this stage I am unclear around how this feature of group chat would > present itself to the user, other than offering the ability to create > an ad-hoc room (does the client do this on its own?). Ad-hoc is not really the way I see this being used. The idea is that a multi-user chat would be owned by a user the same way it owns a conference bridge. This gives a user 'audio' and 'IM' conferencing capabilities. Furthermore, we are working at strengthening the link between a user's audio and IM conferencing capabilities by adding the capability of promoting an IM conference into an 'IM' + 'audio' conference via a single text command. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
