Skip to content
Snippets Groups Projects
  1. Apr 17, 2018
    • George Joseph's avatar
      bridge_softmix: Forward TEXT frames · 4fb7967c
      George Joseph authored
      Core bridging and, more specifically, bridge_softmix have been
      enhanced to relay received frames of type TEXT or TEXT_DATA to all
      participants in a softmix bridge.  res_pjsip_messaging and
      chan_pjsip have been enhanced to take advantage of this so when
      res_pjsip_messaging receives an in-dialog MESSAGE message from a
      user in a conference call, it's relayed to all other participants
      in the call.
      
      res_pjsip_messaging already queues TEXT frames to the channel when
      it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
      will send an MESSAGE when it gets a TEXT frame.  On a normal
      point-to-point call, the frames are forwarded between the two
      correctly.  bridge_softmix was not though so messages weren't
      getting forwarded to conference bridge participants.  Even if they
      were, the bridging code had no way to tell the participants who
      sent the message so it would look like it came from the bridge
      itself.
      
      * The TEXT frame type doesn't allow storage of any meta data, such
      as sender, on the frame so a new TEXT_DATA frame type was added that
      uses the new ast_msg_data structure as its payload.  A channel
      driver can queue a frame of that type when it receives a message
      from outside.  A channel driver can use it for sending messages
      by implementing the new send_text_data channel tech callback and
      setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
      properties.  If set, the bridging/channel core will use it instead
      of the original send_text callback and it will get the ast_msg_data
      structure. Channel drivers aren't required to implement this.  Even
      if a TEXT_DATA enabled driver uses it for incoming messages, an
      outgoing channel driver that doesn't will still have it's send_text
      callback called with only the message text just as before.
      
      * res_pjsip_messaging now creates a TEXT_DATA frame for incoming
      in-dialog messages and sets the "from" to the display name in the
      "From" header, or if that's empty, the caller id name from the
      channel.  This allows the chat client user to set a friendly name
      for the chat.
      
      * bridge_softmix now forwards TEXT and TEXT_DATA frames to all
      participants (except the sender).
      
      * A new function "ast_sendtext_data" was added to channel which
      takes an ast_msg_data structure and calls a channel's
      send_text_data callback, or if that's not defined, the original
      send_text callback.
      
      * bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
      types and ast_sendtext for TEXT frame types.
      
      * chan_pjsip now uses the "from" name in the ast_msg_data structure
      (if it exists) to set the "From" header display name on outgoing text
      messages.
      
      Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489
      4fb7967c
  2. Dec 22, 2017
  3. Sep 21, 2017
    • Joshua Colp's avatar
      bridge: Change participant SFU streams when source streams change. · f2985e31
      Joshua Colp authored
      Some endpoints do not like a stream being reused for a new
      media stream. The frame/jitterbuffer can rely on underlying
      attributes of the media stream in order to order the packets.
      When a new stream takes its place without any notice the
      buffer can get confused and the media ends up getting dropped.
      
      This change uses the SSRC change to determine that a new source
      is reusing an existing stream and then bridge_softmix renegotiates
      each participant such that they see a new media stream. This
      causes the frame/jitterbuffer to start fresh and work as expected.
      
      ASTERISK-27277
      
      Change-Id: I30ccbdba16ca073d7f31e0e59ab778c153afae07
      f2985e31
  4. Mar 07, 2017
    • Joshua Colp's avatar
      core: Add stream topology changing primitives with tests. · 3ed05bad
      Joshua Colp authored
      This change adds a few things to facilitate stream topology changing:
      
      1. Control frame types have been added for use by the channel driver
      to notify the application that the channel wants to change the stream
      topology or that a stream topology change has been accepted. They are
      also used by the indicate interface to the channel that the application
      uses to indicate it wants to do the same.
      
      2. Legacy behavior has been adopted in ast_read() such that if a
      channel requests a stream topology change it is denied automatically
      and the current stream topology is preserved if the application is
      not capable of handling streams.
      
      Tests have also been written which confirm the multistream and
      non-multistream behavior.
      
      ASTERISK-26839
      
      Change-Id: Ia68ef22bca8e8457265ca4f0f9de600cbcc10bc9
      3ed05bad
  5. Jan 23, 2017
    • Lorenzo Miniero's avatar
      media: Add experimental support for RTCP feedback. · 1061539b
      Lorenzo Miniero authored
      This change adds experimental support for providing RTCP
      feedback information to codec modules so they can dynamically
      change themselves based on conditions.
      
      ASTERISK-26584
      
      Change-Id: Ifd6aa77fb4a7ff546c6025900fc2baf332c31857
      1061539b
  6. Oct 27, 2016
    • Corey Farrell's avatar
      Remove ASTERISK_REGISTER_FILE. · a6e5bae3
      Corey Farrell authored
      ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
      all traces of it.
      
      Previously exported symbols removed:
      * __ast_register_file
      * __ast_unregister_file
      * ast_complete_source_filename
      
      This also removes the mtx_prof static variable that was declared when
      MTX_PROFILE was enabled.  This variable was only used in lock.c so it
      is now initialized in that file only.
      
      ASTERISK-26480 #close
      
      Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
      a6e5bae3
  7. Apr 13, 2015
    • Matt Jordan's avatar
      git migration: Refactor the ASTERISK_FILE_VERSION macro · 4a582616
      Matt Jordan authored
      Git does not support the ability to replace a token with a version
      string during check-in. While it does have support for replacing a
      token on clone, this is somewhat sub-optimal: the token is replaced
      with the object hash, which is not particularly easy for human
      consumption. What's more, in practice, the source file version was often
      not terribly useful. Generally, when triaging bugs, the overall version
      of Asterisk is far more useful than an individual SVN version of a file. As a
      result, this patch removes Asterisk's support for showing source file
      versions.
      
      Specifically, it does the following:
      
      * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
        remove passing the version in with the macro. Other facilities
        than 'core show file version' make use of the file names, such as
        setting a debug level only on a specific file. As such, the act of
        registering source files with the Asterisk core still has use. The
        macro rename now reflects the new macro purpose.
      
      * main/asterisk:
        - Refactor the file_version structure to reflect that it no longer
          tracks a version field.
        - Remove the "core show file version" CLI command. Without the file
          version, it is no longer useful.
        - Remove the ast_file_version_find function. The file version is no
          longer tracked.
        - Rename ast_register_file_version/ast_unregister_file_version to
          ast_register_file/ast_unregister_file, respectively.
      
      * main/manager: Remove value from the Version key of the ModuleCheck
        Action. The actual key itself has not been removed, as doing so would
        absolutely constitute a backwards incompatible change. However, since
        the file version is no longer tracked, there is no need to attempt to
        include it in the Version key.
      
      * UPGRADE: Add notes for:
        - Modification to the ModuleCheck AMI Action
        - Removal of the "core show file version" CLI command
      
      Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
      4a582616
  8. Oct 03, 2014
  9. Jul 28, 2014
  10. Jul 25, 2014
  11. Jul 20, 2014
  12. May 09, 2014
  13. Mar 27, 2014
  14. Mar 17, 2014
    • Mark Michelson's avatar
      Fix stuck channel in ARI through the introduction of synchronous bridge actions. · d44aefee
      Mark Michelson authored
      Playing back a file to a channel in an ARI bridge would attempt to wait until
      the playback concluded before returning. The method used involved signaling the
      waiting thread in the ARI custom playback function.
      
      The problem with this is that there were some corner cases that were not accounted for:
      * If a bridge channel could not be found, then we never would attempt the playback but
        would still attempt to wait for the playback to complete.
      * If the bridge playfile action failed to queue, we would still attempt to wait for the
        playback to complete.
      * If the bridge playfile action were queued but some circumstance caused the playback
        not to occur (the bridge dies, the channel is removed from the bridge), then we would
        never be notified.
      
      The solution to this is to move the waiting logic into the bridge code. A new bridge
      API function is added to queue a synchronous action on a bridge. The waiting thread
      is notified when the queued frame has been freed, either due to an error occurring
      or due to successful playback. As a failsafe, the waiting thread has a 10 minute
      timeout just in case there is a frame leak somewhere.
      
      Review: https://reviewboard.asterisk.org/r/3338
      ........
      
      Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d44aefee
  15. Aug 06, 2013
    • David M. Lee's avatar
      ARI: Add recording controls · c7908487
      David M. Lee authored
      This patch implements the controls from ARI recordings. The controls
      are:
      
       * DELETE /recordings/live/{recordingName} - stop recording and
         discard it
       * POST /recordings/live/{recordingName}/stop - stop recording
       * POST /recordings/live/{recordingName}/pause - pause recording
       * POST /recordings/live/{recordingName}/unpause - resume recording
       * POST /recordings/live/{recordingName}/mute - mute recording (record
         silence to the file)
       * POST /recordings/live/{recordingName}/unmute - unmute recording.
      
      Since this underlying functionality did not already exist, is was
      added to app.c by a set of control frames, similar to how playback
      control works. The pause/mute control frames are toggles, even though
      the ARI controls are idempotent, to be consistent with the playback
      control frames.
      
      (closes issue ASTERISK-22181)
      Review: https://reviewboard.asterisk.org/r/2697/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c7908487
  16. May 21, 2013
  17. Jan 31, 2013
  18. Jan 22, 2013
    • Matthew Jordan's avatar
      Add ControlPlayback manager action · 7d9871b3
      Matthew Jordan authored
      This patch adds the capability for asynchronous manipulation of audio being
      played back to a channel though a new AMI action "ControlPlayback". The
      ControlPlayback action supports a number of operations, the availability of
      which depend on the application being used to send audio to the channel.
      When the audio playback was initiated using the ControlPlayback application
      or CONTROL STREAM FILE AGI command, the audio can be paused, stopped,
      restarted, reversed, or skipped forward. When initiated by other mechanisms
      (such as the Playback application), the audio can be stopped, reversed, or
      skipped forward.
      
      Review: https://reviewboard.asterisk.org/r/2265/
      
      (closes issue ASTERISK-20882)
      Reported by: mjordan
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7d9871b3
  19. May 14, 2012
    • Kinsey Moore's avatar
      Commit framework for HANGUPCAUSE (replacement for SIP_CAUSE) · b5a6de76
      Kinsey Moore authored
      This is the starting point for the Asterisk 11: Who Hung Up work and provides
      a framework which will allow channel drivers to report the types of hangup
      cause information available in SIP_CAUSE without incurring the overhead of the
      MASTER_CHANNEL dialplan function. The initial implementation only includes
      cause generation for chan_sip and does not include cause code translation
      utilities.
      
      This change deprecates SIP_CAUSE and replaces its method of reporting cause
      codes with the new framework. This change also deprecates the 'storesipcause'
      option in sip.conf.
      
      Review: https://reviewboard.asterisk.org/r/1822/
      (Closes issue SWP-4221)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b5a6de76
  20. Jan 09, 2012
    • Terry Wilson's avatar
      Replace direct access to channel name with accessor functions · 04da92c3
      Terry Wilson authored
      There are many benefits to making the ast_channel an opaque handle, from
      increasing maintainability to presenting ways to kill masquerades. This patch
      kicks things off by taking things a field at a time, renaming the field to
      '__do_not_use_${fieldname}' and then writing setters/getters and converting the
      existing code to using them. When all fields are done, we can move ast_channel
      to a C file from channel.h and lop off the '__do_not_use_'.
      
      This patch sets up main/channel_interal_api.c to be the only file that actually
      accesses the ast_channel's fields directly. The intent would be for any API
      functions in channel.c to use the accessor functions. No more monkeying around
      with channel internals. We should use our own APIs.
      
      The interesting changes in this patch are the addition of
      channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
      channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
      use accessor functions when ast_channel is really opaque), and some re-working
      of the way channel iterators/callbacks are handled so as to avoid creating fake
      ast_channels on the stack to pass in matching data by directly accessing fields
      (since "name" is a stringfield and the fake channel doesn't init the
      stringfields, you can't use the ast_channel_name_set() function). I went with
      ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
      setter.
      
      The majority of the grunt-work for this change was done by writing a semantic
      patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
      
      Review: https://reviewboard.asterisk.org/r/1655/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      04da92c3
  21. Sep 16, 2011
  22. Sep 09, 2011
    • Matthew Jordan's avatar
      Merged revisions 335078 via svnmerge from · 8b5ba33f
      Matthew Jordan authored
      https://origsvn.digium.com/svn/asterisk/branches/10
      
      ................
        r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines
        
        Merged revisions 335064 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.8
        
        ........
          r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines
          
          Updated SIP 484 handling; added Incomplete control frame
          
          When a SIP phone uses the dial application and receives a 484 Address 
          Incomplete response, if overlapped dialing is enabled for SIP, then
          the 484 Address Incomplete is forwarded back to the SIP phone and the
          HANGUPCAUSE channel variable is set to 28.  Previously, the Incomplete
          application dialplan logic was automatically triggered; now, explicit
          dialplan usage of the application is required.
          
          Additionally, this patch adds a new AST_CONTOL_FRAME type called
          AST_CONTROL_INCOMPLETE.  If a channel driver receives this control frame,
          it is an indication that the dialplan expects more digits back from the
          device.  If the device supports overlap dialing it should attempt to 
          notify the device that the dialplan is waiting for more digits; otherwise,
          it can handle the frame in a manner appropriate to the channel driver.
          
          (closes issue ASTERISK-17288)
          Reported by: Mikael Carlsson
          Tested by: Matthew Jordan
          
          Review: https://reviewboard.asterisk.org/r/1416/
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8b5ba33f
  23. Jul 14, 2011
  24. Feb 07, 2011
  25. Feb 03, 2011
  26. Sep 20, 2010
    • David Vossel's avatar
      Merged revisions 287647 via svnmerge from · 2f3dee23
      David Vossel authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
        
        Addition of the FrameHook API (AKA AwesomeHooks)
        
        So far all our tools for viewing and manipulating media streams
        within Asterisk have been entirely focused on audio.  That made
        sense then, but is not scalable now.  The FrameHook API lets us
        tap into and manipulate _ANY_ type of media or signaling passed
        on a channel present today or in the future.  This tool is a step
        in the direction of expanding Asterisk's boundaries and will help
        generate some rather interesting applications in the future.
        
        In addition to the FrameHook API, a simple dialplan function
        exercising the api has been included as well.  This function
        is called FRAME_TRACE().  FRAME_TRACE() allows for the internal
        ast_frames read and written to a channel to be output.  Filters
        can be placed on this function to debug only certain types of frames.
        This function could be thought of as an internal way of doing
        ast_frame packet captures.
        
        Review: https://reviewboard.asterisk.org/r/925/
      ........
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2f3dee23
Loading