> >-----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? > > Unfortunately we cannot support or 'deliver' Pidging as part > of a product. I do think though that Pidgin as well as > possibly Spark are two great secondary offers for clients > that customers can use 'as is' and without support
SMC will likely be the client of choice for many remote workers but it will certainly not be for ordinary workers. Expect that the vast majority of users will not be using SMC as their IM clients. We may not want to advertize official support of them but we need to include them in our development and testing. > All I did is right click a buddy in the Counterpath client > and select "Start Group Chat". Not sure what it really does, > but it creates a chat room with an ID shown in the header of > the window that is a long human unreadable identifier. I > don't know how that would relate to any chat rooms setup in > the Openfire admin UI or even chat rooms for which I am the > owner or moderator. Thanks. I tested this out and that procedure creates a temporary chat room on openfire whose name is a long alphanumeric sequence. That room ceases to exist when the last participant leaves it. > > If we end up with 'personal' chat rooms (and I like that > idea), then it needs to be a simple click for the user to > start a group chat and invite buddies into that room. > Specific moderator commands then would work in that room I guess. In pidgin you can very easily add your assigned room as a buddy which allows you to enter your room with a double-click but I cannot find an equivalent function in the Counterpath client. That would be one thing that would surely need to be improved on the client. > > > > >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. > > I like that. Wouldn't this mean that we pre-configure chat > rooms like we pre-configure conference bridges? Conference bridges are not pre-configured. When you add a user in sipXconfig, it does not come with a conference bridge automatically. The administrator has to separately create the conference and designate the user that owns it. The same model will be applied to chat rooms. > > > > >> > >> 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. > > Again, this sounds great. Controlling the chat room in a > similar way we do dynamic conference bridge control (i.e. > from the user portal) would make sense. This could be nice but I wasn't proposing that. In fact, for the initial release we are hoping to get away without having chat controls in the web portal. > Using IM commands is > good, but harder to use and remember. _______________________________________________ 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/
