https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260437 | jpeeler | 2010-04-30 17:36:49 -0500 (Fri, 30 Apr 2010) | 18 lines
Merged revisions 260434 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260434 | jpeeler | 2010-04-30 17:22:46 -0500 (Fri, 30 Apr 2010) | 11 lines
Ensure channel state is not incorrectly set in the case of a very early answer.
The needringing bit was being read in dahdi_read after answering thereby
setting the state to ringing from up. This clears needringing upon answering
so that is no longer possible.
(closes issue #17067)
Reported by: tzafrir
Patches:
needringing.diff uploaded by tzafrir (license 46)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
Merged revisions 260195 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
DTMF CallerID detection problems.
The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.
The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.
For shorter numbers, the timeout may have been too short. I increased it
from 2 seconds to 4 seconds. Four seconds is a typical time between rings
for many countries.
(closes issue #16460)
Reported by: sum
Patches:
issue16460.patch uploaded by rmudgett (license 664)
issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett
Review: https://reviewboard.asterisk.org/r/634/
JIRA SWP-562
JIRA AST-334
JIRA SWP-901
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines
Merged revisions 259858 via svnmerge from
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/branches/1.6.2@259899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259307 | rmudgett | 2010-04-27 13:29:33 -0500 (Tue, 27 Apr 2010) | 21 lines
Merged revisions 259270 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259270 | rmudgett | 2010-04-27 13:14:54 -0500 (Tue, 27 Apr 2010) | 14 lines
hidecalleridname parameter in chan_dahdi.conf
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r258305 | dvossel | 2010-04-21 13:13:36 -0500 (Wed, 21 Apr 2010) | 12 lines
fixes issue with double "sip:" in header field
This is a clear mistake in logic. Future discussions
about how to avoid having to handle uri's like this
should take place in the future, but this fix needs
to go in for now.
(closes issue #15847)
Reported by: ebroad
Patches:
doublesip.patch uploaded by ebroad (license 878)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@258314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r257493 | tilghman | 2010-04-15 15:30:15 -0500 (Thu, 15 Apr 2010) | 20 lines
Merged revisions 257467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
Don't recreate peer, when responding to a repeated deregistration attempt.
When a reply to a deregistration is lost in transmit, the client retries the
deregistration. Previously, this would cause a realtime/autocreate peer to be
loaded back into memory, after it had already been correctly purged. Instead,
we just want to resend the reply without loading the peer.
(closes issue #16908)
Reported by: kkm
Patches:
20100412__issue16908.diff.txt uploaded by tilghman (license 14)
Tested by: kkm
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bug is exposed if MFC/R2 support is built into asterisk (i.e.,
openr2.h is present in the include path). Code that unconditionally
clears the CallerID name and number is included.
Also fixed a malformed if test in mkintf() added by issue 15883.
Converted the if statement to a switch statement for clarity.
Regression of the issue 15883 fix.
(closes issue #16968)
Reported by: grecco
Patches:
issue16968.patch uploaded by rmudgett (license 664)
(closes issue #16747)
Reported by: viniciusfontes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@256368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
Merged revisions 250480 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
Make sure to clear red alarm after polarity reversal.
From the issue:
The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
a red alarm on a dahdi / TDM400P connected channel. This is because the line
uses voltage tests (battery loss) and polarity reversal. The polarity reversal
causes chan_dahdi to initiate v23 CallerID processing but during this the event
DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
(closes issue #14163)
Reported by: jedi98
Patches:
chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
Tested by: mattbrown, Chainsaw, mikeeccleston
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@250484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r250395 | dvossel | 2010-03-03 12:03:19 -0600 (Wed, 03 Mar 2010) | 22 lines
Merged revisions 250394 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250394 | dvossel | 2010-03-03 12:02:27 -0600 (Wed, 03 Mar 2010) | 16 lines
fixes problem with duplicate TXREQ packets
When Asterisk receives an IAX2 TXREQ packet, try_transfer()
will call store_by_transfercallno() to link the chan_iax2_pvt
struct into iax_transfercallno_pvts. If a duplicate TXREQ
packet is received for the same call, the pvt struct will be
linked into iax_transfercallno_pvts multiple times. This patch
fixes this. Thanks rain for debugging this and providing a patch!
(closes issue #16904)
Reported by: rain
Patches:
iax2-double-txreq-fix.diff uploaded by rain (license 327)
Tested by: rain, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@250396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r249538 | jpeeler | 2010-03-01 11:11:31 -0600 (Mon, 01 Mar 2010) | 18 lines
Merged revisions 249536 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines
Modify queued frames from local channels to not set the other side to up
In this case, attended transfers were broken due to ast_feature_request_and_dial
detecting the channel being set to up before the answer frame could be read and
therefore failing to mark the channel as ready. This fix is a regression fix for
244785, which should continue to work properly as well.
(closes issue #16816)
Reported by: jamhed
Tested by: jamhed, corruptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.
Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.
Verified that our local TELCO also does the same.
(issue #16789)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r228798 | tilghman | 2009-11-09 01:37:52 -0600 (Mon, 09 Nov 2009) | 14 lines
Fix various problems detected with Valgrind.
* chan_console accessed pvts after deallocation.
* The module loader did not check usecount on shutdown, which led to chan_iax2
reading a timer that was already unloaded.
(closes issue #16062)
Reported by: alexanderheinz
Patches:
20091109__issue16062.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r247914 | rmudgett | 2010-02-19 11:33:33 -0600 (Fri, 19 Feb 2010) | 62 lines
Merged revisions 247910 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r247910 | rmudgett | 2010-02-19 11:18:49 -0600 (Fri, 19 Feb 2010) | 55 lines
Merged revision 247904 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r247904 | rmudgett | 2010-02-19 10:49:44 -0600 (Fri, 19 Feb 2010) | 49 lines
Make chan_misdn DTMF processing consistent with other channel technologies.
The processing of DTMF tones on the receiving side of an ISDN channel is
inconsistent with the way it is handled in other channels, especially
DAHDI analog. This causes DTMF tones sent from an ISDN phone to be
doubled at the connected party.
We are using the following 2 options of misdn.conf
1) astdtmf=yes
2) senddtmf=yes
Option one is necessary because the asterisk DSP DTMF detection is better
than mISDN's internal DSP. Not as many false positives.
Option two is necessary to transmit DTMF tones end to end when mISDN
channels are connected to SIP channels with out of band DTMF for example.
The symptom is that DTMF tones sent by an ISDN phone are doubled on the
way through asterisk when two mISDN channels are connected with a Local
channel in between or if it is bridged to an analog channel.
The doubling of DTMF tones is because DTMF is passed inband to asterisk by
the mISDN channel and passed out of band once again after the release of
the DTMF tone. Passing it inband is wrong. Neither an analog channel nor
SIP channel passes DTMF inband if configured to inband DTMF. Analog and
SIP channels filter out the DTMF tones because they use the voice frames
returned by ast_dsp_process. But chan_misdn passes the unfiltered input
voice frames instead.
To overcome one aspect of the problem, the doubling of DTMF tones when two
mISDN channels are directly bridged, someone made an 'optimization', where
in that case the DTMF tone passed out-of-band to the peer channel is not
translated to an inband tone at the transmit side. This optimization is
bad because it does not work in general. For example, analog channels or
mISDN channels when bridged through an intermediary local channel will
generate DTMF tones from out-of-band information. Also, of course, it
must not be done when there is no inband DTMF available.
This patch fixes the issue. Now chan_misdn will filter the received
inband DTMF signal the same as other channel types.
Another change included: No need to build an extra translation path
because ast_process_dsp does it if required.
Patches:
misdn-dtmf.patch
JIRA ABE-2080
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247915 | dvossel | 2010-02-19 11:40:26 -0600 (Fri, 19 Feb 2010) | 7 lines
handle_request_invite revise comment, fix coding guideline issues
I'm working with this code right now trying to analyze a deadlock.
This change is just to clean up a few things before I make a more
complex patch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247787 | tilghman | 2010-02-18 15:42:53 -0600 (Thu, 18 Feb 2010) | 17 lines
If the peer record is from realtime, it could be set to 0, due to MySQL not representing NULL well in integer columns.
NULL means the value is not specified for the column, which normally means
the driver uses whatever is the default value. However, on MySQL, placing
a NULL in either a float or integer column results in a retrieval of the 0
value. Hence, users get an errant error on load. This patch suppresses
that error and makes the value as if it was not there.
Note that this cannot be done in the realtime driver, because the lack of
difference between NULL and 0 can only be intepreted correctly by the
driver itself. If we did it in the realtime driver, then it would be
effectively impossible to set any realtime field to 0, because it would act
as if the field were unspecified and possibly take on a different value.
(closes issue #16683)
Reported by: wdoekes
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246070 | jpeeler | 2010-02-10 10:47:37 -0600 (Wed, 10 Feb 2010) | 22 lines
Change channel state on local channels for busy,answer,ring.
Previously local channels channel state never changed. This became problematic
when the state of the other side of the local channel was lost, for example
during a masquerade. Changing the state of the local channel allows for the
scenario to be detected when the channel state is set to ringing, but the peer
isn't ringing. The specific problem scenario is described in 164201. Although
this was noted on one of the issues, here is the tested dialplan verified to
work:
exten => 9700,1,Dial(Local/*9700@default&Local/0009700@default)
exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *9700,n,wait(3) ;3 works, 1 did not
exten => *9700,n,Dial(SIP/5001)
exten => 0009700,1,Wait(1) ;1 works, 3 did not
exten => 0009700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r245793 | dvossel | 2010-02-09 17:07:17 -0600 (Tue, 09 Feb 2010) | 18 lines
Merged revisions 245792 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r245792 | dvossel | 2010-02-09 16:55:38 -0600 (Tue, 09 Feb 2010) | 12 lines
Fixes iaxs and iaxsl size off by one issue.
2^15 = 32768 which is the maximum allowed iax2 callnumber.
Creating the iaxs and iaxsl array of size 32768 means the maximum
callnumber is actually out of bounds. This causes a nasty crash.
(closes issue #15997)
Reported by: exarv
Patches:
iax_fix.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245578 | tilghman | 2010-02-08 16:31:40 -0600 (Mon, 08 Feb 2010) | 12 lines
Actually use _ASTLDFLAGS in the main/ and channels/ Makefiles.
They were previously passed correctly, but they simply weren't used. This
caused issues with various platforms whose builds needed to pass special
linker flags via the configure script.
(closes issue #16596)
Reported by: pprindeville
Patches:
asterisk-1.6-astldflags.patch uploaded by pprindeville (license 347)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244505 | tilghman | 2010-02-03 12:34:29 -0600 (Wed, 03 Feb 2010) | 8 lines
The chanvar= setting should inherit the entire list of variables, not just the first one.
(closes issue #16359)
Reported by: raarts
Patches:
dahdi-setvars.diff uploaded by raarts (license 937)
Tested by: raarts
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r243482 | russell | 2010-01-27 11:32:07 -0600 (Wed, 27 Jan 2010) | 13 lines
Fix the ability to specify an OSP token for an outbound IAX2 call.
When this patch was originally submitted, the code allowed for the token to be
set via a channel variable. I decided that a cleaner approach would be to
integrate it into the CHANNEL() function. Unfortunately, that is not a suitable
approach. It's not possible to get the value set on the channel soon enough
using that method. So, go back to the simple channel variable method.
(closes issue #16711)
Reported by: homesick
Patches:
iax-svn.diff uploaded by homesick (license 91)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r241314 | jpeeler | 2010-01-19 12:46:11 -0600 (Tue, 19 Jan 2010) | 20 lines
Merged revisions 241227 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r241227 | jpeeler | 2010-01-19 11:22:18 -0600 (Tue, 19 Jan 2010) | 13 lines
Fix deadlock in agent_read by removing call to agent_logoff.
One must always lock the agents list lock before the agent private. agent_read
locks the private immediately, so locking the agents list lock is not an
option (which is what agent_logoff requires). Because agent_read already
has access to the agent private all that is necessary is to do the required
hanging up that agent_logoff performed.
(closes issue #16321)
Reported by: valon24
Patches:
bug16321.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP show channelstats show current RTCP statistics for calls - if we have it. Calls bridged
in RTP p2p bridge doesn't have any statistics. In calls where the remote end doesn't send
RTCP or we can't receive it due to NAT, there's no reliable data as well.
Thanks, Klaus, for the patch. Sorry for the delay.
(closes issue #15819)
Reported by: klaus3000
Patches:
asterisk-sip-show-channelstats-1.6.2.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239427 | dvossel | 2010-01-12 10:14:41 -0600 (Tue, 12 Jan 2010) | 14 lines
fixes text support in sdp answer
The code that handled setting 'm=text' in the sdp was not executing
in the correct order. The check to see if text was needed came after
the check to add 'm=text' to the sdp, this resulted in 'm=text' always
being set to 0 because it looked like text was never required.
(closes issue #16457)
Reported by: peterj
Patches:
textportinsdp.diff uploaded by peterj (license 951)
issue16457.diff uploaded by dvossel (license 671)
Tested by: peterj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r238412 | dvossel | 2010-01-07 14:15:27 -0600 (Thu, 07 Jan 2010) | 16 lines
Merged revisions 238411 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r238411 | dvossel | 2010-01-07 14:14:25 -0600 (Thu, 07 Jan 2010) | 10 lines
fixes crash in "scheduled_destroy" in chan_iax
A signed short was used to represent a callnumber. This is makes
it possible to attempt to access the iaxs array with a negative
index.
(closes issue #16565)
Reported by: jensvb
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@238416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r236063 | dvossel | 2009-12-22 11:00:08 -0600 (Tue, 22 Dec 2009) | 18 lines
Merged revisions 236062 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r236062 | dvossel | 2009-12-22 10:58:19 -0600 (Tue, 22 Dec 2009) | 11 lines
fixes issue with p->method incorrectly set to ACK
It is possible for a second ACK to come in for a retransmitted message.
If an ack does not match an unacked message in our queue, restore the previous
p->method as this ACK is completely ignored.
(closes issue #16295)
Reported by: omolenkamp
Patches:
issue16295_v2.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@236064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r235521 | file | 2009-12-17 19:21:07 -0400 (Thu, 17 Dec 2009) | 3 lines
Remove some old code for going to the 'fax' extension when a T.38 switchover occurs. This would have
already happened when we detected the CNG tone so this was basically a noop.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r234526 | oej | 2009-12-14 11:46:20 +0100 (Mån, 14 Dec 2009) | 16 lines
Merged revisions 234492 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r234492 | oej | 2009-12-14 11:16:00 +0100 (Mån, 14 Dec 2009) | 8 lines
Stop sending 183's after call hangup.
There where still cases where the 183 keep-alive mechanism would not stop
sending 183's even though the Asterisk server had sent a final reply to
the invite.
EDVX-28
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@234559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r232345 | file | 2009-12-02 12:40:14 -0400 (Wed, 02 Dec 2009) | 7 lines
Add support for handling the 415 Unsupported media type response like we do for a 488 Not acceptable here response.
(closes issue #16186)
Reported by: atis
Patches:
sip_t38_response_415.patch uploaded by atis (license 242)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@232348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r232091 | jpeeler | 2009-12-01 18:45:18 -0600 (Tue, 01 Dec 2009) | 17 lines
Merged revisions 232090 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r232090 | jpeeler | 2009-12-01 18:42:58 -0600 (Tue, 01 Dec 2009) | 10 lines
Do not modify the gain settings on data calls.
(The digital flag actually represents a data call.)
(closes issue #15972)
Reported by: udosw
Patches:
transcap_digital_fix.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@232094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231692 | kpfleming | 2009-11-30 15:47:42 -0600 (Mon, 30 Nov 2009) | 22 lines
Another round of UDPTL stack fixes/improvements:
1) Allow users of UDPTL stack to associate a character-string tag with a UDPTL
session, so that log/error/debug messages generated by the UDPTL stack can
be 'connected' to the endpoint that caused them to be generated.
2) Improve comments (and process) of calculating the far end's maximum IFP size
when redundancy mode is in use for error correction.
3) When an IFP larger than the calculated 'far max IFP' size is presented for
writing, truncate it rather than putting in the buffer and allowing the buffer
to overflow; this will cause the ends to retrain to a lower bit rate that
produces IFPs of an appropriate size if possible, and if not possible, the
FAX transfer will fail completely. In these cases, it is due to the one endpoint
supplying a T38FaxMaxDatagram value that is improperly calculated and is
too low to be of use; we have configuration options available to override
this behavior.
4) Eliminate use of T38FaxMaxDatagram value in udptl.conf; it is no longer
needed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r230881 | file | 2009-11-23 09:45:45 -0600 (Mon, 23 Nov 2009) | 7 lines
Change fax detection in chan_sip so it behaves as one would expect.
Internally the way T.38 is negotiated has changed and the option no longer
reflects a behavior that is valid. It will now look for a CNG tone on
received calls and if present send the call to the 'fax' extension. It is
then up to the application or channel to request the switch over to T.38.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@230884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In sip_hangup we attempted to lock p->owner after we set it to NULL.
Thanks to fhackenberger for reporting the issue and submitting a patch.
(closes issue #15848)
Reported by: fhackenberger
Patches:
digium_bug_0015848 uploaded by fhackenberger (license 592)
Tested by: fhackenberger, lmadsen, TomS, shin-shoryuken, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@229012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r228145 | dbrooks | 2009-11-05 13:34:50 -0600 (Thu, 05 Nov 2009) | 16 lines
Merged revisions 228078 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r228078 | dbrooks | 2009-11-05 12:59:41 -0600 (Thu, 05 Nov 2009) | 9 lines
chan_misdn Asterisk 1.4.27-rc2 crash
Crash related to chan_misdn connection. Patch submitted by gknispel_proformatique, tested
by francesco_r. "I have many crash since i have upgraded to Asterisk 1.4.27-rc2. Attached
a full bt." This patch zeros out an ast_frame.
(closes issue #16041)
Reported by: francesco_r
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@228148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new code, media level proprieties should no longer be confused with session level proprieties. This change also reorganizes some of the SDP parsing code which should make it easier to manage in the future.
(closes issue #14994)
Reported by: frawd
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@227760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP channel names were supposed to be unique by way of a name suffix derived from the
pointer to the channel's private data. Uniqueness was preserved on 32-bit systems, but
not on 64-bit systems. This patch, as suggested by kpfleming, replaces this suffix with
a simple incremented unsigned int.
(closes issue #15152)
Reported by: palbrecht
Review: https://reviewboard.asterisk.org/r/420/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@226978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r225912 | jpeeler | 2009-10-26 14:40:26 -0500 (Mon, 26 Oct 2009) | 12 lines
ACL check not present for verifying SIP INVITEs
The ACL check in check_peer_ok was missing and has now been restored. The
missing check allowed for calls to be made on prohibited networks where an ACL
was defined in sip.conf and the allowguest option was set to off. See the AST
security advisory below for more information.
Merge code associated with AST-2009-007.
(closes issue #16091)
Reported by: thom4fun
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r225445 | dvossel | 2009-10-22 14:55:51 -0500 (Thu, 22 Oct 2009) | 50 lines
SIP TCP/TLS: move client connection setup/write into tcp helper thread, various related locking/memory fixes.
What this patch fixes
1.Moves sip TCP/TLS connection setup into the TCP helper thread:
Connection setup takes awhile and before this it was being
done while holding the monitor lock.
2.Moves TCP/TLS writing to the TCP helper thread: Through the
use of a packet queue and an alert pipe, the TCP helper thread
can now be woken up to write data as well as read data.
3.Locking error: sip_xmit returned an XMIT_ERROR without giving
up the tcptls_session lock. This lock has been completely removed
from sip_xmit and placed in the new sip_tcptls_write() function.
4.Memory leak: When creating a tcptls_client the tls_cfg was alloced
but never freed unless the tcptls_session failed to start. Now the
session_args for a sip client are an ao2 object which frees the
tls_cfg on destruction.
5.Pointer to stack variable: During sip_prepare_socket the creation
of a client's ast_tcptls_session_args was done on the stack and
stored as a pointer in the newly created tcptls_session. Depending
on the events that followed, there was a slight possibility that
pointer could have been accessed after the stack returned. Given
the new changes, it is always accessed after the stack returns
which is why I found it.
Notable code changes
1.I broke tcptls.c's ast_tcptls_client_start() function into two
functions. One for creating and allocating the new tcptls_session,
and a separate one for starting and handling the new connection.
This allowed me to create the tcptls_session, launch the helper
thread, and then establish the connection within the helper thread.
2.Writes to a tcptls_session are now done within the helper thread.
This is done by using an alert pipe to wake up the thread if new
data needs to be sent. The thread's sip_threadinfo object contains
the alert pipe as well as the packet queue.
3.Since the threadinfo object contains the alert pipe, it must now be
accessed outside of the helper thread for every write (queuing of a
packet). For easy lookup, I moved the threadinfo objects from a
linked list to an ao2_container.
(closes issue #13136)
Reported by: pabelanger
Tested by: dvossel, whys
(closes issue #15894)
Reported by: dvossel
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/380/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r225307 | dvossel | 2009-10-21 16:58:46 -0500 (Wed, 21 Oct 2009) | 20 lines
Merged revisions 225243 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225243 | dvossel | 2009-10-21 15:58:08 -0500 (Wed, 21 Oct 2009) | 13 lines
IAX2: VNAK loop caused by signaling frames with no destination call number
It is possible for the PBX thread to queue up signaling frames before
a destination call number is received. This can result in signaling
frames being sent out with no destination call number. Since recent
versions of Asterisk require accurate destination callnumbers for all
Full Frames, this can cause a VNAK loop to occur. To resolve this
no signaling frames are sent until a destination callnumber is received,
and destination call numbers are now only required for iax_pvt matching
when the frame is an ACK.
Review: https://reviewboard.asterisk.org/r/413/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r225033 | dvossel | 2009-10-21 09:39:10 -0500 (Wed, 21 Oct 2009) | 27 lines
Merged revisions 225032 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225032 | dvossel | 2009-10-21 09:37:04 -0500 (Wed, 21 Oct 2009) | 20 lines
IAX/SIP shrinkcallerid option
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224331 | jpeeler | 2009-10-16 20:36:08 -0500 (Fri, 16 Oct 2009) | 20 lines
Merged revisions 224330 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224330 | jpeeler | 2009-10-16 20:32:47 -0500 (Fri, 16 Oct 2009) | 13 lines
Fix stale caller id data from being reported in AMI NewChannel event
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@224334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224261 | rmudgett | 2009-10-16 15:40:57 -0500 (Fri, 16 Oct 2009) | 25 lines
Merged revisions 224260 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224260 | rmudgett | 2009-10-16 15:25:23 -0500 (Fri, 16 Oct 2009) | 18 lines
Never released PRI channels when using Busy() or Congestion() dialplan apps.
When the Busy() or Congestion() application is used towards ISDN (an ISDN
progress is sent), the responding ISDN Disconnect or Release may contain
the ISDN cause user busy or one of the congestion causes. In chan_dahdi.c
these causes will only set the needbusy or needcongestion flags and not
activate the softhangup procedure. Unfortunately only the latter can
interrupt the endless wait loop of Busy()/Congestion().
Result: PRI channels staying in state busy for the rest of asterisk life
or until the other end times out and forces the call to clear.
(in issue 0014292)
Reported by: tomaso
Patches:
disc_rel_userbusy.patch uploaded by tomaso (license 564)
(This patch is unrelated to the issue.)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@224264 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r223652 | kpfleming | 2009-10-12 09:25:29 -0500 (Mon, 12 Oct 2009) | 13 lines
Remove automatic switching from T.38 to voice mode in chan_sip.
chan_sip has some code to automatically switch from T.38 mode to voice mode when
a voice frame is written to the channel while it is in T.38 mode; this was
intended to handle the situation when a FAX transmission has ended and the channel
is not yet hung up, but is causing problems at the beginning of FAX sessions as
well when there are still voice frames 'in flight' at the time the T.38 negotiation
completes. This patch removes the automatic switchover, and changes app_fax to
explicitly switch off T.38 mode when the FAX transmission process ends.
(closes issue #16025)
Reported by: jamicque
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@223655 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is the simplest way to solve a problem that has already been solved
in trunk with the "COLP/CONP and Redirecting party information into Asterisk"
commit. In trunk the redirection reason is translated into a generic redirect
reason. I would have had to do the same fix except chan_sip never reads
PRIREDIRECTREASON. So both chan_dahdi and chan_h323 have been modified to
interpret the one different redirect reason of "no-answer" properly and set the
ISDN reason code 2 of "no reply".
(closes issue #15033)
Reported by: steinwej
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@223406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r223088 | dvossel | 2009-10-09 10:49:30 -0500 (Fri, 09 Oct 2009) | 14 lines
p->peerauth is always empty in transmit_register()
When using callbackextension or specifing the peer name
in a registration string, the peer's specific auth settings
set by the "auth=" strings within the peer definition are not
used by the registration. Thanks to ebroad for reporting the
issue and providing the patch.
(closes issue #15955)
Reported by: ebroad
Patches:
regauthfix.patch uploaded by ebroad (license 878)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@223089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222799 | rmudgett | 2009-10-08 11:44:33 -0500 (Thu, 08 Oct 2009) | 19 lines
Merged revisions 222797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222797 | rmudgett | 2009-10-08 11:33:06 -0500 (Thu, 08 Oct 2009) | 12 lines
Fix memory leak if chan_misdn config parameter is repeated.
Memory leak when the same config option is set more than once in an
misdn.conf section. Why must this be considered? Templates! Defining a
template with default port options and later adding to or overriding some
of them.
Patches:
memleak-misdn.patch
JIRA ABE-1998
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222692 | rmudgett | 2009-10-07 16:56:36 -0500 (Wed, 07 Oct 2009) | 21 lines
Merged revisions 222691 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222691 | rmudgett | 2009-10-07 16:51:24 -0500 (Wed, 07 Oct 2009) | 14 lines
chan_misdn.c:process_ast_dsp() memory leak
misdn.conf: astdtmf must be set to "yes". With "no", buffer loss does not
occur.
The translated frame "f2" when passing through ast_dsp_process() is not
freed whenever it is not used further in process_ast_dsp(). Then in the
end it is never ever freed.
Patches:
translate.patch
JIRA ABE-1993
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The variable index used in this scenario for accessing the dahdi_pvts was
wrong and was most likely copied from the several other places it is used
correctly.
(closes issue #15998)
Reported by: tsearle
Patches:
dahdi_reset_crash.patch uploaded by tsearle (license 373)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222351 | jpeeler | 2009-10-06 15:35:19 -0500 (Tue, 06 Oct 2009) | 9 lines
Fix 222298 (crash during destruction of second channel when variable set with
setvar).
I mistakenly reasoned that setvar would be used on all channels. Since it can
be set per channel, give each dahdi channel a copy of the variable.
(related to #15899)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222298 | jpeeler | 2009-10-06 14:24:59 -0500 (Tue, 06 Oct 2009) | 9 lines
Fix crash during destruction of second channel when variable set with setvar.
The setvar line in chan_dahdi.conf is shared among all the channels, so make
sure to only free the resources only when the last channel is destroyed.
(closes issue #15899)
Reported by: tzafrir
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines
Recorded merge of revisions 222152 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222110 | kpfleming | 2009-10-05 14:45:00 -0500 (Mon, 05 Oct 2009) | 25 lines
Allow non-compliant T.38 endpoints to be supportable via configuration option.
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.
This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.
In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).
(issue #15586)
Reported by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221844 | rmudgett | 2009-10-01 20:09:31 -0500 (Thu, 01 Oct 2009) | 33 lines
Merged revisions 221769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221769 | rmudgett | 2009-10-01 18:18:28 -0500 (Thu, 01 Oct 2009) | 26 lines
Occasionally losing use of B channels in chan_misdn.
I have not been able to reproduce the problem of losing channels.
However, I have seen in the code a reentrancy problem that might give
these symptoms.
The reentrancy patch does several things:
1) Guards B channel and B channel structure allocation.
2) Makes the B channel structure find routines more precise in locating records.
3) Never leave a B channel allocated if we received cause 44.
The last item may cause temporary outgoing call problems, but they should
clear when the line becomes idle.
(closes issue #15490)
Reported by: slutec18
Patches:
issue15490_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, slutec18
(closes issue #15458)
Reported by: FabienToune
Patches:
issue15458_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: FabienToune, rmudgett, slutec18
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221432 | mnicholson | 2009-09-30 15:40:20 -0500 (Wed, 30 Sep 2009) | 17 lines
Merged revisions 221360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221360 | mnicholson | 2009-09-30 14:36:06 -0500 (Wed, 30 Sep 2009) | 10 lines
Fix SRV lookup and Request-URI generation in chan_sip.
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221266 | twilson | 2009-09-30 12:52:30 -0500 (Wed, 30 Sep 2009) | 32 lines
Merged revisions 221086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r220906 | tilghman | 2009-09-29 14:57:37 -0500 (Tue, 29 Sep 2009) | 16 lines
Merged revisions 220873 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r220873 | tilghman | 2009-09-29 12:59:26 -0500 (Tue, 29 Sep 2009) | 9 lines
Reduce CPU usage related to building a peer merely for devicestates.
This fixes a 100% CPU problem in the SIP driver, found by profiling
the driver while the problem was occurring.
(closes issue #14309)
Reported by: pkempgen
Patches:
20090924__issue14309.diff.txt uploaded by tilghman (license 14)
Tested by: pkempgen, vrban
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r220718 | jpeeler | 2009-09-28 14:10:10 -0500 (Mon, 28 Sep 2009) | 10 lines
Fix building of registration entry in build_peer when using callbackextension
Check for remotesecret option was unintentionally always true, which therefore
caused the secret option to never be used. Thanks to dvossel for pointing out
the exact fix.
(closes issue #15943)
Reported by: tpsast
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@220722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219520 | dvossel | 2009-09-18 18:20:58 -0500 (Fri, 18 Sep 2009) | 15 lines
Merged revisions 219519 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219519 | dvossel | 2009-09-18 18:19:50 -0500 (Fri, 18 Sep 2009) | 9 lines
iax2 frame double free
The iax frame's retrans sched id was written over right
before iax2_frame_free was called. In iax2_frame_free that
retrans id is used to delete the sched item. By writing over
the retrans field before the sched item could be deleted, it was
possible for a retransmit to occur on a freed frame.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@219521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219451 | dvossel | 2009-09-18 11:20:41 -0500 (Fri, 18 Sep 2009) | 20 lines
Merged revisions 219450 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219450 | dvossel | 2009-09-18 11:19:15 -0500 (Fri, 18 Sep 2009) | 14 lines
via-header branches not updated correctly on INVITE
INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@219452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219304 | dvossel | 2009-09-17 16:59:21 -0500 (Thu, 17 Sep 2009) | 27 lines
Merged revisions 219303 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219303 | dvossel | 2009-09-17 16:29:37 -0500 (Thu, 17 Sep 2009) | 21 lines
INVITE w/Replaces deadlock fix
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@219307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r218918 | file | 2009-09-16 13:31:47 -0500 (Wed, 16 Sep 2009) | 5 lines
On TCP and TLS connections do not attempt to stop retransmission of the packet internally.
This was preventing responses from being properly processed because the packet was not being found
causing handle_response to return prematurely.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@218934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r218430 | jpeeler | 2009-09-14 17:38:25 -0500 (Mon, 14 Sep 2009) | 18 lines
Merged revisions 218401 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218401 | jpeeler | 2009-09-14 16:47:11 -0500 (Mon, 14 Sep 2009) | 11 lines
Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor.
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@218576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r217807 | dvossel | 2009-09-10 16:07:47 -0500 (Thu, 10 Sep 2009) | 28 lines
Merged revisions 217806 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r217806 | dvossel | 2009-09-10 16:06:07 -0500 (Thu, 10 Sep 2009) | 22 lines
IAX2 encryption regression
The IAX2 Call Token security patch inadvertently broke the use of
encryption due to the reorganization of code in the socket_process()
function. When encryption is used, an incoming full frame must first
be decrypted before the information elements can be parsed. The
security release mistakenly moved IE parsing before decryption in
order to process the new Call Token IE. To resolve this, decryption
of full frames is once again done before looking into the frame. This
involves searching for an existing callno, checking the pvt to see if
encryption is turned on, and decrypting the packet before the internal
fields of the full frame are accessed.
(closes issue #15834)
Reported by: karesmakro
Patches:
iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel, karesmakro
Review: https://reviewboard.asterisk.org/r/355/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@217821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r216993 | dvossel | 2009-09-08 09:26:30 -0500 (Tue, 08 Sep 2009) | 14 lines
caller id number empty
parse_uri was not being given the correct scheme's, as
a result, uri parsing did not parse the username correctly.
One of the side effects of this is an empty caller id.
(closes issue #15839)
Reported by: ebroad
Patches:
blank_cidv2.patch uploaded by ebroad (license 878)
parse_uri_fix.diff uploaded by dvossel (license 671)
Tested by: ebroad, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@216994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines
Merged revisions 216430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@216647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r216368 | russell | 2009-09-04 08:14:25 -0500 (Fri, 04 Sep 2009) | 12 lines
Do not treat every SIP peer as if they were configured with insecure=port.
There was a problem in the function responsible for doing peer matching by
IP address and port number such that during the second pass for checking for
a peer configured with insecure=port, it would end up treating every peer as
if it had been configured that way. These changes fix the logic in the peer
IP and port comparison callback to handle insecure=port checking properly.
This problem was introduced when SIP peers were converted to astobj2. Many
thanks to dvossel for noticing this while working on another peer matching
issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@216436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25 lines
Merged revisions 215682 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
Re-send non-100 provisional responses to prevent cancellation
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215681 | dvossel | 2009-09-02 16:39:31 -0500 (Wed, 02 Sep 2009) | 10 lines
port string to int conversion using sscanf
There are several instances where a port is parsed
from a uri or some other source and converted to
an int value using atoi(), if for some reason the
port string is empty, then a standard port is used.
This logic is used over and over, so I created a function
to handle it in a safer way using sscanf().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215665 | mvanbaak | 2009-09-02 23:23:17 +0200 (Wed, 02 Sep 2009) | 5 lines
add Parkinglot info to sip show peer <foo> and skinny show line <foo>
If we had this from the start, debugging the 'parking not using configured parkinglot'
bug would have been easier.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215479 | mvanbaak | 2009-09-02 18:20:23 +0200 (Wed, 02 Sep 2009) | 3 lines
like in chan_sip's sip_new skinny should copy the configured parkinglot from a line to the newly created channel.
This makes callparking honor the configured parkinglot for skinny lines as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215466 | dvossel | 2009-09-02 11:08:00 -0500 (Wed, 02 Sep 2009) | 16 lines
SIP support for keep-alive event
keep-alive events are used by Sipura/Linksys for NAT keepalive.
There currently don't appear to be any problems with NAT, but
everytime a keep-alive event is received, Asterisk responds with a
"489 Bad event". This error may indicate to a user that NAT
problems exist just because this even is not supported. Now,
rather than respond with an error, the packet is consumed and
a "200 ok" is sent just to indicate we received the packet.
(issue #15084)
Patches:
chan_sip.keepalive.v1.diff uploaded by IgorG (license 20)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215462 | mvanbaak | 2009-09-02 17:56:46 +0200 (Wed, 02 Sep 2009) | 12 lines
Honor configured parkinglot when parking and retrieving parked calls
Thank oej for pointing out the fact that sip_new did not copy parkinglot from the peer
into the newly created channel.
(closes issue #15538)
Reported by: gracedman
Patches:
2009090100_sipnewparkinglot-161.diff.txt uploaded by mvanbaak (license 7)
With mod by me to also fix callparking as well (this uploaded patch only fixed retrieving a parked call)
Tested by: gracedman, mvanbaak
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r213098 | tilghman | 2009-08-19 16:05:17 -0500 (Wed, 19 Aug 2009) | 9 lines
Better parsing for the "register" line
Allows characters that are otherwise used as delimiters to be used within
certain fields (like the secret).
(closes issue #15008, closes issue #15672)
Reported by: tilghman
Patches:
20090818__issue15008.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@213117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r212506 | jpeeler | 2009-08-17 11:50:45 -0500 (Mon, 17 Aug 2009) | 19 lines
Merged revisions 212498 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r212498 | jpeeler | 2009-08-17 11:34:56 -0500 (Mon, 17 Aug 2009) | 12 lines
Fix segfault when reloading chan_misdn.
If more ports were specified than configured in misdn.conf a reload would crash
asterisk. The problem was the unconfigured port was using data from the
previously configured port. When the data for an unconfigured port was freed a
crash would result from the double free.
(closes issue #12113)
Reported by: agupta
Patches:
bug12113.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@212509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r211876 | mnicholson | 2009-08-12 14:53:14 -0500 (Wed, 12 Aug 2009) | 11 lines
Make asterisk handle 423 Interval Too Short messages better.
This change uses separate values for the acceptable minimum expiry provided by the 423 error and the expiry value stored in the configuration file. Previously, the value pulled from the configuration file would be overwritten.
(closes issue #14366)
Reported by: Nick_Lewis
Patches:
sip-expiry-fix1.diff uploaded by mnicholson (license 96)
chan_sip.c-reqexpiry.patch uploaded by Nick (license 657)
Tested by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@211951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r210817 | file | 2009-08-06 14:47:04 -0300 (Thu, 06 Aug 2009) | 11 lines
Accept additional T.38 reinvites after an initial one has been handled.
Discussion of this subject has yielded that it is not actually acceptable to change
T.38 parameters after the initial reinvite but declining is harsh and can cause the
fax to fail when it may be possible to allow it to continue. This patch changes things
so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
the fax a fighting chance.
(closes issue #15610)
Reported by: huangtx2009
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@210820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210640 | rmudgett | 2009-08-05 14:40:03 -0500 (Wed, 05 Aug 2009) | 21 lines
Merged revisions 210575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
Dialplan starts execution before the channel setup is complete.
* Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables. If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
* Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
* Added missing set of CALLINGSUBADDR in the dialing is complete case.
(closes issue #15655)
Reported by: alecdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@210686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r210190 | kpfleming | 2009-08-03 15:48:48 -0500 (Mon, 03 Aug 2009) | 11 lines
Rename 'canreinvite' option to 'directmedia', with backwards compatibility.
It is clear from multiple mailing list, forum, wiki and other sorts of posts
that users don't really understand the effects that the 'canreinvite' config
option actually has, and that in some cases they think that setting it to 'no'
will actually cause various other features (T.38, MOH, etc.) to not work properly,
when in fact this is not the case. This patch changes the proper name of the
option to what it should have been from the beginning ('directmedia'), but
preserves backwards compatibility for existing configurations.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@210191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r209760 | kpfleming | 2009-07-31 20:03:07 -0500 (Fri, 31 Jul 2009) | 13 lines
Merged revisions 209759 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
........
................
r209761 | kpfleming | 2009-07-31 20:04:06 -0500 (Fri, 31 Jul 2009) | 1 line
Revert accidental Makefile change.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@209816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r208749 | jpeeler | 2009-07-25 01:23:18 -0500 (Sat, 25 Jul 2009) | 13 lines
Merged revisions 208746 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208746 | jpeeler | 2009-07-25 01:19:50 -0500 (Sat, 25 Jul 2009) | 7 lines
Fix compiling under dev-mode with gcc 4.4.0.
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@208755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r208588 | mmichelson | 2009-07-24 13:31:04 -0500 (Fri, 24 Jul 2009) | 16 lines
Merged revisions 208587 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208587 | mmichelson | 2009-07-24 13:26:50 -0500 (Fri, 24 Jul 2009) | 10 lines
Only send a BYE when hanging up a channel that is up.
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
(closes issue #14575)
Reported by: chris-mac
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@208591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tzafrir Cohen
Paul Belanger
Matthew Nicholson
Jeff Peeler
Richard Mudgett
Mark Michelson
David Vossel
Leif Madsen
Tilghman Lesher
Russell Bryant
Sean Bright
Terry Wilson
Moises Silva
Alec L Davis
Kevin P. Fleming
Olle Johansson
Joshua Colp
Jason Parker
David Brooks
Michiel van Baak