Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VoIP in ECF, GSoC07 DevLog"

(13.06.2007)
Line 53: Line 53:
 
== 13.06.2007 ==
 
== 13.06.2007 ==
  
Created some graphics describing the IAdapater pattern in the Eclipse Communication Framework. The image describes the implementation in the Jingle provider. Additionally further work has been done on the jingle adapter itself.
+
Created some graphics describing the IAdapater pattern in the Eclipse Communication Framework. The image describes the implementation in the Jingle provider. Additionally further work has been done on the SmackAPI demo.
  
 
Image: [[Media:Adapter-pattern-in-ecf.jpg|Adapter pattern in the ECF]] (549x680, 116 KB)
 
Image: [[Media:Adapter-pattern-in-ecf.jpg|Adapter pattern in the ECF]] (549x680, 116 KB)

Revision as of 11:52, 13 June 2007

This page will be updated regularly with status reports on the development progress of the VoIP implementation via Jingle in the ECF.

30.05.2007

Trying to identify the usage points of the jmf in the Smack API. The intention is to take control of the media framework via the call api. In detail this constitutes the audio with bitrate, samplerate, mono/stereo as well as the current status of the media playback and recording. Additionally it is intended to set the current playback parameters like volume or pan. As it seams, the usage is pretty interwoven with the Smack API itself. Therefore it is not as easy as intended to access the necessary jmf infrastructure. The key jmf classes required are:

Locations of required jmf infrastructure in the Smack API
Required JMF class Location in the Smack API Intended Usage
javax.media.Player org.jivesoftware.smackx.jingle.mediaimpl.jmf.AudioReceiver The Player class and its base class the Controller can be used to get timing information about the data stream.
javax.media.Processor org.jivesoftware.smackx.jingle.mediaimpl.jmf.AudioChannel The Processor (extending Player) in the AudioChannel class is running the audio conversion. It is also able to provide the required javax.media.GainControl. This GainControl is able to modify the volume, pan etc.

As it seams the AudioReceiver is not able to handle payload (encoding details of the stream) changes on runtime. As the possible payload types are preconfigured (hard coded) in the Smack API, those predefined values would need to be changed before establishing a connection. Possibly be removing higher quality payloads to use less bandwidth.

The currently supported Payloads are: gsm, g723 and PCMU at 16000 bits. There configuration takes place in org.jivesoftware.smackx.jingle.mediaimpl.jmf.JmfMediaManager. According to the api docs those codecs work on Windows and Mac only.


31.05.2007

Posted several issues in the SmackAPI forum. Tried to contact Thiago Camargo, the author of the SmackAPI, with several issues described in the previous posting.

Additionally created a figure to describe the architecture of the Jingle Provider in the context of the ECF. It can be seen here.

Jingle-provider.jpg

04.06.2007

Progress can be reported with the SmackAPI. Although no concrete voice is transmitted yet, after various connection configuration attempts it turned out, that the current TransportManager is not well suited. Instead of using an ICETransportManager a STUNTransportManager is used now. It is able to handle NAT based connection issues and does not rely on an intermediator like the ICETransportManager. As a result the current configuration is able to negotiate the connection details such as ports to use for the connection and what codecs to use. In the logs this manfiests as:

...
Track 0 is set to transmit as:
gsm/rtp, 8000.0 Hz, Mono, FrameSize=264 bits
Created RTP session at 19028 to: 84.166.96.253 12568
....

Although the setup seams to be up and running, there is still no voice to be heard. I have posted this development to the ignite forum.

06.06.2007

Further researched the ECF call api trying to figure out what extensions need to be implemented for the jingle implementation.

11.06.2007

Spend more time working on the jingle demo application. One issue has been solved but there is still no voice for the voiceless. The discussion continues in the ignite forum. As it seams my network setup is not the main problem. I have tested the Spark XMPP client which uses the SmackAPI. Spark is able to provide computer-to-computer voice communication with the very same jingle api.

12.06.2007

Implemented the adapter facilities of the call api. The goal is to create a custom IAdapterFactory to extend the XMPPContainer. The adapter type provided here is an ICallSessionContainerAdapter. To understand the adapter approach it is advised to consult this resource: http://www.eclipsezone.com/articles/what-is-iadaptable/

13.06.2007

Created some graphics describing the IAdapater pattern in the Eclipse Communication Framework. The image describes the implementation in the Jingle provider. Additionally further work has been done on the SmackAPI demo.

Image: Adapter pattern in the ECF (549x680, 116 KB)

Back to the top