Skip to content
Snippets Groups Projects
Select Git revision
  • dev_fxs_no_wb
  • 14600-wenpeng
  • lk_channel_joined_bridge_indication
  • 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. Mar 27, 2015
  3. Mar 26, 2015
  5. Mar 25, 2015
  7. Mar 24, 2015
    • Richard Mudgett's avatar
      chan_pjsip: Add "rpid_immediate" option to prevent unnecessary "180 Ringing" messages. · b1e9552b
      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/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b1e9552b
  9. Mar 22, 2015
  11. Mar 20, 2015
  13. Mar 19, 2015
  15. Mar 18, 2015
  17. Mar 17, 2015
  19. Mar 14, 2015
  21. Mar 13, 2015
  23. Mar 12, 2015
    • Matthew Jordan's avatar
      main/audiohook: Update internal sample rate on reads · b9fd61f2
      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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b9fd61f2