Skip to main content

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

Hi Roland,

Roland N. Fru wrote:
Hi Scott, Hi Pierre,

Is EPL compatible with the SCSL (Sun Community Source Licensing -
I don't know the status of the Sun Community Source License. I'll ping Janet Campbell about it and copy Roland and Pierre.

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.

This seems like a terrific idea to me. Separate signalling/call setup API (ECF call API) and protocol (Jingle, IAX, SIP, etc) from a 'streaming media' provider.

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.

I don't know JMF well enough to say if this makes sense, but perhaps it would be an advantage to define a media/rtp API *anyway* to allow for other media/rtp provider implementations (i.e. other than JMF)? For example, whatever Google Talk uses for media/rtp delivery (the name escapes me right now).

"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".

Right. Having the signalling separate from the 'media/rtp provider' allows this and supports the notion that for some implementations (e.g. Skype) that they would not expose media/rtp functionality at the level of the API...but would expose call setup/signalling (as they do).

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).

I'll engage Janet on the question of license compatibility with SCSL and EPL and copy Roland and Pierre. If others are interested in this specifically (licensing/redistribution issues WRT SCSL please just let me know and I'll include you on the thread.



Back to the top