Skip to content
Snippets Groups Projects
Select Git revision
  • dev_fxs_no_wb
  • asterisk_rdkb
  • fix_transport_fallback_at_dns_failure
  • 14600-wenpeng
  • 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
  • merge-asterisk-20.8.1
  • 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. Mar 14, 2015
  3. Mar 13, 2015
  5. Mar 12, 2015
    • Matthew Jordan's avatar
      main/audiohook: Update internal sample rate on reads · 38ee441e
      Matthew Jordan authored 
      When an audiohook is created (which is used by the various Spy applications
and Snoop channel in Asterisk 13+), it initially is given a sample rate of
8kHz. It is expected, however, that this rate may change based on the media
that passes through the audiohook. However, the read/write operations on the
audiohook behave very differently.

When a frame is written to the audiohook, the format of the frame is checked
against the internal sample rate. If the rate of the format does not match
the internal sample rate, the internal sample rate is updated and a new SLIN
format is chosen based on that sample rate. This works just fine.

When a frame is read, however, we do something quite different. If the format
rate matches the internal sample rate, all is fine. However, if the rates
don't match, the audiohook attempts to "fix up" the number of samples that
were requested. This can result in some seriously large number of samples
being requested from the read/write factories.

Consider the worst case - 192kHz SLIN. If we attempt to read 20ms worth of
audio produced at that rate, we'd request 3840 samples (192000 / (1000 / 20)).
However, if the audiohook is still expecting an internal sample rate of 8000,
we'll attempt to "fix up" the requested samples to:

  samples_converted = samples * (ast_format_get_sample_rate(format) /
                                 (float) audiohook->hook_internal_samp_rate);

  which is:

  92160 = 3840 * (192000 / 8000)

This results in us attempting to read 92160 samples from our factories, as
opposed to the 3840 that we actually wanted. On a 64-bit machine, this
miraculously survives - despite allocating up to two buffers of length 92160
on the stack. The 32-bit machines aren't quite so lucky. Even in the case where
this works, we will either (a) get way more samples than we wanted; or (b) get
about 3840 samples, assuming the timing is pretty good on the machine.

Either way, the calculation being performed is wrong, based on the API users
expectations.

My first inclination was to allocate the buffers on the heap. As it is,
however, there's at least two drawbacks with doing this:
(1) It's a bit complicated, as the size of the buffers may change during the
    lifetime of the audiohook (ew).
(2) The stack is faster (yay); the heap is slower (boo).

Since our calculation is flat out wrong in the first place, this patch fixes
this issue by instead updating the internal sample rate based on the format
passed into the read operation. This causes us to read the correct number of
samples, and has the added benefit of setting the audihook with the right
SLIN format.

Note that this issue was caught by the Asterisk Test Suite as a result of
r432195 in the 13 branch. Because this issue is also theoretically possible
in Asterisk 11, the change is being made here as well.

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

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

Merged revisions 432811 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      38ee441e
    • Matthew Jordan's avatar
      Add support for the clang compiler; update RAII_VAR to use BlocksRuntime · 29304d10
      Matthew Jordan authored 
      RAII_VAR, which is used extensively in Asterisk to manage reference counted
resources, uses a GCC extension to automatically invoke a cleanup function
when a variable loses scope. While this functionality is incredibly useful
and has prevented a large number of memory leaks, it also prevents Asterisk
from being compiled with clang.

This patch updates the RAII_VAR macro such that it can be compiled with clang.
It makes use of the BlocksRuntime, which allows for a closure to be created
that performs the actual cleanup.

Note that this does not attempt to address the numerous warnings that the clang
compiler catches in Asterisk.

Much thanks for this patch goes to:
* The folks on StackOverflow who asked this question and Leushenko for
  providing the answer that formed the basis of this code:
  http://stackoverflow.com/questions/24959440/rewrite-gcc-cleanup-macro-with-nested-function-for-clang
* Diederik de Groot, who has been extremely patient in working on getting this
  patch into Asterisk.

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

ASTERISK-24133
ASTERISK-23666
ASTERISK-20399
ASTERISK-20850 #close
Reported by: Diederik de Groot
patches:
  RAII_CLANG.patch uploaded by Diederik de Groot (License 6600)
........

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

Merged revisions 432808 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      29304d10
  7. Mar 11, 2015
  9. Mar 10, 2015
  11. Mar 09, 2015
  13. Mar 08, 2015
  15. Mar 06, 2015
  17. Mar 05, 2015
  19. Mar 04, 2015
    • Matthew Jordan's avatar
      translate: Prevent invalid memory accesses on fast shutdown · 41ba8fd7
      Matthew Jordan authored 
      When a 'core restart now' or 'core stop now' is executed and a channel is
currently in a media operation, the translator matrix can be destroyed while a
channel is currently blocked on getting the best translation choice
(see ast_translator_best_choice). When the channel gets the mutex, the
translation matrix now has invalid memory, and Asterisk crashes.

