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.
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.
Sounds like your first project is in embedding Grizzly in to the RTP
stack of VoiceBridge!
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> wrote:
> From: Miroslav Nachev <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, dev_at_sailfin.dev.java.net, 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 For
> additional commands, e-mail: dev-help_at_sailfin.dev.java.net
>
> Looking for last minute shopping deals? Find them fast with Yahoo!
> Search.
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe_at_sailfin.dev.java.net For
> additional commands, e-mail: dev-help_at_sailfin.dev.java.net