EAGAIN unless we didn't read an entire line. If there is a newline at the
end if the read buffer, break, because we got the whole thing.
(reported and patched by bmd)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This version of the patch maintains the original behavior of the code when
not using FastAGI.
(closes issue #10553)
Reported by: juggie
Patches:
res_agi_fgets-4.patch uploaded by juggie (license 24)
res_agi_fgets_1.4svn.patch uploaded by juggie (license 24)
Slight mods by me
Tested by: juggie, festr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mapping, but won't always match the activated on/by access controls. In that
case, the code needs to keep trying features for a match.
(reported by Atis on the asterisk-dev list, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: juggie
Patches:
res_agi_fgets-2.patch uploaded by juggie (license 24)
Tested by: juggie
When using fastagi, fgets() can return before a full line is read. Add explicit
handling for the case where it gets interrupted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
you complete the transfer before the announcement of the parking spot finishes,
then the channel being parked will hear the remainder of the announcement.
These changes make it so that will not happen anymore.
Basically, res_features sets a flag on the channel is playing the announcement
to so that the file streaming core knows that it needs to watch out for a
channel masquerade, and if it occurs, to abort the announcement.
(closes BE-182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: dimas
Don't output a bridge failed warning message if it failed because one of the channels was part of the masquerade process. That is perfectly normal.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mustardman
Patches:
asterisk-mohposition.diff.txt uploaded by jamesgolovich (license 176)
This patch fixes a few problems with music on hold.
* Fix issues with starting at the beginning of a file when it shouldn't.
* Fix the inuse counter to be decremented even if the class had not been
set to be deleted when not in use anymore
* Don't arbitrarily limit the number of MOH files to 255
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
after we already looked it up by name. This causes broken behavior if there is
more than one feature defined with the same digit pattern.
(closes issue #10539, reported by bungalow, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
without reading the whole line when using fastagi. When this happens,
errno was set to EINTR or EAGAIN. This patch accounts for the possibility
and lets fgets continue in that case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
delete classes from memory that were no longer in the config. This patch fixes
that problem as well as another one. Previously, if you reloaded MOH using the
"moh reload" CLI command, which behaved differently than "module reload ...",
MOH had to be stopped on every channel and started again immediately. However,
there was no way to tell what class was being used, so they would all fall back
to the default class.
(closes issue #10139)
Reported by: blitzrage
Patches:
asterisk-10139-advanced.diff.txt uploaded by jamesgolovich (license 176)
Tested by: jamesgolovich
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
McKeehan in issue #10184.
Upon priority change, the resource list is not NULL terminated when
moving an item to the end of the list. This makes Asterisk endlessy
loop whenever it needs to read the list. Jids with different resource and
priority values, like in Gmail's and GoogleTalk's jabber clients put
that problem in evidence.
Upon reception of a 'from' attribute with an empty resource string,
Asterisk crashes when trying to access the found->cap pointer if the
resource list for the given buddy is not empty. This situation is
perfectly valid and must be handled. The Gizmoproject's jabber client
put that problem in evidence.
Also added a few comments in the code as well as a handle for the
capabilities from Gmail's jabber client, which are stored in a caps:c tag
rather than the usual c tag.
Closes issue #10184.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: seanbright
Patches:
res_agi.carefulwrite.1.4.07252007.patch uploaded by seanbright (license 71)
res_agi.carefulwrite.trunk.07252007.patch uploaded by seanbright (license 71)
Allow the "agi_network: yes" line to be printed out in the AGI debug output.
Also, allow partial writes to be handled when writing out this line just like
it is for all of the others.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: kkiely
Instead of directly mucking with the extension/context/priority of the channel we are transferring when it has a PBX simply call ast_async_goto on it. This will ensure that the channel gets handled properly and sent to the right place.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fkasumovic
Patches:
res_conver.patch uploaded by fkasumovic (license #101)
Use the last occurance of . to find the extension, not the first occurance.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: juggie
Patches:
10210-1.4-grr.patch uploaded by juggie (license #24)
Tested by: juggie, blitzrage
Log a warning if someone uses DeadAGI on a live channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75059 | russell | 2007-07-13 15:07:21 -0500 (Fri, 13 Jul 2007) | 6 lines
Ensure that adding a user to the list of users of a specific music on hold
class is not done at the same time as any of the other operations on this list
to prevent list corruption. Using the global moh_data lock for this is not
ideal, but it is what is used to protect these lists everywhere else in the
module, and I am only changing what is necessary to fix the bug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: blitzrage
Patches submitted by: juggie, qwell, me
Tested by: blitzrage
When trying to find a music on hold class to use, try all of the options,
instead of only the first one that is set. Also, change the MusicOnHold
applications to not hang up on the channel when a class can not be found.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74162 65c4cc65-6c06-0410-ace0-fbb531ad65f3
native bridge function. This fixes a problem where when two zap channels are
natively bridged and one does a flash hook, the other channel did not receive
music on hold. (Reported to me directly by Doug Bailey at Digium)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@73512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