This patch does two things:
(1) We now only clean up the translation matrix on a graceful shutdown. In that
    case, there are no channels, and so there is no risk of this occurring.
(2) We also now set the __matrix and __indextable to NULL. In some initial
    backtraces when this occurred, it looked as if there was a memory corruption
    occurring, and it wasn't until we determined that something had restarted
    Asterisk that the issue became clear. By setting these to NULL on shutdown,
    it becomes a bit easier to determine why a crash is occurring.

Note that we could litter the code with NULL checks on the __matrix, but the
act of making the translation matrix cleaned up on shutdown should preclude
this issue from occurring in the first place, and this part of the code needs
to be as fast as possible.

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

Merged revisions 432453 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      41ba8fd7
  21. Mar 02, 2015
  23. Feb 27, 2015
  25. Feb 26, 2015
  27. Feb 25, 2015
  29. Feb 24, 2015
    • Richard Mudgett's avatar
      config.h: Use real parameter names for ast_variable_new() define. · 57525c3c
      Richard Mudgett authored 
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      57525c3c
    • Matthew Jordan's avatar
      channels/chan_sip: Fix crash when transmitting packet after thread shutdown · 8574c4d1
      Matthew Jordan authored 
      When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.

This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.

ASTERISK-24800 #close
Reported by: JoshE
........

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

Merged revisions 432199 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8574c4d1
    • Matthew Jordan's avatar
      ARI/PJSIP: Apply requesting channel's format cap to created channels · a528dfc9
      Matthew Jordan authored 
      This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
  structure of SLIN and apply it to the new channel being created. This was
  originally done when the PBX core was used to create the channel, as there
  was a condition where a newly created channel could be created without any
  formats. Unfortunately, now that the Dial API is being used, this has two
  drawbacks:
  (a) SLIN, while it will ensure audio will flows, can cause a lot of
      needless transcodings to occur, particularly when a Local channel is
      created to the dialplan. When no format capabilities are available, the
      Dial API handles this better by handing all audio formats to the requsted
      channels. As such, we defer to that API to provide the format
      capabilities.
  (b) If a channel (requester) is causing this channel to be created, we
      currently don't use its format capabilities as we are passing in our own.
      However, the Dial API will use the requester channel's formats if none
      are passed into it, and the requester channel exists and has format
      capabilities. This is the "best" scenario, as it is the most likely to
      create a media path that minimizes transcoding.
  Fixing this simply entails removing the providing of the format capabilities
  structure to the Dial API.

* chan_pjsip: Rather than blindly picking the first format in the format
  capability structure - which actually *can* be a video or text format - we
  select an audio format, and only pick the first format if that fails. That
  minimizes the weird scenario where we attempt to transcode between video/audio.

* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
  Since ast_request already limits us down to one format capability once the
  format capabilities are passed along, there's no reason to squelch it here.

* channel: Fixed a comment. The reason we have to minimize our requested
  format capabilities down to a single format is due to Asterisk's inability
  to convey the format to be used back "up" a channel chain. Consider the
  following:

    PJSIP/A => L;1 <=> L;2 => PJSIP/B
    g,u,a     g,u,a    g,u,a      u

  That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
  PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
  channel has inherited those format capabilities down the line; PJSIP/B
  supports only ulaw. According to these format capabilities, ulaw is
  acceptable and should be selected across all the channels, and no
  transcoding should occur. However, there is no way to convey this: when L;2
  and PJSIP/B are put into a bridge, we will select ulaw, but that is not
  conveyed to PJSIP/A and L;1. Thus, we end up with:

    PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
      g          g   X   u        u

  Which causes g722 to be written to PJSIP/B.

  Even if we can convey the 'ulaw' choice back up the chain (which through
  some severe hacking in Local channels was accomplished), such that the chain
  looks like:

    PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
      u          u       u         u

  We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
  with only 'ulaw'. This results in all the channel structures being set up
  correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
  apart.

  There's a lot of difficulty just in setting this up, as there are numerous
  race conditions in the act of bridging, and no clean mechanism to pass the
  selected format backwards down an established channel chain. As such, the
  best that can be done at this point in time is clarifying the comment.

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

ASTERISK-24812 #close
Reported by: Matt Jordan
........

Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a528dfc9
    • Kevin Harwell's avatar
      bridge_softmix: G.729 codec license held · 91733b5d
      Kevin Harwell authored 
      When more than one call using the same codec type enters into a softmix bridge
and no audio is present for a channel the bridge optimizes the out frame by
using the same one for all channels with the same codec type. Unfortunately,
when that number (channels with same codec type) dropped to <= 1 the codec
was not dereferenced. At least not until all parties left the bridge. Thus in
the case of G.729 the license was not released. This patch ensures that the
codec is dereferenced immediately when the optimization no longer applies.

ASTERISK-24797 #close
Reported by: Luke Hulsey
Review: https://reviewboard.asterisk.org/r/4429/
........

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

Merged revisions 432175 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      91733b5d