Skip to content
Snippets Groups Projects
  1. May 06, 2015
  2. May 03, 2015
  3. Apr 30, 2015
    • Corey Farrell's avatar
      Sample Configs: Fix syntax error in pjsip.conf · 6b208d8c
      Corey Farrell authored
      The sample pjsip.conf has a few comment lines that are missing the
      semicolons at the start of the comment, causing the config to fail
      load.
      
      Change-Id: I776a38c916a7df7ee3e072fd0b21dbf4cc457352
      6b208d8c
    • Richard Mudgett's avatar
      chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option. · 03c51cf5
      Richard Mudgett authored
      Some telco switches occasionally ignore ISDN RESTART requests.  The fix
      for ASTERISK-19608 added an escape clause for B channels in the restarting
      state if the telco ignores a RESTART request.  If the telco fails to
      acknowledge the RESTART then Asterisk will assume the telco acknowledged
      the RESTART on the second call attempt requesting the B channel by the
      telco.  The escape clause is good for dealing with RESTART requests in
      general but it does cause the next call for the restarting B channel to be
      rejected if the telco insists the call must go on that B channel.
      
      chan_dahdi doesn't really need to issue a RESTART request in response to
      receiving a cause 44 (Requested channel not available) code.  Sending the
      RESTART in such a situation is not required (nor prohibited) by the
      standards.  I think chan_dahdi does this for historical reasons to deal
      with buggy peers to get channels unstuck in a similar fashion as the
      chan_dahdi.conf resetinterval option.
      
      * Add the chan_dahdi.conf force_restart_unavailable_chans compatability
      option that when disabled will prevent chan_dahdi from trying to RESTART
      the channel in response to a cause 44 code.
      
      ASTERISK-25034 #close
      Reported by: Richard Mudgett
      
      Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
      03c51cf5
  4. Apr 29, 2015
  5. Apr 27, 2015
    • Corey Farrell's avatar
      Astobj2: Allow reference debugging to be enabled/disabled by config. · 5c1d07ba
      Corey Farrell authored
      * The REF_DEBUG compiler flag no longer has any effect on code that uses
        Astobj2.  It is used to determine if reference debugging is enabled by
        default.  Reference debugging can be enabled or disabled in asterisk.conf.
      * Caller information is provided in logger errors for ao2 bad magic numbers.
      * Optimizes AO2 by merging internal functions with the public counterpart.
        This was possible now that we no longer require a dual ABI.
      
      ASTERISK-24974 #close
      Reported by: Corey Farrell
      
      Change-Id: Icf3552721fe999365ba8a8cf00a965aa6b897cc1
      5c1d07ba
    • Rodrigo Ramírez Norambuena's avatar
      cdr/cdr_odbc.c: Added to record new columns add on CDR 1.8 Asterisk Version · 358080e8
      Rodrigo Ramírez Norambuena authored
      Add new column to INSERT new columns added in cdr 1.8 version. The columns are:
       * peeraccount
       * linkedid
       * sequence
      This feature is configurable in cdr_odbc.conf using a new configuration
      option, 'newcdrcolumns'.
      
      ASTERISK-24976 #close
      
      Change-Id: Ibe0c7540a88305c6012786f438a0813ad8b19127
      358080e8
  6. Apr 16, 2015
    • George Joseph's avatar
      res_pjsip: Add global option to limit the maximum time for initial qualifies · c6ed6816
      George Joseph authored
      
      Currently when Asterisk starts initial qualifies of contacts are spread out
      randomly between 0 and qualify_timeout to prevent network and system overload.
      If a contact's qualify_frequency is 5 minutes however, that contact may be
      unavailable to accept calls for the entire 5 minutes after startup.  So while
      staggering the initial qualifies is a good idea, basing the time on
      qualify_timeout could leave contacts unavailable for too long.
      
      This patch adds a new global parameter "max_initial_qualify_time" that sets the
      maximum time for the initial qualifies.  This way you could make sure that all
      your contacts are initialy, randomly qualified within say 30 seconds but still
      have the contact's ongoing qualifies at a 5 minute interval.
      
      If max_initial_qualify_time is > 0, the formula is initial_interval =
      min(max_initial_interval, qualify_timeout * random().  If not set,
      qualify_timeout is used.
      
      The default is "0" (disabled).
      
      ASTERISK-24863 #close
      
      Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
      Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      c6ed6816
    • George Joseph's avatar
      pjsip_options: Add qualify_timeout processing and eventing · 51886c68
      George Joseph authored
      This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
      discussion at
      http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
      
      
      
      The basic issues are that changes in contact status don't cause events to be
      emitted for the associated endpoint.  Only dynamic contact add/delete actions
      update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
      which is a long time.
      
      This patch makes use of the new transaction timeout feature in r4585 and
      provides the following capabilities...
      
      1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
      user to specify the maximum time in milliseconds to wait for a response to an
      OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
      marked unavailable.
      
      2.  Contact status changes are now propagated up to the endpoint as follows...
      When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
      all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
      existing endpoint events are generated appropriately.
      
      ASTERISK-24863 #close
      
      Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
      Tested-by: Dmitriy Serov
      Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      51886c68
  7. Apr 10, 2015
  8. Apr 08, 2015
  9. Mar 27, 2015
  10. Mar 25, 2015
  11. Mar 24, 2015
    • Richard Mudgett's avatar
      chan_pjsip: Add "rpid_immediate" option to prevent unnecessary "180 Ringing" messages. · 4c2fc5b8
      Richard Mudgett authored
      Incoming PJSIP call legs that have not been answered yet send unnecessary
      "180 Ringing" or "183 Progress" messages every time a connected line
      update happens.  If the outgoing channel is also PJSIP then the incoming
      channel will always send a "180 Ringing" or "183 Progress" message when
      the outgoing channel sends the INVITE.
      
      Consequences of these unnecessary messages:
      
      * The caller can start hearing ringback before the far end even gets the
      call.
      
      * Many phones tend to grab the first connected line information and refuse
      to update the display if it changes.  The first information is not likely
      to be correct if the call goes to an endpoint not under the control of the
      first Asterisk box.
      
      When connected line first went into Asterisk in v1.8, chan_sip received an
      undocumented option "rpid_immediate" that defaults to disabled.  When
      enabled, the option immediately passes connected line update information
      to the caller in "180 Ringing" or "183 Progress" messages as described
      above.
      
      * Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
      "183 Progress" messages.  The default is "no" to disable sending the
      unnecessary messages.
      
      ASTERISK-24781 #close
      Reported by: Richard Mudgett
      
      Review: https://reviewboard.asterisk.org/r/4473/
      ........
      
      Merged revisions 433338 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4c2fc5b8
  12. Mar 17, 2015
  13. Mar 14, 2015
  14. Mar 13, 2015
  15. Mar 09, 2015
  16. Feb 25, 2015
  17. Feb 15, 2015
  18. Feb 10, 2015
    • George Joseph's avatar
      res_pjsip_config_wizard: Add ability to auto-create hints. · 49161d8d
      George Joseph authored
      Looking at the Super Awesome Company sample reminded me that creating hints is 
      just plain gruntwork.  So you can now have the pjsip conifg wizard auto-create 
      them for you.
      
      Specifying 'hint_exten' in the wizard will create 
      'exten => <hint_exten>,hint/PJSIP/<wizard_id>'
      in whatever is specified for 'hint_context'.
      
      Specifying 'hint_application' in the wizard will create
      'exten => <hint_exten>,1,<hint_application>'
      in whatever is specified for 'hint_context'.
      
      The default for 'hint_context' is the endpoint's context.
      There's no default for 'hint_application'.  If not specified, no app is added.
      There's no default for 'hint_exten'.  If not specified, neither the hint itself 
      nor the application will be created.
      
      Some may think this is the slippery slope to users.conf but hints are a basic 
      necessity for phones unlike voicemail, manager, etc that users.conf creates.
      
      Tested-by: George Joseph
      Review: https://reviewboard.asterisk.org/r/4383/
      ........
      
      Merged revisions 431643 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      49161d8d
  19. Jan 30, 2015
  20. Jan 20, 2015
  21. Jan 16, 2015
  22. Jan 12, 2015
  23. Jan 09, 2015
  24. Dec 24, 2014
  25. Dec 22, 2014
    • Matthew Jordan's avatar
      app_confbridge: Add the ability to pass options/command to MixMonitor · b79a4a46
      Matthew Jordan authored
      This patch adds the ability to pass options and a command to MixMontor when
      recording a conference using ConfBridge.
      
      New options are -
      
      * record_options: Options to MixMontor, eg: m(), W() etc.
      * record_command: The command to execute when recording is over.
      * record_file_timestamp: Append the start time to the file name.
      
      These options can also be used with the CONFBRIDGE function, e.g.,
      Set(CONFBRIDGE(bridge,record_command)=/path/to/command ^{MIXMONITOR_FILENAME}))
      
      Review: https://reviewboard.asterisk.org/r/4023
      
      ASTERISK-24351 #close
      Reported by: Gareth Palmer
      patches:
        record_command-428838.patch uploaded by Gareth Palmer (License 5169)
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b79a4a46
  26. Dec 15, 2014
  27. Dec 01, 2014
    • Matthew Jordan's avatar
      main/stasis: Allow subscriptions to use a threadpool for message delivery · 1106e8fd
      Matthew Jordan authored
      Prior to this patch, all Stasis subscriptions would receive a dedicated
      thread for servicing published messages. In contrast, prior to r400178
      (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
      shared a thread pool. It was discovered during some initial work on Stasis
      that, for a low subscription count with high message throughput, the
      threadpool was not as performant as simply having a dedicated thread per
      subscriber.
      
      For situations where a subscriber receives a substantial number of messages
      and is always present, the model of having a dedicated thread per subscriber
      makes sense. While we still have plenty of subscriptions that would follow
      this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
      the following two categories:
      * Large number of subscriptions, specifically those tied to endpoints/peers.
      * Low number of messages. Some subscriptions exist specifically to coordinate
        a single message - the subscription is created, a message is published, the
        delivery is synchronized, and the subscription is destroyed.
      In both of the latter two cases, creating a dedicated thread is wasteful (and
      in the case of a large number of peers/endpoints, harmful). In those cases,
      having shared delivery threads is far more performant.
      
      This patch adds the ability of a subscriber to Stasis to choose whether or not
      their messages are dispatched on a dedicated thread or on a threadpool. The
      threadpool is configurable through stasis.conf.
      
      Review: https://reviewboard.asterisk.org/r/4193
      
      ASTERISK-24533 #close
      Reported by: xrobau
      Tested by: xrobau
      ........
      
      Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1106e8fd
  28. Nov 21, 2014
  29. Nov 19, 2014
  30. Nov 17, 2014
  31. Nov 15, 2014
  32. Nov 14, 2014
  33. Nov 05, 2014
  34. Nov 04, 2014
  35. Nov 03, 2014
Loading