Recon ToDo List

From reSIProcate
Jump to: navigation, search

TODO List[edit]

  • 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 (essential, not supported)
    • SRTP (essential, supported)
    • AVPF and SAVPF (essential, not 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