Mexlca - Expansion

Expand existing infrastructue to have more than 1 interpretation channel

Development Approaches

Leave everything as is, and just work on the mexcla.tac (twisted service) Build a form that creates the channel, and determines how many interpretation channels exist, using the mexcla.tac infrastructure. Revamp the whole fucking thing and use freeswitch webrtc Sip.js, this option may or may not require also using the mexcla.tac.

Everything in tact

Pros

Easiest to accomplish Faster Keeps the same not perfectly beautiful interface. Not too much work

Cons

Not resolving current problems with mexcla (which might be a problem with the protocol) Does not improve sound quality. Does not improve development of webrtc. Does not fully integrate into our webrtc infrastructure. Limits user interaction.

Build webform for handling channel creation

Pros

Allows better interaction for people hosting a call. Permits language designation for the specific interpretation channel, i.e. more info for callers. Helps expand functionality, specific to each call. Relatively easy to implement. Would allow for adding features (pads, irc, calc, presentation, chat) to the channel.

Cons

Would require work, more development and testing. Would create more bugs.

Revamp

Pros

integrate live (video) and mexcla (audio) get to learn cool new things Tighter integration to freeswitch (probably) Perhaps better audio quality Would be using websockets. We'd be cutting edge!!!! perhaps better integration with live.m.o USi feels they can raise more money for this one

Cons

Don't know what we're doing Possibly lots more bugs perhaps we end up revamping live.m.o too

Language Architecture

We have a number of ideas about how to handle the interpretation infrastructure:

Current Structure

Requires the listeners to switch between the main channel and the interpretation channel. In this model a single interpreter "could" interpret in both directions between their native language and the primary language.

Ideal Structure

Two interpretation lines for each language, which would require at least two interpreters per language. In this module the primary channel would only hear the central langugae. So that one interpretation line, call it "French" will have a channel that interprets into French and a chanell that interprets into the primary language ( with the interpreter speaking into the primary channel in the central language.

Conference Architecture

In order to actualize the complexity of the ideal situation for interpretation, we think that the most effective mechanism would be for a fully structured conferencing system. That includes moderation. With a moderator we could have more automated control of the flow of interpretation. In this situation, the moderator would choose who is speaking and we'd automate which interpretation channel gets piped into the primary channel.

Assuming we have 3 lines per interpretation channel, the moderator approach would allow the software to determine whether or not the third interpretation cannel gets piped into the central channel, or if there is only one interpreter then that interpreter's stream gets put into the primary channel.

Moderator Admin Interface

We'll have to create an admin interface for the moderator, which would allow them to build a stack of speakers, and to call on someone, among other things not outlined yet. We might want a way for the moderator and interpreters to be able to speak privately (or mostly privately). In case something goes wrong.

Interpreter's Interface

We'll need some kind of interpreter interface that allows the interpreter to signal to the moderator., though initially the interpreter will have the ability to speak to the main line.

Participant Interface

This interface is the standard participant interface that would include raising/lowering hand to speak, switching languages, see participants, etc.

Room Builder

This is the web form encountered prior to the creation of the conference room. Will include number of interpretation channels, and other things in a web form.

Breakdown the areas to focus

Idea	Consideration	Status
Webform		html	Needs Research
Pad		etherpad	Needs Integration method
Calc		ethercalc	Needs Integration method
Presentation		etherpad or impress.js	Needs Research
Chat		xmpp, irc, other	Needs Research
Private Message		possibly connected to chat	Needs Research
Moderation UI		Freeswitch Hooks	Needs Research