Skip to content
Snippets Groups Projects
Select Git revision
  • dev_fxs_no_wb
  • lk_channel_joined_bridge_indication
  • 14600-wenpeng
  • asterisk_rdkb
  • fix_transport_fallback_at_dns_failure
  • fix_fallback
  • 14666_fxs_no_wideband_codec
  • fix_srv_records
  • wenpeng-test-250121
  • wenpeng-registration-test
  • fix_deadlock_in_bridge_peer_functions
  • devel default protected
  • securesip_pjproject_part1
  • PJ_Example_Review
  • fix_re_register_authorization_header
  • fix_internal_calls_auth
  • fix_internal_calls
  • Secure_SIPtelephony_part1
  • SIPtelephony_DECT_syslog
  • syslog_develop_phase1
  • 22.0.0-pre1
  • 21.4.2
  • 20.9.2
  • 18.24.2
  • certified-20.7-cert2
  • certified-18.9-cert11
  • 21.4.1
  • 20.9.1
  • 18.24.1
  • 21.4.0
  • 20.9.0
  • 18.24.0
  • certified-20.7-cert1
  • certified-18.9-cert10
  • 21.4.0-rc1
  • 20.9.0-rc1
  • 18.24.0-rc1
  • 21.3.1
  • 20.8.1
  • 18.23.1
40 results
Search by author
  • Any Author
  • Adam Porteous Adam Porteous adam.porteous
  • Alex Hopkins Alex Hopkins 59hopper
  • Amin Ben Romdhane Amin Ben Romdhane amin.benromdhane
  • Andreas Gnau Andreas Gnau AGnau
  • Andrej Kucharik Andrej Kucharik andrej.kucharik
  • Andrii Pypa Andrii Pypa andrii.pypa
  • Anjan Chanda Anjan Chanda anjancx
  • Balalakshmi Arunachalam Rajendran Balalakshmi Arunachalam Rajendran arbala
  • Benjamin Larsson Benjamin Larsson benjamin
  • Charles Foster Charles Foster charles.foster_bt.com
  • Dariusz Iwanoczko Dariusz Iwanoczko dariusz.iwanoczko
  • Divya Chandrasekaran Divya Chandrasekaran divya.c
  • Dominic Lake Dominic Lake dominic.lake
  • Elena Vengerova Elena Vengerova helen
  • Erik Karlsson Erik Karlsson erik.karlsson
  • Filip Matusiak Filip Matusiak filmat
  • Filip Strelec Filip Strelec filip.strelec
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
20 authors
  1. Nov 21, 2013
  3. Nov 15, 2013
  5. Nov 14, 2013
  7. Nov 12, 2013
  9. Nov 11, 2013
  11. Nov 08, 2013
    • Kevin Harwell's avatar
      app_dahdiras: Use waitpid instead of wait4. · 2564ed26
      Kevin Harwell authored 
      Several places in the code were using wait4 while other places were using
waitpid.  This change makes all places use waitpid in order to make things
more consistent and since the 'rusage' object passed in/out of wait4 was
never used.

(closes issue ASTERISK-22557)
Reported by: YvesGael
Patches:
     asterisk-11.5.1-wait4.patch uploaded by hurdman (license 6537)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2564ed26
  13. Nov 06, 2013
    • Kevin Harwell's avatar
      app_queue: crash if first agent is "busy" · cdfbc02d
      Kevin Harwell authored 
      If the first agent/member (via CLI "queue show") in a queue is "busy" (dnd,
circuit busy, etc...) and no agents answered then app_queue would crash.
This occurred because while the calling of agent(s) remained valid the channel
on "busy" agent would be set to NULL and then later dereferenced upon a second
"rna" function call.  The original intention of the code is to have only valid
"call attempt" objects (channels != NULL) checked while attempting to call
agent(s).  It does this by building a "call_next" list of valid "call attempt"
objects.  In the case of the "busy" agent subsequent builds of the valid "call
attempt" list would sometimes include (the case mentioned above) an invalid
"call attempt" object.

The fix was to make sure the "call attempt" list was appropriately built on
every iteration.  A NULL sanity check was also added at the original offending
spot of the crash just in case another one slipped by somehow.

(closes issue ASTERISK-22644)
Reported by: Marco Signorini
Review: https://reviewboard.asterisk.org/r/2983/
........

Merged revisions 402517 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402518 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cdfbc02d
  15. Nov 02, 2013
  17. Nov 01, 2013
  19. Oct 24, 2013
  21. Oct 22, 2013
  23. Oct 18, 2013
    • Richard Mudgett's avatar
      Add channel lock protection around translation path setup. · 057d105c
      Richard Mudgett authored 
      Most callers of ast_channel_make_compatible() happen before the channels
