| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9@271295 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9@271270 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc3@269747 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc3@269351 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Shoutouts to Qwell and The Nubs.
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc3@269349 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc2@268577 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Our software isn't released. It escapes!
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc2@268576 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266657 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266656 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266655 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266653 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266651 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266650 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.6.2.9-rc1@266649 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r266592 | tilghman | 2010-06-01 10:18:59 -0500 (Tue, 01 Jun 2010) | 18 lines
Merged revisions 266585 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266585 | tilghman | 2010-06-01 10:17:46 -0500 (Tue, 01 Jun 2010) | 11 lines
Prevent CLI prompt from distorting output of lines shorter than the prompt.
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266598 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17395)
Reported by: pabelanger
Patches:
res_agi.c.patch uploaded by pabelanger (license 224)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266570 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r266438 | tilghman | 2010-05-29 23:44:28 -0500 (Sat, 29 May 2010) | 9 lines
Merged revisions 266437 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266437 | tilghman | 2010-05-29 23:43:28 -0500 (Sat, 29 May 2010) | 2 lines
Reverting patch and reopening issue #16784, as patch breaks color display.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266439 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266337 | tilghman | 2010-05-28 15:53:04 -0500 (Fri, 28 May 2010) | 1 line
Only report swap on platforms which can examine those statistics
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266338 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines
fixes crash when creation of UDPTL fails
(closes issue #17264)
Reported by: falves11
Patches:
issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
Tested by: falves11
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266293 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r266146 | tilghman | 2010-05-26 16:17:46 -0500 (Wed, 26 May 2010) | 21 lines
Merged revisions 266142 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266142 | tilghman | 2010-05-26 16:11:44 -0500 (Wed, 26 May 2010) | 14 lines
Use sigaction for signals which should persist past the initial trigger, not signal.
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266154 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266006 | dvossel | 2010-05-26 13:32:51 -0500 (Wed, 26 May 2010) | 8 lines
fixes failed SIP Directed pickup resulting in dead channel
(closes issue #17339)
Reported by: one47
Patches:
sip_magic_pickup2 uploaded by one47 (license 23)
Tested by: one47, dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266007 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r265923 | tilghman | 2010-05-26 11:23:28 -0500 (Wed, 26 May 2010) | 14 lines
Merged revisions 265910 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r265910 | tilghman | 2010-05-26 11:21:00 -0500 (Wed, 26 May 2010) | 7 lines
Not finding rows in the DB does not rise to the level of a warning.
(closes issue #17062)
Reported by: drookie
Patches:
20100525__issue17062.diff.txt uploaded by tilghman (license 14)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265959 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265894 | tilghman | 2010-05-26 11:14:48 -0500 (Wed, 26 May 2010) | 8 lines
Construct socket name, according to the Postgres docs, and document as such.
(closes issue #17392)
Reported by: dps
Patches:
20100525__issue17392.diff.txt uploaded by tilghman (license 14)
Tested by: dps
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265895 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265842 | mmichelson | 2010-05-26 09:41:55 -0500 (Wed, 26 May 2010) | 9 lines
Re-enable "always" option for videosupport option in sip.conf.
(closes issue #17016)
Reported by: twilson
Patches:
17016.patch uploaded by mmichelson (license 60)
Tested by: devmod
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265747 | tilghman | 2010-05-25 19:29:40 -0500 (Tue, 25 May 2010) | 8 lines
Use configure to determine the prefixes and include directories properly.
This ensures cross-platform compatibility, even among Linux distributions,
which don't always put headers in the same place.
(closes issue #17391)
Reported by: loloski
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265748 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines
Properly use peer's outboundproxy for outbound REGISTERs.
The logic used in transmit_register to get the outboundproxy for a peer
was flawed since this value would be overridden shortly afterwards when
create_addr was called.
In addition, this also fixes some logic used when parsing users.conf so
that the peer name is placed in the internally-generated register string
so that an outboundproxy set in the Asterisk GUI will be used for outbound
REGISTERs.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265699 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue 0017394)
Reported by: aragon
Patches:
half_buffer_fix.diff uploaded by dvossel (license 671)
Tested by: aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265615 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r265611 | mnicholson | 2010-05-25 12:00:11 -0500 (Tue, 25 May 2010) | 15 lines
Merged revisions 265610 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r265610 | mnicholson | 2010-05-25 11:48:19 -0500 (Tue, 25 May 2010) | 8 lines
Don't mark the cdr records of unanswered queue calls with "NOANSWER". This restores the behavior prior to r258670.
(closes issue #17334)
Reported by: jvandal
Patches:
queue-cdr-fixes1.diff uploaded by mnicholson (license 96)
Tested by: aragon, jvandal
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265612 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265521 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265451 | mmichelson | 2010-05-24 17:05:15 -0500 (Mon, 24 May 2010) | 8 lines
Print openh323 log to the Asterisk console.
(closes issue #17109)
Reported by: under
Patches:
logstream.diff uploaded by under (license 914)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265452 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265449 | mmichelson | 2010-05-24 16:44:30 -0500 (Mon, 24 May 2010) | 11 lines
Allow type=user SIP endpoints to be loaded properly from realtime.
(closes issue #16021)
Reported by: Guggemand
Patches:
realtime-type-fix.patch uploaded by Guggemand (license 897)
(altered by me slightly to avoid ref leaks)
Tested by: Guggemand
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265273 | dvossel | 2010-05-24 11:10:09 -0500 (Mon, 24 May 2010) | 2 lines
fixes segfault when using generic plc
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265364 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
........
r265317 | twilson | 2010-05-24 13:21:20 -0500 (Mon, 24 May 2010) | 15 lines
Calendaring support for Exchange Server 2007+ via EWS
This commit adds support for calendaring with Exchange Server 2007+ via
Exchange Web Services. Full write support and for querying attendees. Many
thanks to Jan Kaláb for the feature.
(closes issue #17022)
Reported by: pitel
Patches:
res_calendar_ews.c uploaded by pitel (license 1008)
Tested by: pitel, twilson
Review: https://reviewboard.asterisk.org/r/557/
Review: https://reviewboard.asterisk.org/r/668/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265319 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265316 | tilghman | 2010-05-24 13:19:08 -0500 (Mon, 24 May 2010) | 7 lines
On systems with a LOT of RAM, a signed integer sometimes printed negative.
(closes issue #16837)
Reported by: jlpedrosa
Patches:
20100504__issue16837.diff.txt uploaded by tilghman (license 14)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265318 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
From reviewboard:
This review request is for the patch on issue 17081.
A user reported that he saw increasing numbers of allocations stemming
from app_queue.c when he would run the "queue show" CLI command. The
user reported that he was using approximately 40 realtime queues and
as he ran the CLI command more and more, the memory usage would shoot up.
As it turns out, there was a memory leak and a separate usage of memory
that, while not really a leak, was very irresponsible.
Both memory problems can be attributed to the function init_queue(). When
the "queue show" command is run, all realtime queues have the init_queue()
function called on the in-memory queue. The idea is to place the queue in
its default state and then overwrite options specified in the realtime backend
as we read them.
The first problem, the memory leak, had to do with the fact that the string
field for the name of the first periodic announcement file was being re-created
every time init_queue was called. This patch corrects the behavior by only
calling ast_str_create if the memory has not already been allocated.
The other problem is a bit more complicated. The majority of the strings
in the call_queue structure were changed to use the ast_string_fields API
for 1.6.0 and beyond. init_queue resets all string fields on the queue to
their default values. Then, later in the realtime queue loading process,
these string fields are set to their configured values.
For those unfamiliar with string fields, frequent resizing of a string like
this is not what the string fields API is designed for. The result of this
constant resizing is that as the queue gets loaded, eventually space for
the string runs out and so a new memory pool, at twice the size of the
previously allocated one, is created for the string fields. The reporter
of issue 17081 wrote a script that ran the "queue show" CLI command 2100
times. By the end, each of his 40 queues was taking about a megabyte of
memory apiece just for their string fields.
My fix for this problem is to revert the call_queue structure from using
string fields. In my patch here, I have moved the queue back to using
fixed-sized buffers. I ran the script provided by the reporter of 17081
and determined that I no longer saw the steadily-increasing memory usage
that I had seen before applying the patch.
(closes issue #17081)
Reported by: wliegel
Patches:
17081v2.patch uploaded by mmichelson (license 60)
Tested by: wliegel, mmichelson
Review: https://reviewboard.asterisk.org/r/651/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265172 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r265090 | mmichelson | 2010-05-21 16:08:51 -0500 (Fri, 21 May 2010) | 15 lines
Merged revisions 265089 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r265089 | mmichelson | 2010-05-21 15:59:14 -0500 (Fri, 21 May 2010) | 8 lines
Don't hang up on a queue caller if the file we attempt to play does not exist.
This also fixes a documentation mistake in file.h that made my original attempt
to correct this problem not work correctly.
(closes issue #17061)
Reported by: RoadKill
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265091 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265087 | mmichelson | 2010-05-21 15:38:14 -0500 (Fri, 21 May 2010) | 7 lines
Be sure to set the sin_family on the proxy when allocating.
(closes issue #17157)
Reported by: stuarth
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r265000 | mmichelson | 2010-05-21 11:54:21 -0500 (Fri, 21 May 2010) | 9 lines
Merged revisions 264999 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264999 | mmichelson | 2010-05-21 11:53:53 -0500 (Fri, 21 May 2010) | 3 lines
Fix grammatical error in comment.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265001 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r264997 | mmichelson | 2010-05-21 11:44:27 -0500 (Fri, 21 May 2010) | 38 lines
Merged revisions 264996 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines
Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264998 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r264828 | rmudgett | 2010-05-20 18:29:43 -0500 (Thu, 20 May 2010) | 13 lines
Merged revisions 264820 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264820 | rmudgett | 2010-05-20 18:23:21 -0500 (Thu, 20 May 2010) | 6 lines
ast_callerid_parse() had a path that left name uninitialized.
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264829 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264779 | tilghman | 2010-05-20 17:23:32 -0500 (Thu, 20 May 2010) | 8 lines
Let ExtensionState resolve dynamic hints.
(closes issue #16623)
Reported by: tilghman
Patches:
20100116__issue16623.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264783 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264752 | tilghman | 2010-05-20 16:28:53 -0500 (Thu, 20 May 2010) | 7 lines
Error message fix.
(closes issue #17356)
Reported by: kenner
Patches:
app_stack.c.diff uploaded by kenner (license 1040)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264753 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264453 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264400 | dvossel | 2010-05-19 15:30:33 -0500 (Wed, 19 May 2010) | 11 lines
fixes infinite loop during udptl.c's decode_open_type
When decode_length returns the length there is a check to see if that
length is negative, if so the decode loop breaks as this means the
limit has been reached. The problem here is that length is an
unsigned int, so length can never be negative. This resulted in
an infinite loop.
(issue #17352)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264405 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264379 | mnicholson | 2010-05-19 15:26:27 -0500 (Wed, 19 May 2010) | 4 lines
Cast an unsigned int to a signed int when comparing it with 0.
(AST-377)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264388 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r264335 | mnicholson | 2010-05-19 15:02:57 -0500 (Wed, 19 May 2010) | 12 lines
Merged revisions 264334 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264334 | mnicholson | 2010-05-19 15:01:38 -0500 (Wed, 19 May 2010) | 5 lines
Set quieted flag when receiving a dtmf tone during playback in speechbackground.
(closes issue #16966)
Reported by: asackheim
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264336 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash in check_rtp_timeout
During deadlock avoidance the sip dialog pvt is locked and
unlocked. When this occurs we have no guarantee the pvt's owner
is still valid. We were trying to access the pvt's owner after
this without checking to see if it still existed first.
(closes issue #17271)
Reported by: under
Patches:
check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264332 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r264249 | tilghman | 2010-05-19 12:48:31 -0500 (Wed, 19 May 2010) | 24 lines
Merged revisions 264248 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264248 | tilghman | 2010-05-19 12:41:29 -0500 (Wed, 19 May 2010) | 17 lines
Internal timing is now on by default, if you're using DAHDI 2.3 or above.
The reason for ensuring DAHDI 2.3 or above is that this version ensures that
a timer is always available, whereas in previous versions, it was possible
for DAHDI to be loaded, but have no drivers to actually generate timing. If
internal_timing was turned on in this circumstance, a complete lack of audio
would result. This is the reason why internal_timing was not on by default.
However, now that DAHDI ensures the availability of a timer, there is no
reason for this setting to be off (and in fact, it solves a great many initial
user problems).
(closes issue #15932)
Reported by: dimas
Patches:
20100519__issue15932.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264250 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264204 | tilghman | 2010-05-19 11:42:20 -0500 (Wed, 19 May 2010) | 9 lines
Keep track of digit duration, when we're decoding inband to pass DTMF frames.
(closes issue #17235)
Reported by: frawd
Patches:
new_dtmf_dsp_len.patch uploaded by frawd (license 610)
20100518__issue17235.diff.txt uploaded by tilghman (license 14)
Tested by: frawd
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264205 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash during dtmf
During the processing of Cisco dtmf the dtmf samples were
not being calculated correctly. In an attempt to determine
what sample rate was being used, a NULL frame was processed
which caused a crash. This patch resolves this.
(closes issue #17248)
Reported by: falves11
Patches:
issue_17248.diff uploaded by dvossel (license 671)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264115 f38db490-d61c-443f-a65b-d21fe96a405b
|
