Hi,
> 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 :-)
I think that the name have to start with some vowel letter like "A". I
prefer the name of the future IP PBX to be Acacia, so I would like to
reserve this word. My idea for this future project is to combine ERP +
CRM + IP PBX. If you see what is in the market now you will see that
most of the IP PBXs prefer their IP PBX to be integrated with some CRM.
In the future ERP. And because for such solutions modules are the best
way I think that GlassFish v3 is good starting point.
My dream is Acacia to be so popular like Asterisk now. For example 3Com
and Digium (the holder of Asterisk project) are negotiated Asterisk to
be part of 3Com portfolio.
> 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.
This sounds good but there are another free codecs which can be included
also:
http://www.asterisk.org/doxygen/1.4/group__codecs.html
http://www.voip-info.org/wiki/view/Asterisk+codecs
http://www.voip-info.org/wiki-Codecs
Intel offer the full available pack of the Voice, Audio and Video codecs
including Echo Cancellation. For Linux the package is free but I don't
know how the commercial codecs will be used. The library name is Intel
Integrated Performance Primitives (Intel IPP):
http://www.intel.com/support/performancetools/libraries/ipp/
All supported codecs (Voice, Audio, Video, Cryptography, Speech
Recognition, etc.) and another useful primitives are here:
http://www.intel.com/cd/software/products/asmo-na/eng/302910.htm
Is there any way Sun and Intel to negotiated this codecs or part of them
to be included in Java?
http://www.intel.com/support/performancetools/libraries/ipp/sb/CS-021401.htm#3
http://www.intel.com/support/performancetools/libraries/ipp/win/ia/sb/cs-010676.htm
http://www.intel.com/cd/software/products/asmo-na/eng/219967.htm
I think that the best solution will be if in the RI offers a library
which support everything with some restrictions like number of
simultaneous channels, number of conference parties, etc. Especially for
the commercial codecs.
>> 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.
I will try to do that but I will need of you help especially before to
start programming - when we will discuss the interfaces and another
principal things.
But in the future jVoiceBridge have to be not only renamed. I think that
it needs of redesign to be able to support the mentioned possibilities
in my previous letter. But to be sure that our specification is useful
we have to start IP PBX as Reference Implementation. What do you think
about that your partner Ericsson?
Is there a place in your team (Sun and/or Ericsson) a place for another
player?
Regards,
Miro.
Jonathan Kaplan wrote:
> 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>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jvoicebridge.dev.java.net
> For additional commands, e-mail: dev-help_at_jvoicebridge.dev.java.net
>
>