Age | Commit message (Collapse) | Author | Files | Lines |
|
hangups while playing back announcements.
(closes issue #16005)
Reported by: falves11
Patches:
dial-announce-hangup-fix1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, falves11
Review: https://reviewboard.asterisk.org/r/407/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@227827 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
if the caller hung up
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: http://svn.digium.com/svn/asterisk/branches/1.4@226889 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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225103 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
enabled that should prevent it.
(closes issue #14763)
Reported by: cupotka
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@224565 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
While waiting for an answer, don't send progress for branched calls
for which ringing was sent.
(closes issue #15028)
Reported by: fnordian
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223804 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223550 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223213 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
|
|
chanspy_ds_chan_fixup() is called with the channel locked.
(closes issue #15965)
Reported by: atis
Patches:
chanspy-deadlock-fix1.diff uploaded by mnicholson (license 96)
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@220907 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
|
|
new values.
This change introduces a configuration version variable, which ensures that
connections with the old values are not reused but are allowed to expire
normally.
(closes issue #15934)
Reported by: viniciusfontes
Patches:
20090922__issue15934.diff.txt uploaded by tilghman (license 14)
Tested by: viniciusfontes
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219816 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the change does nothing.
(closes issue #15492)
Reported by: cbbs70a
Patches:
20090713__issue15492.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218730 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also, not in the original bug report, but related fields are accountcode and
musicclass, and the inheritance of datastores.
(closes issue #15372)
Reported by: Romik
Patches:
20090828__issue15372.diff.txt uploaded by tilghman (license 14)
Tested by: cervajs
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218577 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
again.
(issue #15055, SWP-129)
Reported by: jthurman
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218331 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15100)
Reported by: lmsteffan
Patches:
(modified) pickup.patch uploaded by lmsteffan (license 779)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@218223 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
answer.
(Fixes AST-228)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217989 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
conference are not heard.
(closes issue #14588)
Reported by: voipas
Patches:
20090716__issue14588__2.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, twisted, tilghman
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217156 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
|
|
In general channel names are in the form Foo/Bar-Z, but the channel name
could have multiple hyphens and look like Foo/B-a-r-Z. Use strrchr to
truncate the channel name at the last hyphen.
(closes issue #15810)
Reported by: dhubbard
Patches:
dw-softhangup-1.4.patch uploaded by dhubbard (license 733)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@215270 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@213283 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15699)
Reported by: edantie
Patches:
mixmonitor.patch uploaded by edantie (license 862)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@213103 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The additional checks prevent generation of false TRANSFER events in certain situations.
(closes issue #14536)
Reported by: aragon
Patches:
queue-log-xfer-fix1.diff uploaded by mnicholson (license 96)
Tested by: aragon, mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211953 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(ABE-1936)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211112 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is a partial revert of revision 82590, which was an attempted cleanup,
but in reality, it broke QUEUE_MEMBER_LIST, which has always been intended
as a method by which component interfaces could be queried from the queue.
Membername isn't useful here, because that field cannot be used to obtain
further information about the member. See the documentation on
QUEUE_MEMBER_LIST, RemoveQueueMember, QUEUE_MEMBER_PENALTY, and the various
AMI commands which take a member argument for further justification.
(closes issue #15664)
Reported by: rain
Patches:
app_queue-queue_member_list.diff uploaded by rain (license 327)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211038 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
|
|
When Milliwatt() was changed internally to use Playtones() so that the proper
tone was used, it introduced a drop in gain in the output signal. So, use
the playtones API directly and specify a volume argument such that the output
matches the gain of the original Milliwatt() code.
(closes issue #15386)
Reported by: rue_mohr
Patches:
issue_15386.rev2.diff uploaded by russell (license 2)
Tested by: rue_mohr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208622 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This does not indicate an error. A return of -1 just means that the channel
has been hung up.
(reported in #asterisk-dev)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208592 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If a caller were to hang up while a periodic announcement or position
were being said, the return value for those functions would incorrectly
indicate that the caller was still in the queue. With these changes,
the problem does not occur.
(closes issue #14631)
Reported by: latinsud
Patches:
queue_announce_ghost_call2.diff uploaded by latinsud (license 745)
(with small modification from me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@205349 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15400)
Reported by: aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@204012 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
as seconds.
Also, the inequality was reversed. The warning, if triggered, was "Max silence should
be less than minmessage or you may get empty messages", which should have been logged
if max silence was greater than minmessage, but the check was for less than.
Also, conforming if statement to coding guidelines.
closes issue #15331)
Reported by: markd
Review: https://reviewboard.asterisk.org/r/293/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@203719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file. It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition. To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.
(closes issue #15259)
Reported by: travisghansen
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/283/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@201423 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@200991 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15056)
Reported by: p_lindheimer
Patches:
05292009_bug15056.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@198251 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize awat the Local
channel when using this option.
(issue #14829)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197895 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
command.
This change relates to r184980, which was a backport of the state interface
changes to app_queue from trunk. trunk and all of the 1.6.x branches are not
affected.
'queue add member' allows for specifying an interface to use for device state
when adding a queue member via CLI, but the validation code was not properly
updated to reflect this optional argument.
(closes issue #15198)
Reported by: loloski
Patches:
05272009_app_queue.diff uploaded by seanbright (license 71)
Tested by: loloski
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197024 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15050)
Reported by: pmhaddad
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195635 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14889)
Reported by: jaroth
Patches:
app_voicemail.c.patch uploaded by msirota (license 758)
Tested by: msirota, BlargMaN
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195520 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14846)
Reported by: pj
Patches:
20090413__bug14846__1.4.diff.txt uploaded by tilghman (license 14)
20090507__issue14846__1.6.0.diff.txt uploaded by tilghman (license 14)
20090507__issue14846__1.6.1.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195366 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
situations.
This involves setting a proper cdr disposition coresponding to the given
failure condition and ensuring the proper information is stored in the cdr
record.
(closes issue #13691)
Reported by: dferrer
Tested by: mnicholson
(closes issue #13637)
Reported by: atis
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194028 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
issue.
(closes issue #14508)
Reported by: tiziano
Patches:
20090221_2_wrongmailbox.diff.txt uploaded by tiziano (license 377)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@193955 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This allows more concurrent extensions to be copied for a single voicemail,
without creating a possibility of upsetting existing users, where a dialplan
could run out of stack space where it had run fine before. Alternatively,
we could have allocated off the heap, but that is a larger change and would
have increased the chance for instability introduced by this change.
This is really solved starting in 1.6.0.11, as the use of an ast_str buffer
allows an unlimited number of extensions (up to available memory). We
additionally create a new warning message when the buffer length is exceeded,
permitting administrators to see an issue after the fact, whereas previously
the list was silently truncated.
(closes issue #14739)
Reported by: p_lindheimer
Patches:
20090417__bug14739.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@193755 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the caller hung up.
(closes issue #13624)
Reported by: sgenyuk
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@192429 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes a case where a certain message could get played twice.
(closes issue #13155)
Reported by: greenfieldtech
Patches:
app_voicemail.c.multi-lang-patch uploaded by greenfieldtech (license 369)
Tested by: greenfieldtech
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191778 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191629 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Similar to seanbright's commit 191422, this moves some static buffers
to be defined outside of for loops since it is undefined if memory
will be re-used or if the stack will grow with each iteration of the
loop.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191628 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
According to Kevin, it is unspecified as to whether a variable defined inside
a block is allocated once by the compiler or for each pass through the block
(loops being the only interesting case), so just define these before we get
into our loop to be sure.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191422 f38db490-d61c-443f-a65b-d21fe96a405b
|