https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289099 | bbryant | 2010-09-28 14:18:02 -0400 (Tue, 28 Sep 2010) | 28 lines
Merged revisions 289095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289095 | bbryant | 2010-09-28 14:14:19 -0400 (Tue, 28 Sep 2010) | 21 lines
Merged revisions 289094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289094 | bbryant | 2010-09-28 14:10:19 -0400 (Tue, 28 Sep 2010) | 14 lines
Fixes an issue with the Newchannel AMI event during the Masquerading process.
Fixes an issue with the Newchannel AMI event during the Masquerading process,
where no Newchannel AMI event was generated for the psuedo channel used during
the masquerading process.
(closes issue #17987)
Reported by: RadicAlish
Patches:
newchannel.patch.txt uploaded by RadicAlish (license 1122)
Tested by: RadicAlish
Review: https://reviewboard.asterisk.org/r/937/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r288079 | rmudgett | 2010-09-21 15:29:51 -0500 (Tue, 21 Sep 2010) | 2 lines
Protect channel access in CONNECTED_LINE and REDIRECTING interception macro launch code.
........
r288080 | rmudgett | 2010-09-21 15:29:59 -0500 (Tue, 21 Sep 2010) | 8 lines
Simplify locking code for REDIRECTING interception macro when forwarding a call.
Simplified the locking code by using a local copy of the redirecting party
information in app_dial.c:do_forward() and app_queue.c:wait_for_answer()
for launching the REDIRECTING interception macro when a call is forwarded.
Reduced the lock time of the 'o->chan' and 'in' channels.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines
ast_channel_masquerade: Avoid recursive masquerades.
Check all 4 combinations of (original/clonechan) * (masq/masqr).
Initially original->masq and clonechan->masqr were only checked.
It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.
(closes issue #16057;#17363)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287661 | alecdavis | 2010-09-21 10:21:50 +1200 (Tue, 21 Sep 2010) | 14 lines
ast_do_masquerade. Keep channels ao2_container locked while unlink and linking channels.
Previously, Masquerade would unlock 'original' and 'clonechan' and allow another masq thread to run.
End result would be corrupted memory, and the frequent report 'Bad Magic Number'.
(closes issue #17801,#17710)
Reported by: notthematrix
Patches:
Based on bug17801.diff1.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/928
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
Addition of the FrameHook API (AKA AwesomeHooks)
So far all our tools for viewing and manipulating media streams
within Asterisk have been entirely focused on audio. That made
sense then, but is not scalable now. The FrameHook API lets us
tap into and manipulate _ANY_ type of media or signaling passed
on a channel present today or in the future. This tool is a step
in the direction of expanding Asterisk's boundaries and will help
generate some rather interesting applications in the future.
In addition to the FrameHook API, a simple dialplan function
exercising the api has been included as well. This function
is called FRAME_TRACE(). FRAME_TRACE() allows for the internal
ast_frames read and written to a channel to be output. Filters
can be placed on this function to debug only certain types of frames.
This function could be thought of as an internal way of doing
ast_frame packet captures.
Review: https://reviewboard.asterisk.org/r/925/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286682 | mnicholson | 2010-09-14 13:04:21 -0500 (Tue, 14 Sep 2010) | 21 lines
Merged revisions 286681 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286681 | mnicholson | 2010-09-14 13:02:24 -0500 (Tue, 14 Sep 2010) | 14 lines
Merged revisions 286679 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286679 | mnicholson | 2010-09-14 13:00:01 -0500 (Tue, 14 Sep 2010) | 7 lines
Only drop duplicate answer frames if the channel is bridged.
Back in r3710 ast_read() was modified to drop answer frames on channels that were in the UP state. This modification prevented bridges that were up before the answer from being broken and reestablished by an ANSWER control frame. That change also prevents pickup of channels called from the ast_dial framework from working properly. The ast_dial framework expects to see an ANSWER frame after dialing and the pickup code queues one but ast_read() drops it. This new change only drops ANSWER frames when the channel is bridged, allowing the answer queued by the pickup code to properly pass through ast_read() on to the ast_dial framework.
ABE-2473
(related to issue #2342)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282468 | twilson | 2010-08-16 12:53:44 -0500 (Mon, 16 Aug 2010) | 30 lines
Merged revisions 282467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r282467 | twilson | 2010-08-16 12:32:01 -0500 (Mon, 16 Aug 2010) | 23 lines
Merged revisions 282430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281913 | jpeeler | 2010-08-11 22:03:37 -0500 (Wed, 11 Aug 2010) | 34 lines
Merged revisions 281912 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281912 | jpeeler | 2010-08-11 22:01:38 -0500 (Wed, 11 Aug 2010) | 27 lines
Merged revisions 281911 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) | 20 lines
Ensure SSRC is changed when media source is changed to resolve audio delay.
This change causes the SSRC to change right before the channels are bridged,
which is what used to happen. It seems that fixes were made to attempt limiting
SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC
with this change.
There are two other control frames sent in ast_channel_bridge that probably
should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave
this change up to the discretion of resolving issue #17007.
For reference - old review implementing new control frame SRCCHANGE:
https://reviewboard.asterisk.org/r/540
(closes issue #17404)
Reported by: sdolloff
Patches:
bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines
Merged revisions 280306 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines
Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported.
ABE-2229
Review: https://reviewboard.asterisk.org/r/813/
........
Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r279949 | dvossel | 2010-07-27 15:57:00 -0500 (Tue, 27 Jul 2010) | 31 lines
Merged revisions 279946 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r279946 | dvossel | 2010-07-27 15:54:32 -0500 (Tue, 27 Jul 2010) | 24 lines
Merged revisions 279945 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines
remove empty audiohook write list on channel
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
(closes issue #17630)
Reported by: manvirr
Review: https://reviewboard.asterisk.org/r/799/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r278618 | mmichelson | 2010-07-22 09:55:04 -0500 (Thu, 22 Jul 2010) | 13 lines
Allow PLC to function properly when channels use SLIN for audio.
If a channel involved in a bridge was using SLIN audio, then translation
paths were not guaranteed to be set up properly since in all likelihood
the number of translation steps was only 1.
This patch enforces the transcode_via_slin behavior if transcode_via_slin
or generic_plc is enabled and one of the formats to make compatible is
SLIN.
AST-352
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277247 | mnicholson | 2010-07-16 12:29:57 -0500 (Fri, 16 Jul 2010) | 4 lines
For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation.
AST-362
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277250 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
(closes issue #17372)
Reported by: tech_admin
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines
Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The handling of the control subclass AST_CONTROL_READ_ACTION frame leaked
connected line string memory in __ast_read().
Also in __ast_read() the frame type switch should not have had a case for
AST_CONTROL_READ_ACTION. AST_CONTROL_READ_ACTION is not a frame type.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
__ast_channel_alloc_ap() has several points in the initialization of a new
channel structure where it could fail. Since the channel structure is now
an ao2 object, the destructor callback needs to be able to handle clean up
when the structure setup is incomplete.
Problems corrected:
1) Failing to setup the alertpipe would not unreference the structure but
free it directly. Doing this to an ao2_object is very bad.
2) File descriptors need to be initialized to -1 before a construction
failure could occur so the destructor will not close unopened descriptors.
3) The destructor needs to check that the string field has been
initialized before using any string field values. Crashes expected.
4) The destructor should not notify devstate if the device name is empty.
It is a waste of cycles and a couple ERROR log messages are generated.
Review: https://reviewboard.asterisk.org/r/675/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@264997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261093 | tilghman | 2010-05-04 18:36:53 -0500 (Tue, 04 May 2010) | 7 lines
Protect against overflow, when calculating how long to wait for a frame.
(closes issue #17128)
Reported by: under
Patches:
d.diff uploaded by under (license 914)
........
r261094 | tilghman | 2010-05-04 18:47:08 -0500 (Tue, 04 May 2010) | 2 lines
Add a tiny corner case to the previous commit
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines
Prevent Newchannel manager events for dummy channels.
No Newchannel manager event will be fired for channels that are
allocated to not match a registered technology type. Thus bogus
channels allocated solely for variable substitution or CDR
operations do not result in a Newchannel event.
(closes issue #16957)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/601
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193391 | mnicholson | 2009-05-08 16:01:25 -0500 (Fri, 08 May 2009) | 8 lines
Set the proper disposition on originated calls.
(closes issue #14167)
Reported by: jpt
Patches:
call-file-missing-cdr2.diff uploaded by mnicholson (license 96)
Tested by: dlotina, rmartinez, mnicholson
........
r258670 | mnicholson | 2010-04-22 16:49:07 -0500 (Thu, 22 Apr 2010) | 11 lines
Fix broken CDR behavior.
This change allows a CDR record previously marked with disposition ANSWERED to be set as BUSY or NO ANSWER.
Additionally this change partially reverts r235635 and does not set the AST_CDR_FLAG_ORIGINATED flag on CDRs generated from ast_call(). To preserve proper CDR behavior, the AST_CDR_FLAG_DIALED flag is now cleared from all brige CDRs in ast_bridge_call().
(closes issue #16797)
Reported by: VarnishedOtter
Tested by: mnicholson
........
(closes issue #16222)
Reported by: telles
Tested by: mnicholson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This module implements an abstraction for retrieving and exporting
asterisk data.
Developed by:
Brett Bryant <brettbryant@gmail.com>
Eliel C. Sardanons (LU1ALY) <eliels@gmail.com>
For the Google Summer of code 2009 Project.
Documentation can be found in doxygen format and inside the
header include/asterisk/data.h
Review: https://reviewboard.asterisk.org/r/275/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Matthew Nicholson
Brett Bryant
Terry Wilson
Alec L Davis
David Vossel
Jason Parker
Jeff Peeler
Russell Bryant
Mark Michelson
Eliel C. Sardanons
Tilghman Lesher