[Asterisk-video] Conference..

Sat Jan 19 08:56:09 CST 2013

By the way..

You may test the webrtc support here..  (Chrome 24 or up needed)

http://c21medooze.cires21.com/mss-example/

;)
Sergio

El 19/01/2013 15:54, Sergio Garcia Murillo escribió:
> 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
>
>
>
> -- 
> _____________________________________________________________________
> -- 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