Changes between Version 1 and Version 2 of mexcla-expansion


Ignore:
Timestamp:
May 23, 2014, 9:23:28 PM (10 years ago)
Author:
Stephen Mahood
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • mexcla-expansion

    v1 v2  
    66
    77    Leave everything as is, and just work on the mexcla.tac (twisted service)
    8 
    98    Build a form that creates the channel, and determines how many interpretation channels exist, using the mexcla.tac infrastructure.
    10 
    119    Revamp the whole fucking thing and use freeswitch webrtc Sip.js, this option may or may not require also using the mexcla.tac.
    1210
     
    1513
    1614    Easiest to accomplish
    17 
    1815    Faster
    19 
    2016    Keeps the same not perfectly beautiful interface.
    21 
    2217    Not too much work
    2318
     
    2520
    2621    Not resolving current problems with mexcla (which might be a problem with the protocol)
    27 
    2822    Does not improve sound quality.
    29 
    3023    Does not improve development of webrtc.
    31 
    3224    Does not fully integrate into our webrtc infrastructure.
    33 
    3425    Limits user interaction.
    3526
     
    3829
    3930    Allows better interaction for people hosting a call.
    40 
    4131    Permits language designation for the specific interpretation channel, i.e. more info for callers.
    42 
    4332    Helps expand functionality, specific to each call.
    44 
    4533    Relatively easy to implement.
    46 
    4734    Would allow for adding features (pads, irc, calc, presentation, chat) to the channel.
    4835
     
    5037
    5138    Would require work, more development and testing.
    52 
    5339    Would create more bugs.
    5440
     
    5743
    5844    integrate live (video) and mexcla (audio)
    59 
    6045    get to learn cool new things
    61 
    6246    Tighter integration to freeswitch (probably)
    63 
    6447    Perhaps better audio quality
    65 
    6648    Would be using websockets.
    67 
    6849    We'd be cutting edge!!!!
    69 
    7050    perhaps better integration with live.m.o
     51    USi feels they can raise more money for this one
    7152
    7253=== Cons ===
    7354
    7455    Don't know what we're doing
    75 
    7656    Possibly lots more bugs
    77 
    7857    perhaps we end up revamping live.m.o too
    7958
     59
     60= Language Architecture =
     61We have a number of ideas about how to handle the interpretation infrastructure:
     62    == Current Structure ==
     63    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.
     64     == Ideal Structure ==
     65    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.
     66= Conference Architecture =
     67    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.
     68Assuming 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.
     69== Moderator Admin Interface ==
     70    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. 
     71    We might want a way for the moderator and interpreters to be able to speak privately (or mostly privately).  In case something goes wrong.
     72== Interpreter's Interface ==
     73    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.
     74== Participant Interface ==
     75   This interface is the standard participant interface that would include raising/lowering  hand to speak, switching languages, see participants, etc.
     76= Room Builder =
     77   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.