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: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@264249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
users expect them to work.
'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.
This patch changes this functionality to be module-name based instead
of file-name based.
To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.
Review: https://reviewboard.asterisk.org/r/574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: erousseau
This was a reasonable enhancement request, which was
easy to implement. Since it's an enhancement, it
could only be applied to trunk.
Basically, for accounting where "initiated" seconds
are billed for, if the microseconds field on the end
time is greater than the microseconds field for the
answer time, add one second to the billsec field.
The implementation was requested by erousseau, and
I've implemented it as requested. I've updated the
CHANGES, the cdr.conf.sample, and the .h files
accordingly, to accept and set a flag for the
corresponding new option. cdr.c adds in the extra
second based on the usec fields if the option is
set. Tested, seems to be working fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133169 | mmichelson | 2008-07-23 14:39:47 -0500 (Wed, 23 Jul 2008) | 12 lines
As suggested by seanbright, the PSEUDO_CHAN_LEN in
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and off for new installations. This includes the translation from pipes to commas
for pbx_realtime and the EXEC command for AGI, as well as the change to the Set
application not to support multiple variables at once.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: bbryant
Patches:
20070720__core_debug_by_file.patch uploaded by bbryant (license 36)
(with some modifications by me)
Tested by: russell, bbryant
This set of changes introduces the ability to set the core debug or verbose
levels on a per-file basis. Interestingly enough, in 1.4, you have the ability
to set core debug for a single file, but that functionality was accidentally
lost in the conversion of the CLI commands to the new format.
This patch improves upon what was in 1.4 by letting you set it for more than 1
file, and by also supporting verbose.
*** Janitor Project ***
This patch also introduces a new macro, ast_verb(), which is similar
to ast_debug(). Setting the per file verbose value only works for messages that
use this macro. Converting existing uses of ast_verbose() can be done like:
if (option_debug > 2)
ast_verbose(VERBOSE_PREFIX_3 "Something useful\n");
...
ast_verb(3, "Something useful\n");
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add missing option to options.h
- Add missing variables to asterisk.h
- Move manager version to manager.h include file
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@63030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r48998 | kpfleming | 2006-12-27 15:08:30 -0600 (Wed, 27 Dec 2006) | 3 lines
move extern declaration for this option to a header file where it belongs
provide an initial value for 'languageprefix' option, instead of relying on randomness to provide a useful value
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48999 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Fix some breakage I introduced a while ago that made the timestamps option
not functional for CLI verbose output.
- Remove the use of the timestamps option for log output, since it was not
functional.
- clarify text referring to the timestamps option so that it is clear that it
only applies to CLI verbose output
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
output to remove consoles. The prototypes added to logger.h still need
doxygen documentation, as well.
- Add the new command line option to the man page
- make the mute option a flag instead of an int since it is only a binary
option
- remove useless extern keywords for prototypes added to logger.h
- rename ast_console_mute() to ast_console_toggle_mute() since that is what
it actually does
- actually apply the mute option to newly created remote consoles instead of
only working when the CLI command is used
- don't imply the NO_FORK option if the mute command line option is provided
- place the new CLI command in the correct place in the list which has to be
in alphabetical order
- Finally, clean up a few spacing issues to conform to the coding guidelines
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@30630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
force all transcode paths to use AST_FORMAT_SLINEAR as the frames pass through the bridge (can be disabled using the 'transcode_via_sln' setting in th 'options' setting in asteris.conf)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@5376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
