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
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
blitzrage's test machines. It was one of the situations where he was seeing
hung channels, and may be the cause of some of the reports from other people.
(related to issue #9235)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
crashes while we are trying to find a workaround.
Iksemel development seems to have stalled and we might have to stop using the
TCP/TLS connections in that library and use our own, which would scale better
from a poll/select perspective I guess. It would also make it easier to migrate
to OpenSSL and stop Asterisk from depending on both OpenSSL and GnuTLS.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@68027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a bug in the iksemel library, this will not work if you are using GTLS
in the connection. That's being investigated. If you figure out a way to handle
that without us having to patch iksemel, let us know in the bug report. Thanks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
snmp library more than once without completely unloading the module and loading
it again.
(issue #9571, reported by hristo, additional helpful debug information from festr,
patch from me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
