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.1@211950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r211908 | jpeeler | 2009-08-12 15:47:45 -0500 (Wed, 12 Aug 2009) | 12 lines
Fix chan_dahdi option ringtimeout
dahdi_read relies on the dahdi_pvt copy of ringt which was not getting set
in sig_analog. This patch adds a callback to do so.
(closes issue #15288)
Reported by: alecdavis
Patches:
chan_dahdi.ringtimeout.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r211809 | mmichelson | 2009-08-12 13:47:51 -0500 (Wed, 12 Aug 2009) | 15 lines
Blocked revisions 211807 via svnmerge
........
r211807 | mmichelson | 2009-08-12 13:46:09 -0500 (Wed, 12 Aug 2009) | 10 lines
Backport fix so that outbound CANCEL requests have same branch as challenged INVITEs.
There already was code present to be sure that a CANCEL will contain the same branch-id
as the INVITE it is cancelling. However, for INVITES which are challenged downstream,
this mechanism did not work properly. Now this is taken care of.
This is a backport of a fix already present in all 1.6.X branches and in trunk. It also
fixes ABE-1907.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r211435 | jpeeler | 2009-08-10 12:17:06 -0500 (Mon, 10 Aug 2009) | 3 lines
Fix PRI/BRI channels when in alarm condition to only be marked for hangup if
T309 is not enabled.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211440 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r211040 | tilghman | 2009-08-07 13:17:41 -0500 (Fri, 07 Aug 2009) | 21 lines
Merged revisions 211038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r211038 | tilghman | 2009-08-07 13:16:28 -0500 (Fri, 07 Aug 2009) | 14 lines
QUEUE_MEMBER_LIST _really_ wants the interface name, not the membername.
This is a partial revert of revision 82590, which was an attempted cleanup,
but in reality, it broke QUEUE_MEMBER_LIST, which has always been intended
as a method by which component interfaces could be queried from the queue.
Membername isn't useful here, because that field cannot be used to obtain
further information about the member. See the documentation on
QUEUE_MEMBER_LIST, RemoveQueueMember, QUEUE_MEMBER_PENALTY, and the various
AMI commands which take a member argument for further justification.
(closes issue #15664)
Reported by: rain
Patches:
app_queue-queue_member_list.diff uploaded by rain (license 327)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r210992 | kpfleming | 2009-08-07 08:08:00 -0500 (Fri, 07 Aug 2009) | 13 lines
Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.
Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.
(closes issue #15649)
Reported by: dazza76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210914 | tilghman | 2009-08-06 16:46:01 -0500 (Thu, 06 Aug 2009) | 14 lines
Merged revisions 210913 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210916 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.1@210819 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.1@210681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210564 | lmadsen | 2009-08-05 13:49:58 -0500 (Wed, 05 Aug 2009) | 19 lines
Merged revisions 210563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210563 | lmadsen | 2009-08-05 13:46:21 -0500 (Wed, 05 Aug 2009) | 11 lines
Update imapstorage.txt documentation.
Updated the imapstorage.txt documentation to reflect that issues with
c-client versions older than 2007 seem to cause crashing issues that
are not seen with more recent versions. Documentation has been updated
to reflect this.
(closes issue #14496)
Reported by: vbcrlfuser
Patches:
__20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, mmichelson, dbrooks
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r210302 | jpeeler | 2009-08-04 10:35:49 -0500 (Tue, 04 Aug 2009) | 5 lines
Fix broken call pickup
The find_channel_by_group callback was only looking at the channel that was
attempting to make the pickup instead of the other channels in the container.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210238 | kpfleming | 2009-08-04 09:53:00 -0500 (Tue, 04 Aug 2009) | 16 lines
Merged revisions 210237 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210237 | kpfleming | 2009-08-04 09:51:39 -0500 (Tue, 04 Aug 2009) | 10 lines
Eliminate spurious compiler warnings from system headers on *BSD platforms.
Ensure that system headers located in /usr/local/include are actually treated
as system headers by the compiler, and not as local headers which are subject
to warnings from the -Wundef compiler option and others.
(closes issue #15606)
Reported by: mvanbaak
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r209839 | russell | 2009-08-01 06:02:07 -0500 (Sat, 01 Aug 2009) | 20 lines
Merged revisions 209838 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209838 | russell | 2009-08-01 05:59:05 -0500 (Sat, 01 Aug 2009) | 13 lines
Modify how Playtones() is used in Milliwatt() to resolve gain issue.
When Milliwatt() was changed internally to use Playtones() so that the proper
tone was used, it introduced a drop in gain in the output signal. So, use
the playtones API directly and specify a volume argument such that the output
matches the gain of the original Milliwatt() code.
(closes issue #15386)
Reported by: rue_mohr
Patches:
issue_15386.rev2.diff uploaded by russell (license 2)
Tested by: rue_mohr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209841 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.1@209781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r209256 | kpfleming | 2009-07-27 16:21:43 -0500 (Mon, 27 Jul 2009) | 10 lines
Make T.38 switchover in ReceiveFAX synchronous.
In receive mode, if the channel that ReceiveFAX is running on supports T.38,
we should *always* attempt to switch T.38, rather than listening for an incoming
CNG tone and only triggering on that. The channel may be using a low-bitrate
codec that distorts the CNG tone, the sending FAX endpoint may not send CNG
at all, or there could be a variety of other reasons that we don't detect it,
but in all those cases if T.38 is available we certainly want to use it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r209132 | mmichelson | 2009-07-27 12:50:04 -0500 (Mon, 27 Jul 2009) | 24 lines
Merged revisions 209131 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) | 18 lines
Allow for UDPTL to use only even-numbered ports if desired.
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r209056 | kpfleming | 2009-07-27 10:38:59 -0500 (Mon, 27 Jul 2009) | 10 lines
Restore explicit export of ASTCFLAGS/ASTLDFLAGS and underscore-variants to sub-makes.
During the recent Makefile improvements I made, it seemed the 'make' was
automatically carrying down the ASTCFLAGS/ASTLDFLAGS settings to sub-makes,
so I removed the explict export of them. However, there are some circumstances
where make does this, and some where it does not, so I've brought them back
to ensure they are always exported. I also removed an extraneous double setting
of _ASTLDFLAGS on *BSD platforms.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r208813 | mvanbaak | 2009-07-25 14:03:25 +0200 (Sat, 25 Jul 2009) | 10 lines
add default alias reload to run module reload.
Requiring 'module reload' to reload everything, including
core etc makes russell very unhappy.
The default configuration already loads the 'friendly' aliases template.
Added 'reload=module reload' to that template.
Also removed the comment in main/cli.c that reload should come back.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208815 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.1@208754 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
Don't impose an arbitrary limit on member lines in queues.conf
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208661 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.1@208590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
