https://origsvn.digium.com/svn/asterisk/trunk
................
r121230 | mmichelson | 2008-06-09 10:08:58 -0500 (Mon, 09 Jun 2008) | 27 lines
Merged revisions 121229 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
(Note that this is being merged to trunk/1.6.0 because
it may affect non-callback agents with ackcall set)
........
r121229 | mmichelson | 2008-06-09 10:02:37 -0500 (Mon, 09 Jun 2008) | 16 lines
A unique situation of timeouts brought forth a failure situation for
autologoff in chan_agent. If using AgentCallbackLogin-style agents,
then if the timeout specified by the Dial() to reach the agent's phone
was shorter than the timeout specified in queues.conf, then autologoff
would only work if the caller hung up while the agent's phone was ringing.
This patch allows autologoff to work in this situation when the call in
queue transfers to the next available agent (as it would have if the timeout
in queues.conf were less than the timeout in the Dial()).
(closes issue #12754)
Reported by: Rodrigo
Patches:
12754.patch uploaded by putnopvut (license 60)
Tested by: Rodrigo
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@121231 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r121163 | jpeeler | 2008-06-07 20:41:59 -0500 (Sat, 07 Jun 2008) | 4 lines
This was accidentally reverted.
Fixes a bug where if a stream monitor thread was not created (caused from failure of opening or starting the stream) pthread_cancel was called with an invalid thread ID.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@121164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r120906 | jpeeler | 2008-06-06 12:50:05 -0500 (Fri, 06 Jun 2008) | 16 lines
Merged revisions 120863,120885 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r120863 | jpeeler | 2008-06-06 10:33:15 -0500 (Fri, 06 Jun 2008) | 3 lines
This fixes a crash when LOW_MEMORY is turned on. Two allocations of the ast_rtp struct that were previously allocated on the stack have been modified to use thread local storage instead.
........
r120885 | jpeeler | 2008-06-06 11:39:20 -0500 (Fri, 06 Jun 2008) | 2 lines
Correction to commmit 120863, make sure proper destructor function is called as well define two thread storage local variables.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@120907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r119839 | russell | 2008-06-02 15:08:24 -0500 (Mon, 02 Jun 2008) | 15 lines
Merged revisions 119838 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119838 | russell | 2008-06-02 15:08:04 -0500 (Mon, 02 Jun 2008) | 7 lines
Revert a change made for issue #12479. This change caused a regression such that
a dial string such as (IAX2/foo) did not automatically fall back to dialing the 's'
extension anymore.
(closes issue #12770)
Reported by: dagmoller
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r119741 | phsultan | 2008-06-02 16:35:24 +0200 (Mon, 02 Jun 2008) | 13 lines
Do not link the guest account with any configured XMPP client (in
jabber.conf). The actual connection is made when a call comes in
Asterisk.
Apply this fix to Jingle too.
Fix the ast_aji_get_client function that was not able to retrieve an
XMPP client from its JID.
(closes issue #12085)
Reported by: junky
Tested by: phsultan
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r119586 | crichter | 2008-06-02 03:46:23 -0500 (Mon, 02 Jun 2008) | 9 lines
Merged revisions 119585 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119585 | crichter | 2008-06-02 10:35:28 +0200 (Mo, 02 Jun 2008) | 1 line
Added counter for unhandled_bmsg Print, this prevents the logs to be flooded to fast and save CPU in this error scenario. Added 'last_used' element to bc structure, when a bchannel changes from used to free this exact time will be marked in last_used. When a new channel is requested the find_free_chan function will check if the new empty channel was used within the last second, if yes it will search for the next channel, if no it will return this channel. This simple mechanism has prooven to prevent race conditions where the NT and TE tried to allocate the exact same channel at the same time (RELEASE cause: 44).
........
................
r119637 | crichter | 2008-06-02 04:35:04 -0500 (Mon, 02 Jun 2008) | 9 lines
Merged revisions 119636 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119636 | crichter | 2008-06-02 11:29:21 +0200 (Mo, 02 Jun 2008) | 1 line
fixed compile issue when dev-mode is enabled
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r119239 | russell | 2008-05-30 07:59:11 -0500 (Fri, 30 May 2008) | 23 lines
Merged revisions 119238 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r119238 | russell | 2008-05-30 07:55:36 -0500 (Fri, 30 May 2008) | 15 lines
Merged revisions 119237 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r119237 | russell | 2008-05-30 07:49:39 -0500 (Fri, 30 May 2008) | 7 lines
- Instead of only enforcing destination call number checking on an ACK, check
all full frames except for PING and LAGRQ, which may be sent by older versions
too quickly to contain the destination call number.
(As suggested by Tim Panton on the asterisk-dev list)
- Merge changes from team/russell/iax2-frame-race, which prevents PING and LAGRQ
from being sent before the destination call number is known.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r118955 | tilghman | 2008-05-29 12:35:19 -0500 (Thu, 29 May 2008) | 11 lines
Merged revisions 118953 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118953 | tilghman | 2008-05-29 12:20:16 -0500 (Thu, 29 May 2008) | 3 lines
Add some debugging code that ensures that when we do deadlock avoidance, we
don't lose the information about how a lock was originally acquired.
........
................
r118957 | tilghman | 2008-05-29 12:39:50 -0500 (Thu, 29 May 2008) | 10 lines
Merged revisions 118954 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118954 | tilghman | 2008-05-29 12:33:01 -0500 (Thu, 29 May 2008) | 2 lines
Define also when not DEBUG_THREADS
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r118647 | file | 2008-05-28 11:29:01 -0300 (Wed, 28 May 2008) | 12 lines
Merged revisions 118646 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118646 | file | 2008-05-28 11:23:34 -0300 (Wed, 28 May 2008) | 4 lines
Add an option to use the source IP address of RTP as the destination IP address of UDPTL when a specific option is enabled. If the remote side is properly configured (ports forwarded) then UDPTL will flow.
(closes issue #10417)
Reported by: cstadlmann
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r118252 | tilghman | 2008-05-25 11:17:05 -0500 (Sun, 25 May 2008) | 20 lines
Merged revisions 118251 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118251 | tilghman | 2008-05-25 11:02:04 -0500 (Sun, 25 May 2008) | 12 lines
Realtime flag affects construction in multiple ways, so consulting whether
rtcachefriends was set was done too soon (needed to be done inside build_peer,
not just as a flag to build_peer).
Also, fullcontact needed to be reconstructed, because realtime separates the
embedded ';' into multiple fields.
(closes issue #12722)
Reported by: barthpbx
Patches:
20080525__bug12722.diff.txt uploaded by Corydon76 (license 14)
Tested by: barthpbx
(Much of the discussion happened on #asterisk-dev for diagnosing this issue)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r118020 | phsultan | 2008-05-23 12:33:21 +0200 (Fri, 23 May 2008) | 15 lines
- remove whitespaces between tags in received XML packets before giving
them to the parser ;
- report Gtalk error messages from a buddy to the console.
This patch makes Asterisk "Google Jingle" (chan_gtalk) implementation
work with Empathy. Note that this is only true for audio streams, not
video.
Thank you to PH for his great help!
(closes issue #12647)
Reported by: PH
Patches:
trunk-12647-1.diff uploaded by phsultan (license 73)
Tested by: phsultan, PH
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r117628 | jpeeler | 2008-05-21 15:44:04 -0500 (Wed, 21 May 2008) | 12 lines
Merged revisions 117462 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r117462 | jpeeler | 2008-05-21 11:58:40 -0500 (Wed, 21 May 2008) | 3 lines
Pass a pointer for the conf parameter to the function mkintf rather than the whole zt_chan_conf structure.
Another commit is following to make sure the zt_chan_conf structure is not modified.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@117659 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r116039 | russell | 2008-05-13 16:18:55 -0500 (Tue, 13 May 2008) | 32 lines
Merged revisions 116038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116038 | russell | 2008-05-13 16:17:23 -0500 (Tue, 13 May 2008) | 24 lines
Fix a deadlock involving channel autoservice and chan_local that was debugged
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in ast_autoservice_stop().
The reason these threads were waiting around is because this function waits to
ensure that the channel list in the autoservice thread gets rebuilt before the
stop() function returns. However, the autoservice thread was also locked, so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local channel.
However, the local channel was locked by a thread that was stuck in the autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function in
chan_local. This function assumed that one of the channels passed in as an
argument was locked when called. However, that was not always the case. There
were multiple cases in which this channel was not locked when the function was
called. We fixed up chan_local to indicate to this function whether this channel
was locked or not. The previous assumption had caused local_queue_frame() to
improperly return with the channel locked, where it would then never get unlocked.
(closes issue #12584)
(related to issue #12603)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@116040 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115566 | russell | 2008-05-08 14:17:04 -0500 (Thu, 08 May 2008) | 41 lines
Merged revisions 115565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r115565 | russell | 2008-05-08 14:15:25 -0500 (Thu, 08 May 2008) | 33 lines
Merged revisions 115564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines
Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy. We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.
It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed. So, that frame did not include
the destination call number, because it didn't have it yet. Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one. This
caused the frame to be rejected with an INVAL. The frame would get retransmitted
for forever, rejected every time ...
This race condition exists in all versions that got the security changes,
in theory. However, it is really only likely that this would cause a problem in
Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing
all versions that could potentially be affected by the introduced race condition.
These changes are what bbryant and I came up with to fix the issue. Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly. If it doesn't complete after yielding for a little
while, then the frame gets dropped.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115305 | russell | 2008-05-05 14:50:24 -0500 (Mon, 05 May 2008) | 13 lines
Merged revisions 115304 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115304 | russell | 2008-05-05 14:49:25 -0500 (Mon, 05 May 2008) | 5 lines
Avoid putting opaque="" in Digest authentication. This patch came from switchvox.
It fixes authentication with Primus in Canada, and has been in use for a very long
time without causing problems with any other providers.
(closes issue AST-36)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r114922 | qwell | 2008-05-01 11:49:24 -0500 (Thu, 01 May 2008) | 10 lines
Allow dringXrange to properly default to 10, as was done in 1.4.
dringXrange is a new feature that was added, and it attempted to default, but only when the option was specified.
(closes issue #12536)
Reported by: bjm
Patches:
12536-dringXrange.diff uploaded by qwell (license 4)
Tested by: bjm
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114892 | russell | 2008-04-30 11:34:24 -0500 (Wed, 30 Apr 2008) | 36 lines
Merged revisions 114891 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114891 | russell | 2008-04-30 11:30:01 -0500 (Wed, 30 Apr 2008) | 28 lines
Merge changes from team/russell/iax2_find_callno and iax2_find_callno_1.4
These changes address a critical performance issue introduced in the latest
release. The fix for the latest security issue included a change that made
Asterisk randomly choose call numbers to make them more difficult to guess by
attackers. However, due to some inefficient (this is by far, an understatement)
code, when Asterisk chose high call numbers, chan_iax2 became unusable after
just a small number of calls. On a small embedded platform, it would not be
able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't
run more than about 16 IAX2 channels. Ouch.
These changes address some performance issues of the find_callno() function
that have bothered me for a very long time. On every incoming media frame,
it iterated through every possible call number trying to find a matching
active call. This involved a mutex lock and unlock for each call number
checked. So, if the random call number chosen was 20000, then every media
frame would cause 20000 locks and unlocks. Previously, this problem was
not as obvious since Asterisk always chose the lowest call number it could.
A second container for IAX2 pvt structs has been added. It is an astobj2
hash table. When we know the remote side's call number, the pvt goes into
the hash table with a hash value of the remote side's call number. Then,
lookups for incoming media frames are a very fast hash lookup instead of an
absolutely insane array traversal.
In a quick test, I was able to get more than 3600% more IAX2 channels
on my machine with these changes.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114884 | kpfleming | 2008-04-30 09:49:51 -0500 (Wed, 30 Apr 2008) | 10 lines
Merged revisions 114880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114880 | kpfleming | 2008-04-30 09:46:57 -0500 (Wed, 30 Apr 2008) | 2 lines
use the ARRAY_LEN macro for indexing through the iaxs/iaxsl arrays so that the size of the arrays can be adjusted in one place, and change the size of the arrays from 32768 calls to 2048 calls when LOW_MEMORY is defined
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r114866 | jpeeler | 2008-04-29 17:54:14 -0500 (Tue, 29 Apr 2008) | 2 lines
Fixes a problem where all the templates were marked as dead no matter what. The templates should only be marked as dead if a configuration file has been successfully loaded and has changes. Bug found while making API documentation for 1.6.0.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
Merged to 1.6 because it fixes a crash.
........
r114700 | mvanbaak | 2008-04-27 17:17:18 +0200 (Sun, 27 Apr 2008) | 8 lines
Make MWI in chan_skinny event based modeled after chan_zap and chan_mgcp.
(closes issue #12214)
Reported by: DEA
Patches:
chan_skinny-vm-events-v3.txt uploaded by DEA (license 3)
Tested by: DEA and me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114633 | mmichelson | 2008-04-24 16:35:39 -0500 (Thu, 24 Apr 2008) | 19 lines
Merged revisions 114632 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114632 | mmichelson | 2008-04-24 16:35:08 -0500 (Thu, 24 Apr 2008) | 11 lines
Re-invite RTP during a masquerade so that, for instance, an AMI
redirect of two channels which are natively bridged will preserve audio
on both channels. This prevents a problem with Asterisk not re-inviting
due to one of the channels having being a zombie.
(closes issue #12513)
Reported by: mneuhauser
Patches:
asterisk-1.4-114602_restore-RTP-on-fixup.patch uploaded by mneuhauser (license 425)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114612 | qwell | 2008-04-24 11:47:01 -0500 (Thu, 24 Apr 2008) | 17 lines
Merged revisions 51989 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #12496)
Reported by: daniele
Patches:
misdn-moh-1.6.0-beta7.1.patch uploaded by daniele (license 471)
Tested by: daniele
Technically, I didn't use the patch above except to find out what revision to merge - but it's the same thing as this revision.
........
r51989 | crichter | 2007-01-24 06:57:22 -0600 (Wed, 24 Jan 2007) | 1 line
added fix from #8899
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114538 | russell | 2008-04-22 13:04:39 -0500 (Tue, 22 Apr 2008) | 17 lines
Merged revisions 114537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines
If the dial string passed to the call channel callback does not indicate an
extension, then consider the extension on the channel before falling back
to the default.
(closes issue #12479)
Reported by: darren1713
Patches:
exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114185 | kpfleming | 2008-04-16 15:47:30 -0500 (Wed, 16 Apr 2008) | 14 lines
Merged revisions 114184 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114184 | kpfleming | 2008-04-16 15:46:38 -0500 (Wed, 16 Apr 2008) | 6 lines
use the ZT_SET_DIALPARAMS ioctl properly by initializing the structure to all zeroes in case it contains fields that we don't write values into (which it does as of Zaptel 1.4.10)
(closes issue #12456)
Reported by: fnordian
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114084 | twilson | 2008-04-11 17:48:52 -0500 (Fri, 11 Apr 2008) | 15 lines
Merged revisions 114083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114083 | twilson | 2008-04-11 17:32:51 -0500 (Fri, 11 Apr 2008) | 7 lines
Several places in the code called find_callno() (which releases the lock on the pvt structure) and then immediately locked the call and did things with it. Unfortunately, the call can disappear between the find_callno and the lock, causing Bad Stuff(tm) to happen.
Added find_callno_locked() function to return the callno withtout unlocking for instances that it is needed.
(issue #12400)
Reported by: ztel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113928 | mmichelson | 2008-04-09 15:56:14 -0500 (Wed, 09 Apr 2008) | 16 lines
Merged revisions 113927 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines
We need to set the persistant_route [sic] parameter for the sip_pvt
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113785 | file | 2008-04-09 13:52:04 -0300 (Wed, 09 Apr 2008) | 12 lines
Merged revisions 113784 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113784 | file | 2008-04-09 13:50:45 -0300 (Wed, 09 Apr 2008) | 4 lines
If we receive an AUTHREQ from the remote server and we are unable to reply (for example they have a secret configured, but we do not) then queue a hangup frame on the Asterisk channel. This will cause the channel to hangup and a HANGUP to be sent via IAX2 to the remote side which is the proper thing to do in this scenario.
(closes issue #12385)
Reported by: viraptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113682 | mmichelson | 2008-04-09 09:41:58 -0500 (Wed, 09 Apr 2008) | 17 lines
Merged revisions 113681 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113681 | mmichelson | 2008-04-09 09:40:05 -0500 (Wed, 09 Apr 2008) | 9 lines
If Asterisk receives a 488 on an INVITE (not a reinvite), then
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113241 | jpeeler | 2008-04-07 16:35:48 -0500 (Mon, 07 Apr 2008) | 23 lines
Merged revisions 113013 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r112431 | file | 2008-04-02 12:26:51 -0300 (Wed, 02 Apr 2008) | 7 lines
Since the SIP request structure gets reused multiple times with TCP handling we have to clear the debug state or else we will keep spitting out debug even after it has been turned off.
(closes issue #12169)
Reported by: pj
Patches:
12169-debugoff-2.diff uploaded by qwell (license 4)
Tested by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r111017 | file | 2008-03-26 15:42:52 -0300 (Wed, 26 Mar 2008) | 12 lines
Merged revisions 110628 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@111018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110636 | mmichelson | 2008-03-25 10:41:33 -0500 (Tue, 25 Mar 2008) | 15 lines
Merged revisions 110635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110635 | mmichelson | 2008-03-25 10:40:33 -0500 (Tue, 25 Mar 2008) | 7 lines
When reverting a commit, I accidentally left in this bit which was an experiment
to see what would happen. It passed the compile test, and I didn't notice I had
left this change in too.
So this is a revert of a revert...sort of.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110619 | mmichelson | 2008-03-24 14:19:37 -0500 (Mon, 24 Mar 2008) | 23 lines
Merged revisions 110618 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110618 | mmichelson | 2008-03-24 14:17:41 -0500 (Mon, 24 Mar 2008) | 15 lines
This is a revert for revision 108288. The reason is that that revision
was not for an actual bug fix per se, and so it really should not have been in 1.4 in
the first place. Plus, people who compile with DO_CRASH are more likely
to encounter a crash due to this change. While I think the usage of DO_CRASH
in ast_sched_del is a bit absurd, this sort of change is beyond the scope of 1.4
and should be done instead in a developer branch based on trunk
so that all scheduler functions are fixed at once.
I also am reverting the change to trunk and 1.6 since they also suffer from
the DO_CRASH potential.
(closes issue #12272)
Reported by: qq12345
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r110337 | russell | 2008-03-20 16:55:50 -0500 (Thu, 20 Mar 2008) | 22 lines
Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines
Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@110338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r109447 | twilson | 2008-03-18 10:43:34 -0500 (Tue, 18 Mar 2008) | 3 lines
Go through and fix a bunch of places where character strings were being interpreted as format strings. Most of these changes are solely to make compiling with -Wsecurity and -Wformat=2 happy, and were not
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r109168 | mvanbaak | 2008-03-17 18:43:46 +0100 (Mon, 17 Mar 2008) | 11 lines
Update the directory of placed calls on skinny phones
when dialing a channel that does not provide progress (analog ZAP lines)
The phone does handle the double update on calls to channels that do
provide progress and wont insert duplicate items
(closes issue #12239)
Reported by: DEA
Patches:
chan_skinny-call-log.txt uploaded by DEA (license 3)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108738 | mmichelson | 2008-03-14 11:52:51 -0500 (Fri, 14 Mar 2008) | 41 lines
Merged revisions 108737 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108737 | mmichelson | 2008-03-14 11:44:08 -0500 (Fri, 14 Mar 2008) | 33 lines
Fix a race condition in the SIP packet scheduler which could cause a crash.
chan_sip uses the scheduler API in order to schedule retransmission of reliable
packets (such as INVITES). If a retransmission of a packet is occurring, then the
packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if
a response is received from the packet as previously transmitted, then when we
ACK the response, we will remove the packet from the scheduler and free the packet.
The problem is that both the ACK function and retrans_pkt attempt to acquire the
same lock at the beginning of the function call. This means that if the ACK function
acquires the lock first, then it will free the packet which retrans_pkt is about to
read from and write to. The result is a crash.
The solution:
1. If the ACK function fails to remove the packet from the scheduler and the retransmit
id of the packet is not -1 (meaning that we have not reached the maximum number of
retransmissions) then release the lock and yield so that retrans_pkt may acquire the
lock and operate.
2. Make absolutely certain that the ACK function does not recursively lock the lock in
question. If it does, then releasing the lock will do no good, since retrans_pkt will
still be unable to acquire the lock.
(closes issue #12098)
Reported by: wegbert
(closes issue #12089)
Reported by: PTorres
Patches:
12098-putnopvutv3.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108531 | russell | 2008-03-13 16:06:52 -0500 (Thu, 13 Mar 2008) | 18 lines
Merged revisions 108530 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108530 | russell | 2008-03-13 16:06:33 -0500 (Thu, 13 Mar 2008) | 10 lines
Make a tweak that gets the LEDs on polycom phones to blink when an extension that
has been subscribed to goes on hold. Otherwise, they just stay on like it does
when an extension is in use.
(closes issue #11263)
Reported by: russell
Patches:
notify_hold.rev1.txt uploaded by russell (license 2)
Tested by: russell
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108289 | mmichelson | 2008-03-12 16:57:41 -0500 (Wed, 12 Mar 2008) | 22 lines
Merged revisions 108288 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108288 | mmichelson | 2008-03-12 16:53:46 -0500 (Wed, 12 Mar 2008) | 14 lines
Change AST_SCHED_DEL use to ast_sched_del for autocongestion in chan_sip.
The scheduler callback will always return 0. This means that this id
is never rescheduled, so it makes no sense to loop trying to delete
the id from the scheduler queue. If we fail to remove the item from the
queue once, it will fail every single time.
(Yes I realize that in this case, the macro would exit early because the
id is set to -1 in the callback, but it still makes no sense to use
that macro in favor of calling ast_sched_del once and being done with it)
This is the first of potentially several such fixes.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r108191 | kpfleming | 2008-03-12 15:27:01 -0500 (Wed, 12 Mar 2008) | 14 lines
Merged revisions 108086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108086 | kpfleming | 2008-03-12 14:16:07 -0500 (Wed, 12 Mar 2008) | 6 lines
if we receive an INVITE with a Content-Length that is not a valid number, or is zero, then don't process the rest of the message body looking for an SDP
closes issue #11475
Reported by: andrebarbosa
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@108205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r106946 | kpfleming | 2008-03-08 10:03:48 -0600 (Sat, 08 Mar 2008) | 10 lines
Merged revisions 106945 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106945 | kpfleming | 2008-03-08 09:59:42 -0600 (Sat, 08 Mar 2008) | 2 lines
don't generate D-Channel "up" and "down" messages unless the channel state is actually changing; also, generate the "up" message when an implicit "up" occurs due to reception of a normal event when we thought the channel was "down"
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r105734 | russell | 2008-03-04 14:36:16 -0600 (Tue, 04 Mar 2008) | 6 lines
Fix some bugs in the SIP tcp helper thread.
- fix a spot where a lock wouldn't get unlocked in an error condition
- call ast_mutex_destroy() on the lock before freeing its memory
(related to issue #11972)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r105675 | file | 2008-03-04 12:08:42 -0600 (Tue, 04 Mar 2008) | 16 lines
Merged revisions 105674 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines
When a new source of audio comes in (such as music on hold) make sure the marker bit gets set.
(closes issue #10355)
Reported by: wdecarne
Patches:
10355.diff uploaded by file (license 11)
(closes issue #11491)
Reported by: kanderson
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r106040 | kpfleming | 2008-03-05 09:40:40 -0600 (Wed, 05 Mar 2008) | 15 lines
Merged revisions 106038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines
when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one
(closes issue #11917)
Reported by: mavetju
Tested by: mavetju
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@106041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines
Merge changes from team/russell/smdi-1.4
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104095 | file | 2008-02-25 17:37:20 -0400 (Mon, 25 Feb 2008) | 6 lines
Make it so a users.conf user creates both a SIP peer and a SIP user. The user will be used for inbound authentication for the device, and peer will be used for placing calls to the device.
(closes issue #9044)
Reported by: queuetue
Patches:
sip-gui-friend.diff uploaded by qwell (license 4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104084 | file | 2008-02-25 12:16:13 -0400 (Mon, 25 Feb 2008) | 6 lines
If a resubscription comes in for a dialog we no longer know about tell the remote side that the dialog does not exist so they subscribe again using a new dialog.
(closes issue #10727)
Reported by: s0l4rb03
Patches:
10727-2.diff uploaded by file (license 11)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104082 | file | 2008-02-25 11:17:18 -0400 (Mon, 25 Feb 2008) | 6 lines
Due to recent changes tag will no longer be NULL if not present so we have to use ast_strlen_zero to see if it's actually blank.
(closes issue #12061)
Reported by: flefoll
Patches:
chan_sip.c.br14.patch_pedantic_no_totag uploaded by flefoll (license 244)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103821 | russell | 2008-02-19 14:02:49 -0600 (Tue, 19 Feb 2008) | 8 lines
Account for the fact that the "other" channel can disappear while the local pvt
is not locked.
(fixes a problem introduced in rev 100581)
(closes issue #12012)
Reported by: stevedavies
Patch by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: julianjm
Patches:
chan_zap.c-1.4-devicestate-v1.diff uploaded by julianjm (license 99)
Patch fixes problem of device state incorrectly reporting idle before PBX answers incoming call on FXO channel. Device status is updated now during new channel creation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103780 | tilghman | 2008-02-18 11:31:52 -0600 (Mon, 18 Feb 2008) | 9 lines
When a SIP channel is being auto-destroyed, it's possible for it to still be
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103770 | mmichelson | 2008-02-18 10:37:31 -0600 (Mon, 18 Feb 2008) | 10 lines
Fix a linked list corruption that under the right circumstances
could lead to a looped list, meaning it will traverse forever.
(closes issue #11818)
Reported by: michael-fig
Patches:
11818.patch uploaded by putnopvut (license 60)
Tested by: michael-fig
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #8925)
About a year ago, as Leif Madsen and Jim van Meggelen were going over the CLI
commands in Asterisk 1.4 for the next version of their book, they documented
a lot of inconsistencies. This set of changes addresses all of these issues
and has been reviewed by Leif.
While this does introduce even more changes to the CLI command structure, it
makes everything consistent, which is the most important thing.
Thanks to all that helped with this one!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r102090 | oej | 2008-02-03 11:37:32 +0100 (Sön, 03 Feb 2008) | 8 lines
Handle ACK and CANCEL in an invite transaction - even if we get INFO transactions during the actual call setup.
(closes issue #10567)
Reported by: jacksch
Tested by: oej
Patch by: oej inspired by suggestions from neutrino88 in the bug tracker
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@102091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101989 | russell | 2008-02-01 17:06:32 -0600 (Fri, 01 Feb 2008) | 5 lines
Change the SDP_SAMPLE_RATE macro. It turns out that even though G.722 is 16 kHz,
it is supposed to specified as 8 kHz in the RTP, and RTP timestamps are supposed
to be calculated based on 8 kHz. (Apparently this is due to a bug in a spec, but
people follow it anyway, because it's the spec ...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101693 | russell | 2008-01-31 18:32:49 -0600 (Thu, 31 Jan 2008) | 8 lines
Add some more sanity checking on IAX2 dial strings for the case that no peer
or hostname was provided, which is the one part of the dial string that is
absolutely required. If it's not there, bail out.
(closes issue #11897)
Reported by sokhapkin
Patch by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101413 | russell | 2008-01-31 13:04:52 -0600 (Thu, 31 Jan 2008) | 2 lines
Add missing locking to the find_agent() function.
........
r101414 | russell | 2008-01-31 13:07:46 -0600 (Thu, 31 Jan 2008) | 3 lines
Move the locking from find_agent() into the agent dialplan function handler to
ensure that the agent doesn't disappear while we're looking at it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
broke realtime configurations which still used the "username" field. This was taken
care of properly when reading from realtime but was not handled properly when updating
a realtime peer. This change also adds a deprecation NOTICE CLI message that will print
if using the deprecated "username" field.
(closes issue #11880)
Reported by: cabal95
Patches:
11880.patch uploaded by putnopvut (license 60)
Tested by: cabal95
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100629 | russell | 2008-01-28 12:34:20 -0600 (Mon, 28 Jan 2008) | 5 lines
For some reason, the use of this strdupa() is leading to memory corruption on
freebsd sparc64. This trivial workaround fixes it.
(closes issue #10300, closes issue #11857, reported by mattias04 and Home-of-the-Brave)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines
Make some deadlock related fixes. These bugs were discovered and reported
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that was just merged from 1.4, so this is a changeover to those APIs to use the
macro versions, so that we properly detect errors from ast_sched_del, instead
of simply ignoring the return values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99977 | oej | 2008-01-23 21:58:20 +0100 (Ons, 23 Jan 2008) | 9 lines
Make sure we don't cancel destruction on calls in CANCEL state, even if we
get 183 while waiting for answer on our CANCEL.
(issue #11736)
Reported by: MVF
Patches:
bug11736.txt uploaded by oej (license 306)
Tested by: MVF
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99979 65c4cc65-6c06-0410-ace0-fbb531ad65f3