enter a two party bridge.  With the new bridging framework, two party
bridging technologies may also call ast_channel_make_compatible() when
there is more than one thread involved with the two channels.

* Added channel lock protection in set_format() and
ast_channel_make_compatible_helper() when dealing with the channel's
native formats while setting up a translation path.

* Fixed best_src_fmt and best_dst_fmt usage consistency in
ast_channel_make_compatible_helper().  The call to
ast_translator_best_choice() got them backwards.

* Updated some callers of ast_channel_make_compatible() and the function
documentation.  There is actually a difference between the two channels
passed in.

* Fixed the deadlock potential in res_fax.c dealing with
ast_channel_make_compatible().  The deadlock potential was already there
anyway because res_fax called ast_channel_make_compatible() with chan
locked.

(closes issue ASTERISK-22542)
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/2915/
........

Merged revisions 401239 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      057d105c
  25. Oct 16, 2013
  27. Oct 08, 2013
  29. Oct 07, 2013
  31. Oct 06, 2013
  33. Oct 03, 2013
  35. Oct 02, 2013
  37. Sep 30, 2013
    • David M. Lee's avatar
      Multiple revisions 399887,400138,400178,400180-400181 · 2de42c2a
      David M. Lee authored 
      ........
  r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
  
  Minor performance bump by not allocate manager variable struct if we don't need it
........
  r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
  
  Stasis performance improvements
  
  This patch addresses several performance problems that were found in
  the initial performance testing of Asterisk 12.
  
  The Stasis dispatch object was allocated as an AO2 object, even though
  it has a very confined lifecycle. This was replaced with a straight
  ast_malloc().
  
  The Stasis message router was spending an inordinate amount of time
  searching hash tables. In this case, most of our routers had 6 or
  fewer routes in them to begin with. This was replaced with an array
  that's searched linearly for the route.
  
  We more heavily rely on AO2 objects in Asterisk 12, and the memset()
  in ao2_ref() actually became noticeable on the profile. This was
  #ifdef'ed to only run when AO2_DEBUG was enabled.
  
  After being misled by an erroneous comment in taskprocessor.c during
  profiling, the wrong comment was removed.
  
  Review: https://reviewboard.asterisk.org/r/2873/
........
  r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
  
  Taskprocessor optimization; switch Stasis to use taskprocessors
  
  This patch optimizes taskprocessor to use a semaphore for signaling,
  which the OS can do a better job at managing contention and waiting
  that we can with a mutex and condition.
  
  The taskprocessor execution was also slightly optimized to reduce the
  number of locks taken.
  
  The only observable difference in the taskprocessor implementation is
  that when the final reference to the taskprocessor goes away, it will
  execute all tasks to completion instead of discarding the unexecuted
  tasks.
  
  For systems where unnamed semaphores are not supported, a really
  simple semaphore implementation is provided. (Which gives identical
  performance as the original taskprocessor implementation).
  
  The way we ended up implementing Stasis caused the threadpool to be a
  burden instead of a boost to performance. This was switched to just
  use taskprocessors directly for subscriptions.
  
  Review: https://reviewboard.asterisk.org/r/2881/
........
  r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
  
  Optimize how Stasis forwards are dispatched
  
  This patch optimizes how forwards are dispatched in Stasis.
  
  Originally, forwards were dispatched as subscriptions that are invoked
  on the publishing thread. This did not account for the vast number of
  forwards we would end up having in the system, and the amount of work it
  would take to walk though the forward subscriptions.
  
  This patch modifies Stasis so that rather than walking the tree of
  forwards on every dispatch, when forwards and subscriptions are changed,
  the subscriber list for every topic in the tree is changed.
  
  This has a couple of benefits. First, this reduces the workload of
  dispatching messages. It also reduces contention when dispatching to
  different topics that happen to forward to the same aggregation topic
  (as happens with all of the channel, bridge and endpoint topics).
  
  Since forwards are no longer subscriptions, the bulk of this patch is
  simply changing stasis_subscription objects to stasis_forward objects
  (which, admittedly, I should have done in the first place.)
  
  Since this required me to yet again put in a growing array, I finally
  abstracted that out into a set of ast_vector macros in
  asterisk/vector.h.
  
  Review: https://reviewboard.asterisk.org/r/2883/
