[Asterisk-video] Conference..

[Sergio Garcia Murillo]

Hi Hans,

The MCU is composed by a business logic/signaling (based on java sip 
servlets)  and a media server (implemented in C++).
The java part needs to be deployed into an sip servlets compatible 
application server, been Sailfin (based on Glashfish code) one of them
You can also deploy it on Mobicents Sip Servlets, which is has a version 
based on Tomcat and another one in JBoss AS7.

http://www.mobicents.org/products_sip_servlets.html

As a bonus, if you use Mobicents, it provides support for sip over 
websocekts, so you can directly call the MCU with a WebRTC enabled 
browser and join the same conferences as your sip phones, until Asterisk 
natively supports WebRTC clients.

Best regards
Sergio

El 19/01/2013 14:57, Hans Witvliet escribió:
> Hi Sergio,
>
> No problems with biased opinions.
>
> We are just starting to look at it, and there are no requirements, yet.
> During one of the meetings however it was clearly stated however that
> "switched mode" is no option:
> It boils down to this, if you have one party speaking it is not only
> important to see the speaking person, but it is at least as important to
> see the listening parties. (disbelief, disgust, approval) before they
> react. Sometimes a facial expression and saying nothing says enough.
>
> Obviously multiplexing / transcoding of video streams is a hell of a job
> requiring many cpu cycles. Thus offloading to one or more dedicated
> machines is a sensible thing to do. Probably related to the number of:
> a) simultaneously conferences
> b) participating users.
> c) used codecs
>
> I'll pass your info along, it is certainly interesting.
>
> Just a single question:
> The online docu mentions SUN's glassfish as an java application server.
> Is mcu tied to this, or can one choose to use something like JBoss?
> And likewise, just SUN/Oracle-java or also openjdk?
> Probably "anything is possible", but any experience with them?
>
>
> Tnx, Hans
>
> On Fri, 2013-01-18 at 14:09 +0100, Sergio Garcia Murillo wrote:
>> Hi,
>>
>> My opinion my biased, but IMO if you choose to do video mixing and not
>> video switching, doing it in the same Asterisk box is a BAD idea (due to
>> the resources needed).
>>
>> Much better to use a dedicated MCU which you may locate in different
>> server (and even better, in several servers), you can use mine which is
>> ea silly integrated with asterisk:
>>
>> http://www.medooze.com/products/mcu.aspx
>>
>> Best regards
>> Sergio
>> El 18/01/2013 12:32, Hans Witvliet escribió:
>>> Hi all,
>>>
>>> Just noticed that Emil (main developper of jitsi) is going to do a
>>> lecture at upcoming Fosdem. Key note:
>>>
>>> <snip>
>>> About a year ago the Jitsi project developers started work on support
>>> for video conference calls. We had had audio conferencing for a while at
>>> that point and we were using it regularly in our dev meetings. Video
>>> seemed like a logical next step so we rolled our sleeves and got to
>>> work.
>>>
>>> The first choice that we needed to make was how to handle video
>>> distribution. The approach that we had been using for audio was for one
>>> of the participating Jitsi instances to mix all flows. That's easy to do
>>> for audio streams and any recent machine can easily mix a call with six
>>> or more participants.
>>>
>>> Video however was a different story. Mixing video into composite images
>>> is an extremely expensive affair and one could never achieve this
>>> real-time with today's desktop or laptop computers. We had to choose
>>> between an approach where the conference organizer would simply switch
>>> to the active speaker or a solution where a central node would relay all
>>> streams to all participants, while every participant keeps sending a
>>> single stream.
>>>
>>> We finally went for the latter which also seems to be the approach taken
>>> by Skype and Google for their respective conferencing services. We
>>> started by implementing all this in Jitsi but along the way we also
>>> decided to make the RTP relaying part a separate server-side component.
>>> This is how Jitsi Videobridge was born: an XMPP server component that
>>> focus agents can control via dedicated XMPP IQs.
>>> </snip>
>>>
>>>
>>> After reading this, my first reaction was: great!
>>> My second was: bummer, it's just for xmpp.
>>> Third: Isn't this something that should/could have been done in
>>> asterisk?
>>>
>>>
>>> Hans.
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- 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
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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
>
> --
> _____________________________________________________________________
> -- 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