| From | Sent On | Attachments |
|---|---|---|
| Sergio Garcia Murillo | Jan 30, 2009 2:17 am | |
| Mitul Limbani | Jan 30, 2009 9:54 am | |
| tele...@vedatel.com | Jan 30, 2009 11:41 am | |
| Sergio Garcia Murillo | Jan 31, 2009 2:34 am | |
| Sergio Garcia Murillo | Jan 31, 2009 2:41 am | |
| Mitul Limbani | Jan 31, 2009 2:57 am |
| Subject: | [Asterisk-video] MCU architecture | |
|---|---|---|
| From: | Sergio Garcia Murillo (serg...@fontventa.com) | |
| Date: | Jan 30, 2009 2:17:47 am | |
| List: | com.digium.lists.asterisk-video | |
Hi everyone,
Currently the mcu solution has two main components, the VideoMixer and the mcuWeb.
The videomixer component handles ONLY media, i.e. it receives rtp, unpack audio and video, performs audio/mixing video, encoding, packing and rtp sending. It is completely controlled by a xmlrpc interface and has no service logic at all.
The current xmlprc api has the following methods:
-Create/Destroy conference -Add/Remove participant to conference -Set conference parameters like video size and number and distribution of participants on screen -Set audio/video send/receive ports per participant -Set audio/video codec and parameters (size,fps) etc per participant -(Un)Mute participant -Set conference mosaic positions: lock slot, assign slot to participant, etc.. -Add watch only participant to conference (experimental: flash video broadcasting in web)
It currently supports only h263p but should not be too difficult to add support to h264. The rest of the functionalities are completed (except flash support) and only a bit of testing is needed. In the near future I would like to convert the videomixer in a MediaServer, been able not only to offer multivideo conference services, but also transcoding, flash casting, etc..
As I said before everything is controlled by an xmlrpc api, so a component handling the service logic and signalling is needed. That component could app_conference and the confiance project did integrate the video mixer as an external unit.
I decided to implement it as a complete external unit from Asterisk. Why? I think it was easier quicker and easier to develop, avoid the monolithic and sometimes obscure architecture of asterisk and could provide much more functionalities. And the chosen technology was.. java (I feel a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced).
Yes, Java, using the Sailfin Sip Application Server (https://sailfin.dev.java.net/) which allows to create an application that handles SIP and HTTP request (an application like click to dial is just a few lines of code http://wiki.glassfish.java.net/Wiki.jsp?page=SipClickToDialExample2). If you start with your prejudges about java, speed and show on, just think that it is a telco grade Sun and Ericsson development.
The mcuWeb component implement the service logic, handles all the SIP signalling (receiving invite request from asterisk), controls the Video Mixer with the xmlrpc and offers a WEB UI to manage the conferences.
This part is also fully functional, but I think that is where more work is needed in order to customize the service with the functionalities needed by the customers. In particular questions like the following need to be answered:
- Is it required to create the conference before the user calls? or it get created when it calls in? - Are there private conferences? How are the participants allowed to get in, by password or by invite only? - Is there always a default public room? - etc...
Any thoughts are welcome
Best regards Sergio
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-video mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-video





