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@sailfin.dev.java.net
For additional commands, e-mail:
dev-help@sailfin.dev.java.net