Sreeram Duvur wrote:
> Hi Miro,
>
> Finally managed to read your detailed e-mail. It has wonderful detail.
> I do agree that voicebridge may be limiting the vision and scope. At
> some point in future we may have to rename the project. I will pass on
> the feedback.
>
Agreed. We picked the name jVoiceBridge because it is currently voice
only and we didn't want to confuse people. If we can extend it to do
more (which would be great), we can come up with a new name too. Maybe
a fish-based named like Glassfish and SailFin :-)
> Some features you mentioned like ability to record conferences, exists
> in voicebridge. Jonathan had described this to me earlier. Have you
> found any Java/Native solutions for G.711, G.729, Speex, MPEG-4,
> H.264, DTMF and IVR in open source? Would be good to bring them all
> together in one package.
>
Currently jVoiceBridge supports RTP using the G.711 and SPEEX codecs.
We also support a number of custom high-quality codecs, from CD-quality
(44.1k/stereo/PCM) audio down to telephone quality (8k/mono/ulaw). The
bridge can transcode between these formats, so a call can contain
participants at different audio qualities. We do not support any
commercial codecs, although there is a plugin mechanism to add new
ones. We support recording conferences and individual calls, as well as
DTMF detection. We also support playback from recorded files in .au and
.mp3 format.
> Sounds like your first project is in embedding Grizzly in to the RTP
> stack of VoiceBridge!
This would be great - hopefully it will significantly improve the
scalability of the bridge, and prepare it for future extensions such as
video streaming.
-Jon
> Sreeram
>
>
>
> On Dec 13, 2007, at 5:52 AM, krishna kalluri wrote:
>
>> Hi Miro,
>>
>> I have one comment for your statement below.
>>
>> For example the Stream Media Service Provider implementation can be
>> realized with different ways depending of the target:
>>
>> The above statement is violating the Java philosophy of write once
>> and run any where.
>>
>> Regards
>> /Krishna
>>
>> --- On *Thu, 12/13/07, Miroslav Nachev /<miro_at_space-comm.com
>> <mailto:miro_at_space-comm.com>>/* wrote:
>>
>> From: Miroslav Nachev <miro_at_space-comm.com
>> <mailto:miro_at_space-comm.com>>
>> Subject: Re: Instructions how to start new sub-project for RTP
>> using Grizzly
>> To: dev_at_grizzly.dev.java.net <mailto:dev_at_grizzly.dev.java.net>,
>> dev_at_sailfin.dev.java.net <mailto:dev_at_sailfin.dev.java.net>,
>> dev_at_jvoicebridge.dev.java.net <mailto:dev_at_jvoicebridge.dev.java.net>
>> Date: Thursday, December 13, 2007, 3:01 PM
>>
>> Hi,
>>
>> I will not answer to all letters. I will explain my thesis on
>> principle and then will be more concrete. From my practice the
>> success of one projects depends of the following initial steps:
>> - Determine the Target and Vision;
>> - Strategy how this Vision will be realized because most of the
>> times there are more than one way;
>> - Design of the Application/System;
>> - Development;
>> - Testing;
>> - Implementation;
>> - Maintenance and support.
>>
>> In most cases the 1st 3 steps are skipped. Unfortunately their
>> importance is in their order. That's why I will start from the
>> beginning.
>>
>> What is our target? My personal target is one modern IP PBX which
>> support most popular voice, audio and video codecs like G.711,
>> G.729, Speex, MPEG-4, H.264, etc. and is integrated with another
>> business systems like CRM, ERP, etc. Also, this solution have to
>> be used in end-terminals like VoIP Phones, PSTN/GSM Gateways, FXS
>> Telephone Adapters, etc. If our approach is principle we must
>> specify all Interfaces and Abstract Classes and to do Reference
>> Implementation of them which RI to be included in JDK. This will
>> help to hardware producers to do fast and easy their products.
>>
>> In my opinion jVoiceBridge sounds very good but is not correct
>> because we speak not only for Voice. Our target is Voice, Audio
>> and Video. And this can not be separated because in one video
>> conference the voice and video go together with timestamps, etc.
>> For me jMediaBridge or StreamMediaBridge or something like that
>> sounds better.
>>
>> Because all of the above media protocols are *extremely time
>> critical* using Java NIO is very important. I am not sure that
>> Real Time Java will help so much but you can give your opinion.
>> The main target of Grizzly project is:
>> - Uses Java technology based NIO primitives and hides the
>> complexity of programming with Java technology based NIO;
>> - Easy-to-use high performance APIs for TCP, UDP, and SSL
>> communications;
>> - Brings non-blocking sockets to the protocol processing layer;
>> - Utilizes high performance buffers and buffer management;
>> - Choice of several different high performance thread pools.
>> We need of all of this to have real working stream media library.
>> The above can not be separated in another project (using another
>> buffers and logic) because is time critical everything MUST be in
>> one place.
>>
>> Lets see the possible usages of this Stream Media Bridge:
>> 1. Conferences - here through RTP, the voice streams will come in
>> different formats, decoded in linear or another format, time
>> synchronized with video streams which also have to be decoded in
>> some common format, mixed with another streams, encoded to the
>> relevant client format and transmitted to the client in through RTP.
>> 2. VoIP Phones - here the RTP part will be connected to the
>> another VoIP side which can be Phone, Gateway, Conference Server,
>> etc. The other side of the stream will be connected to Microphone
>> and Speaker of the device. In this case the Stream library has
>> additional duties: to prevent Acoustic Echo Cancellation (G.167)
>> and to connect to Microphone and Speaker drivers in faster way.
>> Most popular IP Phones support limited Conferencing (3-5 lines)
>> so the Conference capabilities will be welcome here also. For
>> both sides Java NIO must be used.
>> 3. PSTN/GSM Gateway - this case is very similar to the 2nd case
>> with IP Phone but the differences are that instead Acoustic Echo
>> Cancellation algorithm we will need to apply Line Echo
>> Cancellation (G.168). The 2nd difference here is that we have to
>> apply Conferencing to minimize the streams which are directed to
>> main Conference Server in case that more than one parties are
>> connected to the same conference.
>> 4. Another Conference/IP PBX Servers;
>> 5. Voice Recording is very important for all of the above
>> situation for 2 cases: tapping and voice mail;
>> 6. DTMF detect/generate is another feature when this
>> signalization is not passed through SIP protocol;
>> 7. FAX detect/send/receive (when fax signal is detected the line
>> echo cancellation MUST be stopped);
>> 8. etc.
>>
>> Because some codecs are commercial and maybe somebody would like
>> to use own codecs (G.729, Echo Cancellations) we MUST to provide
>> a plugin mechanism for the codecs. This plugin can be like
>> Stream/Pipe oriented which is used from the drivers in Solaris OS.
>>
>> We have to give the opportunity to the other vendors to create
>> their own implementations. That's why we have to specify an
>> Stream Media Service Provider interface/abstract class.
>>
>> For example the Stream Media Service Provider implementation can
>> be realized with different ways depending of the target:
>> 1. If the CPU is with enough power like x86 or Dual Core this
>> library can realized without additional hardware;
>> 2. If the CPU is with limited power then some DSP (integrated or
>> PCI Card with DSP) can be used;
>> 3. If the solution needs of more simultaneous calls then one or
>> more FPGA/DSP can be used;
>> 4. If the solution is for some PSTN Service Provider, then some
>> Stream Media Servers can be used.
>> Our Reference Implementation (RI) can be the 1st variant. But we
>> have to expect all possible variants in our specification.
>>
>> It is not obligatory to implement everything of the above but we
>> must foresee it in interfaces and abstract classes.
>>
>>
>> *Now let's return to the RTP requirements and specification.*
>> 1. Summary - RTP is a peer-to-peer network transport that handles
>> stream and message data. It is designed for scenarios where
>> latency is more important than guaranteed delivery. RTP is
>> currently used in all Stream Media Applications.
>> 2. Requirements:
>> *Requirement
>> * *Description*
>> Compatibility
>> - Meets all requirements of RFC 1889 and RFC 3550
>> - Able to receive and parse RTP headers from Audio and Video
>> Conferencing Tool (VIC) transmissions
>> - Sent packets able to be decoded by most popular RTP decoders
>> - Able to coexist peacefully with data streams from VIC as long
>> as we don’t have collisions where VIC sends on the same
>> Synchronization Source (SSRC) and Payload Type.
>> Performance
>> - Able to send N x 640 x 480 and (N+1) x 320 x 240 compressed
>> streams
>> - Able to receive N x 640 x 480 and (N+2) x 320 x 240 streams or
>> (N + 4) x 320 x 240 streams or (N + 5) x 160 x 120 streams
>> - Able to transmit 60 Megabits per second (Mbits) of raw data (90
>> Mbits if not NIC constrained)
>> /*- What about 1,000 Mbits and 10,000 Mbits NICs?*/
>> - Only consume 20% CPU and 32 MB of RAM (not including
>> encode/decode) while transmitting 60 Mbits on Dual 2.4GHz Xeon,
>> 1GB RAM systems
>> Optional
>> Network Diagnostics
>> Tools to enable an administrator or operator to see at an
>> instant what the network connectivity status is between all
>> nodes. This is necessary because tools for diagnosing Multicast
>> problems are missing or weak.
>>
>> /*Where we have to determine N*/
>>
>> I will start preparing of RTP Interfaces and specification, then
>> will send to discuss it in the forum, and after that I will start
>> working.
>>
>>
>> Regards,
>> Miro.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_sailfin.dev.java.net
>> <mailto:dev-unsubscribe_at_sailfin.dev.java.net> For additional
>> commands, e-mail: dev-help_at_sailfin.dev.java.net
>> <mailto:dev-help_at_sailfin.dev.java.net>
>>
>>
>> ------------------------------------------------------------------------
>> Looking for last minute shopping deals? Find them fast with Yahoo!
>> Search.
>> <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_sailfin.dev.java.net
>> <mailto:dev-unsubscribe_at_sailfin.dev.java.net> For additional
>> commands, e-mail: dev-help_at_sailfin.dev.java.net
>> <mailto:dev-help_at_sailfin.dev.java.net>
>