https://origsvn.digium.com/svn/asterisk/trunk
................
r132703 | oej | 2008-07-22 22:46:11 +0200 (Tis, 22 Jul 2008) | 17 lines
Merged revisions 132645 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132645 | oej | 2008-07-22 22:10:26 +0200 (Tis, 22 Jul 2008) | 9 lines
The most common question on the #asterisk iRC channel and on mailing lists
seems to be in regards to an error message when retransmit fails. This
is frequently misunderstood as a failure of Asterisk, not a failure of
the network to reach the other party.
This document tries to assist the Asterisk user in sorting out these
issues by explaining the logic and pointing at some possible
causes. Hopefully, we will get other questions now :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r132721 | kpfleming | 2008-07-22 16:21:56 -0500 (Tue, 22 Jul 2008) | 14 lines
Merged revisions 132712 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132712 | kpfleming | 2008-07-22 16:17:23 -0500 (Tue, 22 Jul 2008) | 6 lines
ensure that if any alarms exist at channel creation time, they are handled identically to if they occurred later, so that later alarm clearing will work properly and 'make sense'
(closes issue #12160)
Reported by: tzafrir
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r132466 | bbryant | 2008-07-21 12:22:02 -0500 (Mon, 21 Jul 2008) | 3 lines
Fix an issue in iax2 where a call that's been rejected still kept an open channel on the side that attempted to make the call (not the side of the
call that rejected the call). Changes were load tested and also approved by Russell.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r131868 | jpeeler | 2008-07-17 17:40:00 -0500 (Thu, 17 Jul 2008) | 6 lines
Add configuration option to chan_dahdi.conf to allow buffering policy and number of buffers to be configured per channel. Syntax:
buffers=<num of buffers>,<policy>
Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate".
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@131869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r130890 | tilghman | 2008-07-14 18:59:54 -0500 (Mon, 14 Jul 2008) | 16 lines
Merged revisions 130889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130889 | tilghman | 2008-07-14 18:59:13 -0500 (Mon, 14 Jul 2008) | 8 lines
Override the callerid in all cases when the callerid is set in the user, not
just when a remote callerid is set. Also, if not set in the user, allow the
remote CallerID to pass through.
(closes issue #12875)
Reported by: dimas
Patches:
20080714__bug12875.diff.txt uploaded by Corydon76 (license 14)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r130126 | tilghman | 2008-07-11 12:29:24 -0500 (Fri, 11 Jul 2008) | 17 lines
Merged revisions 130102 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130102 | tilghman | 2008-07-11 11:50:42 -0500 (Fri, 11 Jul 2008) | 9 lines
Pass the devicestate from an underlying channel up through the Agent channel.
This should make the Agent always report the correct device state, even when
the underlying channel is used for other purposes.
(closes issue #12773)
Reported by: davidw
Patches:
20080710__bug12773.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r130040 | kpfleming | 2008-07-11 10:57:17 -0500 (Fri, 11 Jul 2008) | 12 lines
Merged revisions 130039 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130039 | kpfleming | 2008-07-11 10:41:56 -0500 (Fri, 11 Jul 2008) | 4 lines
add support for a configuration parameter for 'inband audio during RELEASE', which is currently mandatory in libpri-1.4.4 but will become configurable in libpri-1.4.5 later today
(related to issue #13042)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r128951 | oej | 2008-07-08 12:02:12 +0200 (Tis, 08 Jul 2008) | 19 lines
Merged revisions 128950 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r128950 | oej | 2008-07-08 11:52:21 +0200 (Tis, 08 Jul 2008) | 11 lines
Don't hangup the call if we can't resolve the Contact if there's a proxy
route set for the call.
----
This comment was added a while ago and today it hit me badly.
/* OEJ: Possible issue that may need a check:
If we have a proxy route between us and the device,
should we care about resolving the contact
or should we just send it?
*/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@128952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r128640 | mmichelson | 2008-07-07 12:09:11 -0500 (Mon, 07 Jul 2008) | 18 lines
Merged revisions 128639 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r128639 | mmichelson | 2008-07-07 12:02:28 -0500 (Mon, 07 Jul 2008) | 10 lines
By using the iaxdynamicthreadcount to identify a thread, it was possible
for thread identifiers to be duplicated. By using a globally-unique monotonically-
increasing integer, this is now avoided.
(closes issue #13009)
Reported by: jpgrayson
Patches:
chan_iax2_dyn_threadnum.patch uploaded by jpgrayson (license 492)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@128641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r128524 | oej | 2008-07-06 22:11:37 +0200 (Sön, 06 Jul 2008) | 5 lines
- Fixing issues with "sip show settings"
- Adding IP address for TCP and/or TLS too if auto-domain is enabled and
binding to a different IP address
- Fixing documentation in sip.conf.sample
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@128539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r128290 | oej | 2008-07-05 23:55:57 +0200 (Lör, 05 Jul 2008) | 5 lines
Adding doxygen comments to missing parts, moving some #define
...trying to get my head around the thoughts behind the TCP/TLS stuff
and figure out what needs to be done to make it useful...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@128293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r128122 | mattf | 2008-07-04 22:26:42 -0500 (Fri, 04 Jul 2008) | 1 line
Add option to wait to be able to explicitly send ACM via the Proceeding() application in the dialplan. Also minor documentation update explaining how to setup multiple signalling links within a linkset
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@128124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r127793 | murf | 2008-07-03 11:16:44 -0600 (Thu, 03 Jul 2008) | 38 lines
Merged revisions 127663 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r127663 | murf | 2008-07-02 18:16:25 -0600 (Wed, 02 Jul 2008) | 30 lines
The CDRfix4/5/6 omnibus cdr fixes.
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@127830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r127779 | oej | 2008-07-03 18:25:59 +0200 (Tor, 03 Jul 2008) | 4 lines
Revert some logic for session timers. We do send in-dialog requests that should not have session-timer
require headers, like MESSAGE and REFER. So in the future, only add them on requests and responses
that are related to INVITEs and re-INVITEs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@127790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r127297 | tilghman | 2008-07-01 21:48:43 -0500 (Tue, 01 Jul 2008) | 12 lines
Change the global timer B to be dependent on the value of the T1 timer, as
recommended in RFC 3261, instead of being hardcoded to 32 seconds. This is
important for LANs, as it allows autocongestion to occur much more quickly, if
desired by the local PBX administrator. It also corrects a bug: if the T1
timer was increased beyond 500ms, then timer B would have been set at a much
lower value than recommended.
(closes issue #12544)
Reported by: kactus
Patches:
20080616__bug12544.diff.txt uploaded by Corydon76 (license 14)
Tested by: kactus
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@127298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r126517 | oej | 2008-06-30 15:03:53 +0200 (MÃ¥n, 30 Jun 2008) | 20 lines
The following patch with some changes for trunk...
Merged revisions 126516 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r126516 | oej | 2008-06-30 14:50:55 +0200 (MÃ¥n, 30 Jun 2008) | 10 lines
Send all responses to an INVITE reliably, so that we retransmit if we don't get an ACK and
also fail if we don't get the very same precious ACK. Based on patch by tsearle, with
my own additions.
(closes issue #12951)
Reported by: tsearle
Patches:
busy_retransmit.patch uploaded by tsearle (license 373)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@126518 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r125891 | bbryant | 2008-06-27 11:28:06 -0500 (Fri, 27 Jun 2008) | 6 lines
Change the way that the transport option works for sip users. transport will now take multiple arguments, the first one listed will be the one used
for new dialogs, and the rest listed will be acceptable ways for that peer to contact us. This fixes a minor bug where, because SIP TCP/UDP run on
the same port, could cause a TCP peer to be saved in the ast_db. There will also be warnings when a transport is changed for an unexpected reason.
(issue #12799)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@125892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r125333 | kpfleming | 2008-06-26 10:50:07 -0500 (Thu, 26 Jun 2008) | 13 lines
Merged revisions 125327 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125327 | kpfleming | 2008-06-26 10:30:33 -0500 (Thu, 26 Jun 2008) | 5 lines
ensure that (whenever possible) if we generate a log message because an ioctl() call to DAHDI/Zaptel failed, that we include the reason it failed by including the stringified error number
(issue AST-80)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@125334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r125138 | kpfleming | 2008-06-25 18:05:28 -0500 (Wed, 25 Jun 2008) | 18 lines
Merged revisions 125132 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125132 | kpfleming | 2008-06-25 17:21:30 -0500 (Wed, 25 Jun 2008) | 10 lines
allow tonezone to live in a different place than DAHDI/Zaptel, since dahdi-tools and dahdi-linux are now separate packages and can be installed in different places
don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@125146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r124316 | tilghman | 2008-06-20 15:17:04 -0500 (Fri, 20 Jun 2008) | 16 lines
Merged revisions 124315 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r124315 | tilghman | 2008-06-20 15:16:02 -0500 (Fri, 20 Jun 2008) | 8 lines
When using a Local channel, started by a call file, with a destination of an
AGI script, the AGI script does not always get notified of a hangup if the
underlying channel hangs up early.
(closes issue #11833)
Reported by: IgorG
Patches:
local_hangup-v1.diff uploaded by IgorG (license 20)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@124317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r123546 | bbryant | 2008-06-17 16:46:57 -0500 (Tue, 17 Jun 2008) | 5 lines
Updates all usages of ast_tcptls_session_instance to be managed by reference counts so that they only get destroyed when all threads are done using
them, and memory does not get free'd causing strange issues with SIP.
This code was originally written by russellb in the team/group/issue_11972/ branch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@123547 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r123334 | mmichelson | 2008-06-17 13:09:54 -0500 (Tue, 17 Jun 2008) | 19 lines
Merged revisions 123333 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r123333 | mmichelson | 2008-06-17 13:09:16 -0500 (Tue, 17 Jun 2008) | 11 lines
Cisco BTS sends SIP responses with a tab between the Cseq number and
SIP request method in the Cseq: header. Asterisk did not handle this
properly, but with this patch, all is well.
(closes issue #12834)
Reported by: tobias_e
Patches:
12834.patch uploaded by putnopvut (license 60)
Tested by: tobias_e
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@123335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r123111 | tilghman | 2008-06-16 14:23:51 -0500 (Mon, 16 Jun 2008) | 16 lines
Merged revisions 123110 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r123110 | tilghman | 2008-06-16 14:21:58 -0500 (Mon, 16 Jun 2008) | 8 lines
People expect that if "hasvoicemail" is set in users.conf, even if "mailbox"
isn't set, that SIP will detect a mailbox.
(closes issue #12855)
Reported by: PLL
Patches:
20080614__bug12855__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: PLL
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@123112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r122920 | file | 2008-06-16 09:32:02 -0300 (Mon, 16 Jun 2008) | 14 lines
Merged revisions 122919 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122919 | file | 2008-06-16 09:31:09 -0300 (Mon, 16 Jun 2008) | 6 lines
Only compare the first 15 characters so that even if the charset is specified we still accept it as SDP.
(closes issue #12803)
Reported by: lanzaandrea
Patches:
chan_sip.c.diff uploaded by lanzaandrea (license 496)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@122921 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Olle Johansson
Tilghman Lesher
Mark Michelson
Kevin P. Fleming
Brett Bryant
Jeff Peeler
Matthew Fredrickson
Russell Bryant
Luigi Rizzo
Steve Murphy
Sean Bright
Joshua Colp
Philippe Sultan
Michiel van Baak