Difference between revisions of "Recon ToDo List"

From reSIProcate
Jump to navigation Jump to search
Line 1: Line 1:
 
===TODO List===
 
===TODO List===
*In order for recon to appeal to the widest audience possible, some changes should be made in order to provide a better layer between the underlying media stack (currently sipXtapi) and the Conversation Manager.
+
*In order for recon to appeal to the widest audience possible, some changes should be made in order to provide a better layer between the underlying media stack (currently sipXtapi) and the Conversation Manager.
 +
** alternative media stacks include:
 +
*** WebRTC media stack uses [http://www.webrtc.org/reference/native-apis libjingle] and supports ICE/STUN/TURN, SRTP and many of the essential audio and video codecs for the future
 +
*** [http://gstreamer.freedesktop.org/ gstreamer] (common on Linux systems)
 +
*** media stacks and codec modules from Asterisk or FreeSWITCH projects
 
* Provide a media access API/thin layer so that sipX API's are not accessed directly from different areas in recon source code.  Currently sipX API's are accessed in the following locations:
 
* Provide a media access API/thin layer so that sipX API's are not accessed directly from different areas in recon source code.  Currently sipX API's are accessed in the following locations:
 
** ConversationManager.cxx - contains main sipXmediaFactory and sipXmediaInterface - the interface into sipX library
 
** ConversationManager.cxx - contains main sipXmediaFactory and sipXmediaInterface - the interface into sipX library
Line 30: Line 34:
 
*Implement ICE
 
*Implement ICE
 
*Optimize Locking in reflow MediaStream object
 
*Optimize Locking in reflow MediaStream object
 +
* WebRTC support, this depends on some of the items above, particularly:
 +
** ICE (not supported)
 +
** SRTP (supported)
 +
** video (not essential, but desirable, not currently supported)
 +
** Opus audio codec (not essential, but desirable, not currently supported)
 +
* sipX RPM - the spec file has been created upstream, it is currently pending a [https://bugzilla.redhat.com/show_bug.cgi?id=961237 Fedora review request]
 +
* configuration of different internal audio sample rates
 +
** currently hardcoded for 8000 samples/sec sample rate
 +
** G.722 is best with a bridge that uses 16000 samples/sec internally
 +
** sipXtapi media framework provides [http://sipxtapi.sipfoundry.org/wiki/Frequently_Asked_Questions a way to change the default sample rate] and it just needs reCon to support this config option and make necessary SDP changes
 +
* support for the G.722 codec
 +
** G.722 has some peculiarities with SDP and we may need to support more than one of these permutations on a per-peer basis
 +
** some [https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/test/testUA.cxx?revision=10167&view=markup#l1451 code comments/hacks] already reveal how this works for Polycom phones (tested 2013)
 +
* creating a basic server process from [https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/test/testUA.cxx?view=markup testUA] would involve the following steps:
 +
** devising a way to send commands over a TCP socket or message queue instead of using stdin/stdout.  Sending and receiving commands in JSON format appears desirable as it allows interaction with Python and potentially a web UI.
 +
** Using the [https://svn.resiprocate.org/viewsvn/resiprocate/main/rutil/ConfigParse.hxx?view=markup rutil/ConfigParse] mechanism for parsing a configuration file and command line settings
 +
** Using the [https://svn.resiprocate.org/viewsvn/resiprocate/main/rutil/ServerProcess.hxx?view=markup rutil/ServerProcess] mechanism for running as a daemon, dropping privileges, etc
 +
** the conversion of reTurn server to run as a daemon process (before the v1.8 release) provides a good example of how to go about this
 +
* support for authentication/authorization schemes

Revision as of 05:34, 17 June 2013

TODO List

  • In order for recon to appeal to the widest audience possible, some changes should be made in order to provide a better layer between the underlying media stack (currently sipXtapi) and the Conversation Manager.
    • alternative media stacks include:
      • WebRTC media stack uses libjingle and supports ICE/STUN/TURN, SRTP and many of the essential audio and video codecs for the future
      • gstreamer (common on Linux systems)
      • media stacks and codec modules from Asterisk or FreeSWITCH projects
  • Provide a media access API/thin layer so that sipX API's are not accessed directly from different areas in recon source code. Currently sipX API's are accessed in the following locations:
    • ConversationManager.cxx - contains main sipXmediaFactory and sipXmediaInterface - the interface into sipX library
      • createMediaInterface
      • setVolume
      • setMicrophoneGain
      • muteMicrophone
      • enableEchoCancel
      • enableAutoGainControl
      • enableNoiseReduction
    • BridgeMixer.cxx - API's to control the sipX bridge mixing matrix
      • setMixWeightsForOutput
      • setMixWeightsForInput
    • MediaResourceParticipant.cxx - API's to play tones, files, media
      • start/stopTone
      • start/stopAudio
      • playBuffer
      • createPlayer (deprecated in latest sipX)
    • RemoteParticipantDialogSet - API's to create local socket/connection
      • create/deleteConnection
      • getCapabilities
      • getConnectionPortOnBridge
    • RemoteParticipant.cxx - API's to start/stop RTP
      • setConnectionDestination
      • start/stopRtpSend
      • start/stopRtpReceive
      • isReceivingRtpAudio
      • isSendingRtpAudio
  • Implement ICE
  • Optimize Locking in reflow MediaStream object
  • WebRTC support, this depends on some of the items above, particularly:
    • ICE (not supported)
    • SRTP (supported)
    • video (not essential, but desirable, not currently supported)
    • Opus audio codec (not essential, but desirable, not currently supported)
  • sipX RPM - the spec file has been created upstream, it is currently pending a Fedora review request
  • configuration of different internal audio sample rates
    • currently hardcoded for 8000 samples/sec sample rate
    • G.722 is best with a bridge that uses 16000 samples/sec internally
    • sipXtapi media framework provides a way to change the default sample rate and it just needs reCon to support this config option and make necessary SDP changes
  • support for the G.722 codec
    • G.722 has some peculiarities with SDP and we may need to support more than one of these permutations on a per-peer basis
    • some code comments/hacks already reveal how this works for Polycom phones (tested 2013)
  • creating a basic server process from testUA would involve the following steps:
    • devising a way to send commands over a TCP socket or message queue instead of using stdin/stdout. Sending and receiving commands in JSON format appears desirable as it allows interaction with Python and potentially a web UI.
    • Using the rutil/ConfigParse mechanism for parsing a configuration file and command line settings
    • Using the rutil/ServerProcess mechanism for running as a daemon, dropping privileges, etc
    • the conversion of reTurn server to run as a daemon process (before the v1.8 release) provides a good example of how to go about this
  • support for authentication/authorization schemes