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"

(New page: 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 poin...)
 
Line 1: Line 1:
 
This page will be updated regularly with status reports on the development progress of the VoIP implementation via Jingle in the ECF.
 
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 ===
+
== 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:
 
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:
Line 17: Line 17:
  
 
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.
 
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.
 +
 +
[[Image:Jingle-provider.jpg]]

Revision as of 15:49, 31 May 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

Back to the top