| Age | Commit message (Collapse) | Author |
|---|
|
http://bamboo.asterisk.org/download/AST-TRUNKFREEBSD/build_logs/AST-TRUNKFREEBSD-187.log
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269495 | russell | 2010-06-09 17:18:37 -0500 (Wed, 09 Jun 2010) | 2 lines
Don't stop Asterisk if chan_oss fails to register 'Console' (due to another channel driver already claiming it).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17336)
Reported by: snuffy
Patches:
doxygen-fixes1.diff uploaded by snuffy (license 35)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268969 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Also, optimize the allocation of mailboxes to avoid additional memory structures.
(closes issue #16320)
Reported by: Marquis
Patches:
20100525__issue16320.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
is expressed as a double, the last value would not also need to be a double.
(closes issue #15807)
Reported by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268495 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
option tweak
Changes.
1. RFC 3261 states in section 17.1.2.2 and 17.1.1.2 that retransmission
timers should initially be set to timer T1. T1 by default is 500ms.
Asterisk was starting the retransmission timers at T1*2 which shouldn't
cause any problems, but is not RFC compliant.
2. RFC 3261 states in section 17.1.2.2 that for a non-INVITE client transaction,
if the retransmit timer fires while in the proceeding state that
the request must be retransmitted. Asterisk currently ack's
requests for both INVITE and non-INVITE transactions when a
1XX response is received, this patch changes this for non-INVITE requests.
3. The 'registerattempts' option in sip.conf is supposed to set
how many registry attempts will be made before giving up. When
this option is set to 1, I would expect only one registry attempt
to be made before stopping because of a failure, but instead two are
made. In my opinion this is not expected behavior. This option does
not indicate that these are re-attempts. The logic behind this option
has been changed to only attempt registers the exact number of times
this option is set to. If this option is 0, it still continues to
re-attempt the registration forever.
Review: https://reviewboard.asterisk.org/r/687/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The problem would manifest itself if your dialplan matching could accept
more digits to match than were actually dialed. The time out waiting for
overlap digits disconnected the call instead of matching any accumulated
digits to the dialplan.
Accidental conversion of a break out of loop as a break out of switch.
(closes issue #17401)
Reported by: avalentin
Patches:
issue17401_digit_timeout.patch uploaded by rmudgett (license 664)
Tested by: avalentin, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From issue ABE-2247. RFC 3261 compliance for sections 13.2.24 and 17.1.1.2.
Review: https://reviewboard.asterisk.org/r/692/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add the ability to report waiting messages to ISDN endpoints (phones).
Relevant specification: EN 300 650 and EN 300 745
Review: https://reviewboard.asterisk.org/r/599/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267399 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
After some debugging, the random chan_h323 build failures appear to be due
to complications introduced by some chan_h323 specific build stuff getting
triggered during a clean. Simplify this by moving the h323 clean commands
down into channels/makefile.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add the ability to report malicious callers as an AMI event in the call
event class.
Relevant specification: EN 300 180
Review: https://reviewboard.asterisk.org/r/576/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Two struct sockaddr_ins are created when applying directmedia
host access rules. The addresses of these are passed to the RTP
engine to be filled in. However, the RTP engine inspects the fields
of the structs before actually taking action. This inspection caused
valgrind to be a bit unhappy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267097 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
|
|
This feature generates AMI events in the new aoc event class from the
events passed up by libpri.
Review: https://reviewboard.asterisk.org/r/537/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(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: https://origsvn.digium.com/svn/asterisk/trunk@266292 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch breaks up every part of the sip registry string during
config parsing and removes all parsing from transmit_register().
Thanks to Nick_Lewis for contributing this patch!
(closes issue #14331)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domparse.patch uploaded by Nick Lewis (license 657)
chan_sip.c.patch uploaded by Nick Lewis (license 657)
chan_sip.c.domainparse3.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse4.patch uploaded by Nick Lewis (license 657)
chan_sip.c-domparse5.patch uploaded by Nick Lewis (license 657)
nicklewispatch.diff uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
Review: https://reviewboard.asterisk.org/r/628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17339)
Reported by: one47
Patches:
sip_magic_pickup2 uploaded by one47 (license 23)
Tested by: one47, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17016)
Reported by: twilson
Patches:
17016.patch uploaded by mmichelson (license 60)
Tested by: devmod
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@265698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17109)
Reported by: under
Patches:
logstream.diff uploaded by under (license 914)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(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: https://origsvn.digium.com/svn/asterisk/trunk@265449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The decoding of the replace_id did not need to be broken
up in this instance. This was brought to my attention
again because it caused a segfault when the from or to
tags were not present in the "Replaces" header.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265366 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #17157)
Reported by: stuarth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The same code was repeated in lots of different places, so I made a utility
fuction for it. This should make the merge in the v6-new branch easier.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
directmediapermit/directmediadeny support to restrict which peers can do
directmedia based on ip address. In some networks not all phones are fully
routed, i.e. not all phones can ping each other. This patch adds a way to
restrict directmedia for certain peers between certain networks.
(closes issue #16645)
Reported by: raarts
Patches:
directmediapermit.patch uploaded by raarts (license 937)
Tested by: raarts
Review: https://reviewboard.asterisk.org/r/467/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264626 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
|
|
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: https://origsvn.digium.com/svn/asterisk/trunk@264331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Thanks to Richard for pointing this out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263810 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
|
|
Very unfortunate things happen if we add an iax_frame
to the frame queue and let go of the lock before scheduling
the frame's transmit... There is a race condition that
exists where the frame can be removed from the frame_queue
and freed before the transmit is scheduled if we do not
hold on to that lock. This results in a freed frame
being scheduled for transmit later.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Thanks to Raymond Burke for pointing it out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262897 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Must do a deep copy of the cc_params in duplicate_pseudo(). Otherwise,
when the duplicate pseudo channel is destroyed, it frees the original
pseudo channel cc_params. The original pseudo channel is then left with a
dangling pointer for when the next duplicated pseudo channel is created.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
