Age | Commit message (Collapse) | Author | Files | Lines |
|
app_voicemail from entering an infinite loop when the same format is specified twice in the format list.
(closes issue #15625)
Reported by: Shagg63
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/429/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@231614 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AST-2009-010
(closes issue #16242)
Reported by: amorsen
Patches:
issue16242.diff uploaded by oej (license 306)
Tested by: amorsen, oej, dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@231441 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@231298 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Spotted by Stuart Henderson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230469 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Solaris will crash if NULL is passed to ast_log. This simple patch simply uses S_OR to
get around this.
(closes issue #15392)
Reported by: yrashk
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@229498 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
characters, they will compare equal.
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: http://svn.digium.com/svn/asterisk/branches/1.4@229360 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Update a WARNING message to give a suggested fix when encountered.
(closes issue #16198)
Reported by: atis
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228896 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@228692 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
passing through the Asterisk core.
(closes issue #15560)
Reported by: jvandal
(closes issue #15709)
Reported by: covici
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228409 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
strings returned from BASE64_DECODE.
(closes issue #15271)
Reported by: chappell
Patches:
base64_fix.patch uploaded by chappell (license 8)
Tested by: kobaz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228378 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15981)
Reported by: slavon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228338 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the filestream.
(closes issue #15495)
Reported by: pdf
Patches:
20090916__issue15495.diff.txt uploaded by tilghman (license 14)
Tested by: pdf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@226138 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225171 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225169 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16103)
Reported by: majorbloodnok
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225105 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The reasoning for these changes are the same as what I wrote in the commit
message for rev 222878.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@224931 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
While this looks like an optimization, it prevents a crash from occurring
when used with certain audiohook callbacks (diagnosed with SVN trunk,
backported to 1.4 to keep the source consistent across versions).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@224855 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
While testing some endpoints that support 16kHz and 32kHz sample rates, some
log messages were generated due to calc_rxstamp() computing timestamps in a way
that produced odd results, so this patch sanitizes the result of the
computations.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@224670 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223486 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The purpose of this code was to have a hangup frame put on the list of deferred
frames. However, the code that read the hangup frame was outside of the scope
of where the hangup frame was declared.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223485 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15104)
Reported by: nblasgen
Patches:
manager-timeout1.diff uploaded by mnicholson (license 96)
Tested by: nblasgen, mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223225 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222878 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ABE-1998
Review: https://reviewboard.asterisk.org/r/395/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222877 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222152 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
suck.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221970 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221776 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15865)
Reported by: kobaz
Patches:
20090915__issue15865.diff.txt uploaded by tilghman (license 14)
Tested by: kobaz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221086 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Call Progress() in your dialplan if you explicitly want progress to be sent.
(Reverts change 216430, closes issue #15957)
Reported by: Pavel Troller on the Asterisk-Dev mailing list
http://lists.digium.com/pipermail/asterisk-dev/2009-September/039897.html
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220288 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15129)
Reported by: bmh
Patches:
20090918__issue15129.diff.txt uploaded by tilghman (license 14)
Review:
https://reviewboard.asterisk.org/r/372/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219653 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219136 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15583)
Reported by: pkempgen
Patches:
20090726__issue15583.diff.txt uploaded by tilghman (license 14)
20090726__issue15583-1.4-4.diff.txt uploaded by pkempgen (license 169)
Tested by: pkempgen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219023 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
matching.
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218867 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216435 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216430 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is the same as rev 216222 in trunk but 1.4 is affected as well
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216369 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12912)
Reported by: rathaus
Tested by: tilghman, russell, dvossel, dbrooks
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216000 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@214701 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@214194 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@214069 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15273)
Reported by: Benjamin Kluck
Patches:
say_c.patch uploaded by Benjamin Kluck (license 803)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@214068 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
parethesis.
(closes issue #15242)
Reported by: Nick_Lewis
Patches:
pbx.c-funcparenthesis.patch2 uploaded by dbrooks (license 790)
pbx.c-funcparenthesis-1.4.diff uploaded by loloski (license 68)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@213970 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to handle.
Without this patch, asterisk creates a temporary file before determining if the
specified command is valid. If invalid, we weren't properly cleaning up the file.
(closes issue #15730)
Reported by: zmehmood
Patches:
M15730.diff uploaded by junky (license 177)
Tested by: zmehmood
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@212763 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211274 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210913 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
developer discussions.
(related to issue #15639)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210066 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #15639)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210065 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15639)
Reported by: nmav
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210064 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #15396)
Reported by: aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209879 f38db490-d61c-443f-a65b-d21fe96a405b
|