........
  r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
  
  Remove dispatch object allocation from Stasis publishing
  
  While looking for areas for performance improvement, I realized that an
  unused feature in Stasis was negatively impacting performance.
  
  When a message is sent to a subscriber, a dispatch object is allocated
  for the dispatch, containing the topic the message was published to, the
  subscriber the message is being sent to, and the message itself.
  
  The topic is actually unused by any subscriber in Asterisk today. And
  the subscriber is associated with the taskprocessor the message is being
  dispatched to.
  
  First, this patch removes the unused topic parameter from Stasis
  subscription callbacks.
  
  Second, this patch introduces the concept of taskprocessor local data,
  data that may be set on a taskprocessor and provided along with the data
  pointer when a task is pushed using the ast_taskprocessor_push_local()
  call. This allows the task to have both data specific to that
  taskprocessor, in addition to data specific to that invocation.
  
  With those two changes, the dispatch object can be removed completely,
  and the message is simply refcounted and sent directly to the
  taskprocessor.
  
  Review: https://reviewboard.asterisk.org/r/2884/
........

Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2de42c2a
  39. Sep 28, 2013
    • Matthew Jordan's avatar
      app_queue: Make manager events tolerant of Local channel shenanigans · ccab0f27
      Matthew Jordan authored 
      app_queue currently attempts to handle Local channel optimizations in an effort
to provide accurate information in Stasis messages (and their corresponding
AMI events) as well as the Queue log. Sometimes, however, things don't go as
planned.

Consider the following scenario:
 SIP/foo <-> L;1 <-> L;2 <-> SIP/agent

SIP/agent answers, triggering a Local channel optimization. app_queue will
normally do the following:
 * Listen for the Local optimization events and update our agent accordingly
   to SIP/agent in the queue log and messages
 * When we get a hangup, publish the AgentComplete event based on our
   information (SIP/foo and SIP/agent)

However, as with all things that depend on sanity from something as capricious
as Local channels, things can go wrong:
 (1) SIP/agent immediately hangs up upon answering. This triggers a race
     condition between termination messages coming from SIP/agent and the
     ongoing Local channel optimization messages. (Note that this can also
     occur with SIP/foo)
 (2) In a race condition, Asterisk can (rarely) deliver the hangup messages
     prior to the Local channel optimization.

In that case, the messages *may* arrive to app_queue in the following order:
 * Hangup SIP/Agent
 * Hangup SIP/foo
 * Optimize L;1/L;2
 * Hangup L;2
 * Hangup L;1

When app_queue receives the hangup of the agent or the caller, it will attempt
to publish the AgentComplete event. However, it now has a problem - it thinks
its agent is the ;1 side of the Local channel, as it never received the
optimization event. At the same time, that channel is already gone. This
results in getting NULL from the Stasis cache. What's more, we can't really
wait for the optimization message, as we are currently handling the hangup
of the channel that the optimization event would tell us to use.

This patch modifies the behavior in app_queue such that, since we still have a
lot of pertinent queue information (interface, queue name, etc.), we now raise
the event with what information we know. The channels involved now may or may
not be present. Users will still at least get the "AgentComplete" event, which
"completes" the known Agent information.

Review: https://reviewboard.asterisk.org/r/2878/

(closes issue ASTERISK-22507)
Reported by: Richard Mudgett
........

Merged revisions 400060 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ccab0f27
  41. Sep 27, 2013
  43. Sep 26, 2013
  45. Sep 24, 2013
  47. Sep 21, 2013
  49. Sep 17, 2013
    • Kevin Harwell's avatar
      Confbridge: empty conference not being torn down · b1db2df8
      Kevin Harwell authored 
      Confbridge would not properly tear down an empty conference bridge when all
users were kicked via end_marked=yes and at least one user was also set to
wait_marked.  This occurred because while end_marked users were being kicked
and at least one was also set to wait_marked then the leave wait_marked handler
would be called on that user, but there would be no waiting user (still
considered active).  The waiting users would decrement and now be negative.  The
conference would remain, but be put into an inactive state.  The solution was
to move from the active list to the wait list, those users with wait_marked set
right before kicking.  This allows both the active and wait users to decrement
correctly and the confbridge to tear down properly.

A crashed also occurred when trying to list the specific conference from the CLI.
This happened because the conference specified was invalid.  Since the
conference properly tears down now there is no way to reference it thus
alleviating the crash as well.

(closes issue ASTERISK-21859)
Reported by: Chris Gentle
Review: https://reviewboard.asterisk.org/r/2848/
........

Merged revisions 399222 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 399225 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b1db2df8
  51. Sep 16, 2013
  53. Sep 13, 2013
  55. Sep 12, 2013