Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] ECF VOIP - Signalling and Media Transport Providers

Hi Scott, Hi Pierre,

Is EPL compatible with the SCSL (Sun Community Source Licensing - I figured out the
information I got from the "Jingle Audio SOC project" wasn't very precise
with regards to the available Media/RTP libraries and codecs. ECF VOIP can
use JMF directly! JMF in return uses JavaSound for low level capture,
playback, mixing etc. We (or 3rd Parties) can extend the JMF, using its
plug-in architecture, to support codecs that are not available out of the

My inclination is to bundle the JMF source (assuming if SCSL/EPL
compatibility) into an "ECF media/rtp Provider" as described above so it can
be coupled with different "ECF VOIP Providers" (Jingle, IAX, SIP, ...) to
provide VOIP communications.

Our Call API will shield users from the details of the underlying "ECF VOIP
Providers" implementations. The "ECF VOIP Providers" will in return be
TIGHTLY COUPLED with the "ECF media/rtp Provider" to deliver voice
capability. With this, we make use of the abstraction already provided by
JMF and do not need to design any special "ECF media/rtp API". Extensions
can be made by low-level plumbing within the JMF code or simply by using its
available JMF plug-in architecture.

"ECF VOIP Providers" CAN and MUST NOT use the "ECF media/rtp Provider" for
carrying and delivering their payload (VOICE). E.g. ECF can interact only at
the available API level with Skype. The Skype API, to the best of my
knowledge, provides no possibility to separate Signalling and media
transport. This, however, is relevant only to the "ECF Skype Provider"
implementer who will not make use of the "ECF media/rtp Provider".

Any further thoughts on this? If not, I'll bundle the JMF as mentioned above
so Pierre and I can go ahead and couple the upcoming "ECF Jingle Provider"
with the "ECF media/rtp Provider" (of course considering the fact that the
Call API still has to be completed).

Roland N. Fru.

Back to the top