The configuration option for allowing hosts to make non-token-based calls
is 'calltokenoptional', not 'calltokenignore'. (reported on asterisk-users)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@230246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The example given in the issue report is that of [234] and [246], which have
these characteristics, yet they are clearly not equivalent. The code still
uses these two characteristics, yet when the two scores compare equal, an
additional check will be done to compare all characters within the class to
verify equality.
(closes issue #15421)
Reported by: jsmith
Patches:
20091109__issue15421__2.diff.txt uploaded by tilghman (license 14)
Tested by: jsmith, thedavidfactor
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@229360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems the translation core would actually consider g726aal2 -> g726 -> signed linear
to be a quicker path then g726aal2 -> signed linear which exposed this problem.
(closes issue #15504)
Reported by: globalnetinc
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@229281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ExternalIVR uses the D tag for two different event types. This documents that
behavior and how to differentiate between the two cases. Also includes a minor
spelling fix and clarification
(closes issue #16211)
Reported by: thedavidfactor
Patches:
externalivr.txt.20091109.1507.patch uploaded by thedavidfactor (license 903)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@229191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After writing to the audiohook list in ast_write(), frames
were being freed incorrectly. Under certain conditions this
resulted in a double free crash.
(closes issue #16133)
Reported by: wetwired
(closes issue #16045)
Reported by: bluecrow76
Patches:
issue16045.diff uploaded by dvossel (license 671)
Tested by: bluecrow76, dvossel, habile
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@228692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For reasons not yet known, it appears possible for an ast_frame
to have a datalen greater than zero while the actual data is NULL
during Packet Loss Concealment. Most codecs don't support PLC so
this doesn't affect them. This patch catches the malformed frame
and prevents the crash from occuring. Additional efforts to determine
why it is possible for a frame to look like this are still being
investigated.
(issue #16979)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@228418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Crash related to chan_misdn connection. Patch submitted by gknispel_proformatique, tested
by francesco_r. "I have many crash since i have upgraded to Asterisk 1.4.27-rc2. Attached
a full bt." This patch zeros out an ast_frame.
(closes issue #16041)
Reported by: francesco_r
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@228078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logic to detect if a requested file is indeed a different file from the
current file was incorrect. The main issue being confusion of the use of
filename_base which was previously set without pathing information and then
compared to another full path. Robust file comparison logic has been added
to properly check if two files are the same even if symlinks are used.
(closes issue #15313)
Reported by: caspy
Patches:
20091103__issue15313__1.4.diff.txt uploaded by jpeeler (license 325)
but mostly tilghman's work
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@227944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new code, media level proprieties should no longer be confused with session level proprieties. This change also reorganizes some of the SDP parsing code which should make it easier to manage in the future.
(closes issue #14994)
Reported by: frawd
Tested by: frawd, mnicholson, file
Review: https://reviewboard.asterisk.org/r/385/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@227758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP channel names were supposed to be unique by way of a name suffix derived from the
pointer to the channel's private data. Uniqueness was preserved on 32-bit systems, but
not on 64-bit systems. This patch, as suggested by kpfleming, replaces this suffix with
a simple incremented unsigned int.
(closes issue #15152)
Reported by: palbrecht
Review: https://reviewboard.asterisk.org/r/420/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
while the called party had not yet answered.
This was fixed by introducing an argument to the 'n' option which, when enabled, removes the introduction
file under all scenarios. This was done to preserve the behavior that has existed for quite some time.
(closes issue #14674)
Reported by: ulogic
Patches:
bug14674.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the documentation in sip.conf.sample in order to make it more clear
that directmedia/canreinvite do not cause Asterisk to ignore reINVITEs. It
is only used to stop Asterisk from generating a reINVITE, but does not stop
it from accepting them if necessary.
(closes issue #15644)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
David Vossel
Kevin P. Fleming
Matthew Nicholson
Michiel van Baak
Joshua Colp
David Brooks
Tilghman Lesher
David Ruggles
Leif Madsen
Jason Parker
Jeff Peeler
Richard Mudgett
Olle Johansson