https://origsvn.digium.com/svn/asterisk/trunk
................
r137848 | tilghman | 2008-08-14 11:52:43 -0500 (Thu, 14 Aug 2008) | 17 lines
Merged revisions 137847 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r137847 | tilghman | 2008-08-14 11:47:30 -0500 (Thu, 14 Aug 2008) | 9 lines
When creating the secondary subchannel name, it is necessary to compare to
the existing channel name without the "Zap/" or "DAHDI/" prefix, since our
test string is also without that prefix.
(closes issue #13027)
Reported by: dferrer
Patches:
chan_zap-1.4.21.1_fix2.patch uploaded by dferrer (license 525)
(Slightly modified by me, to compensate for both names)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@137849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r136063 | mmichelson | 2008-08-06 10:59:29 -0500 (Wed, 06 Aug 2008) | 24 lines
Merged revisions 136062 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@136064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r135748 | tilghman | 2008-08-05 16:37:35 -0500 (Tue, 05 Aug 2008) | 17 lines
Merged revisions 135747 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135747 | tilghman | 2008-08-05 16:34:46 -0500 (Tue, 05 Aug 2008) | 9 lines
In a conversion to use ast_strlen_zero, the meaning of the flag IAX_HASCALLERID
was perverted. This change reverts IAX2 to the original meaning, which was,
that the callerid set on the client should be overridden on the server, even if
that means the resulting callerid is blank. In other words, if you set
"callerid=" in the IAX config, then the callerid should be overridden to blank,
even if set on the client. Note that there's a distinction, even on realtime,
between the field not existing (NULL in databases) and the field existing, but
set to blank (override callerid to blank).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@135749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r135439 | russell | 2008-08-04 10:02:12 -0500 (Mon, 04 Aug 2008) | 4 lines
Be explicit that we don't want a result from this callback. The callback would
never indicate a match, so nothing would have been returned anyway, but it was
still a poor example of proper usage.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@135440 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r135197 | seanbright | 2008-08-01 15:29:26 -0400 (Fri, 01 Aug 2008) | 6 lines
Remove some code that used to do something but does not anymore, mainly
to get rid of a shadow warning (but this seemed legitimate enough to fix
here instead of in my branch).
Thanks to putnopvut for taking a look as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@135198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r135126 | tilghman | 2008-08-01 11:39:51 -0500 (Fri, 01 Aug 2008) | 9 lines
SIP should use the transport type set in the Moved Temporarily for the next
invite.
(closes issue #11843)
Reported by: pestermann
Patches:
20080723__issue11843_302_ignores_transport_16branch.diff uploaded by bbryant (license 36)
20080723__issue11843_302_ignores_transport_trunk.diff uploaded by bbryant (license 36)
Tested by: pabelanger
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@135127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r133041 | mmichelson | 2008-07-23 12:54:03 -0500 (Wed, 23 Jul 2008) | 15 lines
Merged revisions 133038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133038 | mmichelson | 2008-07-23 12:50:01 -0500 (Wed, 23 Jul 2008) | 7 lines
Small cleanup. Move the declaration of the DAHDI_SPANINFO
variable to the block where it is used. This allows one
less #ifdef HAVE_PRI to clutter things up.
Thanks to Tzafrir for pointing this out on #asterisk-dev
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@133042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r132883 | crichter | 2008-07-23 07:07:15 -0500 (Wed, 23 Jul 2008) | 9 lines
Merged revisions 132826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132826 | crichter | 2008-07-23 13:37:50 +0200 (Mi, 23 Jul 2008) | 1 line
another Fix because of r119585, this commit has broken high frequented BRI Ports, there was a possibility that a channel, that was marked as in_use would be reused later, the corresponding port could got stuck then. So it is recommended to upgrade for chan_misdn users.
........
................
r132966 | kpfleming | 2008-07-23 11:38:28 -0500 (Wed, 23 Jul 2008) | 2 lines
use correct function name... please compile with --enable-dev-mode
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r132795 | mmichelson | 2008-07-22 17:17:09 -0500 (Tue, 22 Jul 2008) | 11 lines
Merged revisions 132777 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
Allow Spiraled INVITEs to work correctly within Asterisk.
Prior to this change, a spiraled INVITE would cause a 482
Loop Detected to be sent to the caller. With this change,
if a potential loop is detected, the Request-URI is inspected
to see if it has changed from what was originally received. If
pedantic mode is on, then this inspection is fully RFC 3261
compliant. If pedantic mode is not on, then a string comparison
is used to test the equality of the two R-URIs.
This has been tested by using OpenSER to rewrite the R-URI
and send the INVITE back to Asterisk.
(closes issue #7403)
Reported by: stephen_dredge
Modified:
branches/1.4/channels/chan_sip.c
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
