Matthew Jordan [Sat, 19 Jan 2013 00:19:19 +0000 (00:19 +0000)]
Fix astcanary startup problem due to wrong pid value from before daemon call
When Asterisk forks itself into the background via a call to daemon, it must
re-set the pid value of the new process. Otherwise, astcanary gets the pid
value of the process before the fork, which prevents it from running. Asterisk
eventually starts lowering its priority, as it can no longer communicate
with the proverbial canary in the coal mine.
This patch ensures that the correct process identifier is used by astcanary.
Note that this is getting committed to 10 as a regression fix.
(closes issue ASTERISK-20947)
Reported by: Jakob Hirsch
Tested by: mjordan
patches:
asterisk-10.12.0.astcanary_ppid.diff uploaded by Jakob Hirsch (license 6113)
........
Merged revisions 379509 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379510 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 379513 from http://svn.asterisk.org/svn/asterisk/branches/11
David M. Lee [Fri, 18 Jan 2013 22:42:38 +0000 (22:42 +0000)]
Up the minimum OS X version to 10.6.
* This allows us to remove some special-case build logic.
* 10.5 is down to less that 8% of the OS X market share. 10.4 is down to
under 2%.
* Apple is no longer releasing security updates for 10.5 and earlier.
Kinsey Moore [Fri, 18 Jan 2013 21:52:18 +0000 (21:52 +0000)]
Fix regression in Confbridge user count
When the restructuring work got committed to Confbridge in r375470 to
fix many open issues, it caused a regression in the reported count of
users when conference information was requested via CLI or manager.
This corrects the user count and user information displayed when
listing conference information from the CLI and manager.
(closes issue ASTERISK-20938)
Reported By: Timo Teras
Patches:
confbridge-list.patch uploaded by Timo Teras (license 5409)
........
Merged revisions 379478 from http://svn.asterisk.org/svn/asterisk/branches/11
Jonathan Rose [Fri, 18 Jan 2013 18:25:56 +0000 (18:25 +0000)]
app_voicemail: Improve msg_id handling
app_voicemail will no longer issue error messages when it retrieves an msg_id
with a NULL value from realtime and will instead simply populate the msg_id
field with a newly generated msg_id. In addition, this patch changes the way
msg_ids are generated to eliminate certain causes of duplicate IDs appearing
within a single system. In addition, when messages are copied, they will now
receive a new msg_id.
(closes issue ASTERISK-20717)
Reported by: Alec Davis
Review: https://reviewboard.asterisk.org/r/2220/
........
Merged revisions 379460 from http://svn.asterisk.org/svn/asterisk/branches/11
Mark Michelson [Fri, 18 Jan 2013 15:42:10 +0000 (15:42 +0000)]
Add threadpool support to Asterisk.
This commit consists of two parts.
Part one changes the taskprocessor API to be less self-contained.
Instead, the taskprocessor is now more of a task queue that informs
a listener of changes to the queue. The listener then has the responsibility
of executing the tasks as it pleases. There is a default listener implementation
that functions the same way as "classic" taskprocessors, in that it creates
a single thread for tasks to execute in. Old users of taskprocessors have
not been altered and still function the same way.
Part two introduces the threadpool API. A threadpool is a special type of
taskprocessor listener that has multiple threads associated with it. The threadpool
also has an optional listener that can adjust the threadpool as conditions change.
In addition the threadpool has a set of options that can allow for the threadpool
to grow and shrink on its own as tasks are added and executed.
Both set of changes contain accompanying unit tests.
(closes issue ASTERISK-20691)
Reported By: Matt Jordan
David M. Lee [Fri, 18 Jan 2013 05:31:23 +0000 (05:31 +0000)]
Fix Record-Route parsing for large headers.
Record-Route parsing copied the header into a char[256] array, which can
be a problem if the header is longer than that. This patch parses the
header in place, without the copy, avoiding the issue.
In addition to the original patch, I added a unit test for the new
get_in_brackets_const function.
(closes issue ASTERISK-20837)
Reported by: Corey Farrell
Patches:
chan_sip-build_route-optimized-rev1.patch uploaded by Corey Farrell (license 5909)
(with minor changes by dlee)
........
Merged revisions 379392 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379393 from http://svn.asterisk.org/svn/asterisk/branches/11
Mark Michelson [Thu, 17 Jan 2013 16:04:10 +0000 (16:04 +0000)]
Address David's latest feedback on reviewboard:
* Add a max_size option for threadpools. Also added a test for this option.
* Fixed comments to be more accurate and have fewer typos.
* Updated copyright dates on new files.
Fix issue where chan_mobile fails to bind to first available port
Per the bluez API, in order to bind to the first available port, the rc_channel
field of the socket addressing structure used to bind the socket should be set
to 0. Previously, Asterisk had set the rc_channel field set to 1, causing it
to connect to whatever happens to be on port 1.
We could probably not explicitly set rc_channel to 0 since we memset the struct
earlier, but explicitly setting it will hopefully prevent someone from coming
in and setting it to some explicit port in the future.
(closes issue ASTERISK-16357)
Reported by: challado
Tested by: Alexander Heinz, Nikolay Ilduganov, benjamin, eliafino, David van Geyn
patches:
ASTERISK-16357.diff uploaded by Nikolay Ilduganov (license 6253)
........
Merged revisions 379342 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379343 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Matthew Jordan [Thu, 17 Jan 2013 02:32:34 +0000 (02:32 +0000)]
Fix issue where chan_mobile fails to bind to first available port
Per the bluez API, in order to bind to the first available port, the rc_channel
field of the socket addressing structure used to bind the socket should be set
to 0. Previously, Asterisk had set the rc_channel field set to 1, causing it
to connect to whatever happens to be on port 1.
We could probably not explicitly set rc_channel to 0 since we memset the struct
earlier, but explicitly setting it will hopefully prevent someone from coming
in and setting it to some explicit port in the future.
(closes issue ASTERISK-16357)
Reported by: challado
Tested by: Alexander Heinz, Nikolay Ilduganov, benjamin, eliafino, David van Geyn
patches:
ASTERISK-16357.diff uploaded by Nikolay Ilduganov (license 6253)
........
Merged revisions 379342 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379343 from http://svn.asterisk.org/svn/asterisk/branches/11
Let documentation reference links specify which module they're linking to
Again, since res_jabber/res_xmpp have duplicate APIs, their documentation ref
links have to specify which reference they're referring to. The various
documentation parsers can interpret the module attribute however they want
in order to construct the appropriate links.
........
Merged revisions 379228 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r379231 | rmudgett | 2013-01-16 11:49:52 -0600 (Wed, 16 Jan 2013) | 10 lines
chan_misdn: Fix compile error.
(issue ASTERISK-15456)
........
Merged revisions 379226 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379230 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r379233 | rmudgett | 2013-01-16 12:09:28 -0600 (Wed, 16 Jan 2013) | 8 lines
Reduce call-id logging resource usage.
Since there is no need for the call-id logging ao2 object to have a lock,
don't create it with one.
........
Merged revisions 379232 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Matthew Jordan [Wed, 16 Jan 2013 17:46:15 +0000 (17:46 +0000)]
Let documentation reference links specify which module they're linking to
Again, since res_jabber/res_xmpp have duplicate APIs, their documentation ref
links have to specify which reference they're referring to. The various
documentation parsers can interpret the module attribute however they want
in order to construct the appropriate links.
........
Merged revisions 379228 from http://svn.asterisk.org/svn/asterisk/branches/11
Add module tags to documentation for res_jabber/res_xmpp
Since res_jabber/res_xmpp provide the same APIs (app/func/manager/etc.),
the XML documentation for each needs to call out which module is providing
the documentation. The module attribute has been added to the various XML
fragments for this purpose.
........
r379210 | mjordan | 2013-01-16 09:30:20 -0600 (Wed, 16 Jan 2013) | 4 lines
Update the dtd to actually *support* the module attribute in all elements
Mea culpa.
........
Merged revisions 379209-379210 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Add module tags to documentation for res_jabber/res_xmpp
Since res_jabber/res_xmpp provide the same APIs (app/func/manager/etc.),
the XML documentation for each needs to call out which module is providing
the documentation. The module attribute has been added to the various XML
fragments for this purpose.
........
r379210 | mjordan | 2013-01-16 09:30:20 -0600 (Wed, 16 Jan 2013) | 4 lines
Update the dtd to actually *support* the module attribute in all elements
Mea culpa.
........
Merged revisions 379209-379210 from http://svn.asterisk.org/svn/asterisk/branches/11
The parser for SMS messages would incorrectly parse out the from number.
The parsing would incorrectly start scanning for the from number at the
same index as the first double quote ("); this would inadvertently cause
it to treat the first double quote as the terminating double quote for
the from number as well.
The SMSSRC should now populate correctly.
(closes issue ASTERISK-16822)
Reported by: menschentier
Tested by: Jonas Falck
patches:
fixSMSSRC.patch uploaded by jonax (license 6320)
Matthew Jordan [Wed, 16 Jan 2013 04:14:38 +0000 (04:14 +0000)]
Fix parsing SMSSRC for SMS messages
The parser for SMS messages would incorrectly parse out the from number.
The parsing would incorrectly start scanning for the from number at the
same index as the first double quote ("); this would inadvertently cause
it to treat the first double quote as the terminating double quote for
the from number as well.
The SMSSRC should now populate correctly.
(closes issue ASTERISK-16822)
Reported by: menschentier
Tested by: Jonas Falck
patches:
fixSMSSRC.patch uploaded by jonax (license 6320)
"First this patch adds general support for busy detection. It also adds support
for the ECAM command at Sony Ericsson phones and also signals busy when only
early media was received but the call got not answered."
Set the INVALID_EXTEN channel variable when chan_misdn forces the 'i' extension
The chan_misdn channel driver will send a channel with an invalid destination
to the 'i' extension itself if said extension can be reached. It forgot,
however, to set the INVALID_EXTEN channel variable when it bounces the channel
to this extension. Dialplan writers everywhere moaned at yet another
inconsistency.
This is yet another example of why duplicating logic in multiple places results
in bugs that stick around in Jira for just under three years.
Yes: ASTERISK-15456 was created on January 18th, 2010. Patch committed on
January 15th, 2013. Ouch.
(closes issue ASTERISK-15456)
Reported by: Thomas Omerzu
patches:
chan_misdn_invalid.patch2 uploaded by Thomas Omerzu (license 5927)
........
Merged revisions 379145 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379146 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Matthew Jordan [Wed, 16 Jan 2013 00:16:22 +0000 (00:16 +0000)]
Set the INVALID_EXTEN channel variable when chan_misdn forces the 'i' extension
The chan_misdn channel driver will send a channel with an invalid destination
to the 'i' extension itself if said extension can be reached. It forgot,
however, to set the INVALID_EXTEN channel variable when it bounces the channel
to this extension. Dialplan writers everywhere moaned at yet another
inconsistency.
This is yet another example of why duplicating logic in multiple places results
in bugs that stick around in Jira for just under three years.
Yes: ASTERISK-15456 was created on January 18th, 2010. Patch committed on
January 15th, 2013. Ouch.
(closes issue ASTERISK-15456)
Reported by: Thomas Omerzu
patches:
chan_misdn_invalid.patch2 uploaded by Thomas Omerzu (license 5927)
........
Merged revisions 379145 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379146 from http://svn.asterisk.org/svn/asterisk/branches/11
Matthew Jordan [Tue, 15 Jan 2013 23:54:34 +0000 (23:54 +0000)]
Add busy detection to chan_mobile
From the patch author:
"First this patch adds general support for busy detection. It also adds support
for the ECAM command at Sony Ericsson phones and also signals busy when only
early media was received but the call got not answered."
Mark Michelson [Tue, 15 Jan 2013 20:15:00 +0000 (20:15 +0000)]
Address further review feedback from David Lee.
* Clarify some documentation
* Change copyright date of taskprocessor files
* Address potential issue of creating taskprocessor with listener if
taskprocessor with that name exists already
Mark Michelson [Tue, 15 Jan 2013 18:40:36 +0000 (18:40 +0000)]
Remove alloc and destroy callbacks from the taskprocessor.
Now user data is allocated by the creator of the taskprocessor
listener and that user data is passed into ast_taskprocessor_listener_alloc().
Similarly, freeing of the user data is left up to the user himself. He can
free the data when the taskprocessor shuts down, or he can choose to hold
onto it if it makes sense to do so.
This, unsurprisingly, makes threadpool allocation a LOT cleaner now.
Fix XML encoding of 'identity display' in NOTIFY messages, continued.
When r378933 was merged into 1.8, it should have also escaped
remote_display, since it will have the same XML encoding problem when
the caller/callee roles are reversed.
Merged revisions 379001 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379020 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r379023 | dlee | 2013-01-14 09:58:01 -0600 (Mon, 14 Jan 2013) | 20 lines
Masquerades are an insane implementation detail within Asterisk. It generates
a number of useless and confusing events, and manipulates channels in a way
that semantically doesn't make sense. I've given a fairly thorough review of
masquerade code and its usage on the wiki at
https://wiki.asterisk.org/wiki/x/IwBRAQ.
While ultimately it makes the most sense to abandon masquerades altogether,
it will take some time to completely irradicate. Even then, there may always
be code that's not worth rewriting to get rid of the masquerade.
This patch does two things to make masquerades slightly less insane:
* When swapping the names of the original and clone channel, only emit a
single rename event of original -> original<ZOMBIE>. The original code
issued three rename events to accomplish the same end.
* In addition to swapping the names of the channels, also swap their
uniqueid's. This allows the 'Uniqueid' field to be used as a stable
identifier for a channel from and external interface, such as AMI.
David M. Lee [Mon, 14 Jan 2013 15:58:01 +0000 (15:58 +0000)]
Gently reduce masquerade insanity
Masquerades are an insane implementation detail within Asterisk. It generates
a number of useless and confusing events, and manipulates channels in a way
that semantically doesn't make sense. I've given a fairly thorough review of
masquerade code and its usage on the wiki at
https://wiki.asterisk.org/wiki/x/IwBRAQ.
While ultimately it makes the most sense to abandon masquerades altogether,
it will take some time to completely irradicate. Even then, there may always
be code that's not worth rewriting to get rid of the masquerade.
This patch does two things to make masquerades slightly less insane:
* When swapping the names of the original and clone channel, only emit a
single rename event of original -> original<ZOMBIE>. The original code
issued three rename events to accomplish the same end.
* In addition to swapping the names of the channels, also swap their
uniqueid's. This allows the 'Uniqueid' field to be used as a stable
identifier for a channel from and external interface, such as AMI.
David M. Lee [Mon, 14 Jan 2013 15:29:22 +0000 (15:29 +0000)]
Fix XML encoding of 'identity display' in NOTIFY messages, continued.
When r378933 was merged into 1.8, it should have also escaped
remote_display, since it will have the same XML encoding problem when
the caller/callee roles are reversed.
Reset RTP timestamp; sequence number on SSRC change
In r370252 for ASTERISK-18404, Asterisk's handling of RTP was modified to
better account for out of order RTP packets. This was accomplished by using the
RTP timestamp and sequence number to check for out of order packets. However,
when a SSRC change occurs, the timestamp and sequence number will no longer
have any relation to the previously received packets. The variables tracking
the timestamp and sequence number therefore have to be reset.
Matthew Jordan [Sun, 13 Jan 2013 22:07:00 +0000 (22:07 +0000)]
Reset RTP timestamp; sequence number on SSRC change
In r370252 for ASTERISK-18404, Asterisk's handling of RTP was modified to
better account for out of order RTP packets. This was accomplished by using the
RTP timestamp and sequence number to check for out of order packets. However,
when a SSRC change occurs, the timestamp and sequence number will no longer
have any relation to the previously received packets. The variables tracking
the timestamp and sequence number therefore have to be reset.
Fix XML encoding of 'identity display' in NOTIFY messages.
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
David M. Lee [Sat, 12 Jan 2013 06:43:37 +0000 (06:43 +0000)]
Fix XML encoding of 'identity display' in NOTIFY messages.
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
This provides a JSON API by pulling in and wrapping the Jansson JSON
library[1]. The Asterisk API basically mirrors the Jansson
functionality, with a few minor tweaks.
* Some names have been asteriskified to protect the innocent.
* Jansson provides both reference-stealing and reference-borrowing
versions of several API's. The Asterisk API is exclusively
reference-stealing for operations that put elements into arrays and
objects.
* No support for doubles, since we usually don't need that.
* Coming along for the ride is the ast_test_validate macro, which made
the unit tests much easier to write.
Retain XMPP filters across reconnections so external modules continue to function as expected.
Previously if an XMPP client reconnected any filters added by an external module were lost.
This issue exhibited itself with chan_motif not receiving and reacting to Jingle signaling.
Joshua Colp [Fri, 11 Jan 2013 23:05:38 +0000 (23:05 +0000)]
Retain XMPP filters across reconnections so external modules continue to function as expected.
Previously if an XMPP client reconnected any filters added by an external module were lost.
This issue exhibited itself with chan_motif not receiving and reacting to Jingle signaling.
David M. Lee [Fri, 11 Jan 2013 22:31:42 +0000 (22:31 +0000)]
Add JSON API for Asterisk.
This provides a JSON API by pulling in and wrapping the Jansson JSON
library[1]. The Asterisk API basically mirrors the Jansson
functionality, with a few minor tweaks.
* Some names have been asteriskified to protect the innocent.
* Jansson provides both reference-stealing and reference-borrowing
versions of several API's. The Asterisk API is exclusively
reference-stealing for operations that put elements into arrays and
objects.
* No support for doubles, since we usually don't need that.
* Coming along for the ride is the ast_test_validate macro, which made
the unit tests much easier to write.
Automerge script [Thu, 10 Jan 2013 00:20:46 +0000 (00:20 +0000)]
Merged revisions 378854,378858-378859 via svnmerge from
file:///srv/subversion/repos/asterisk/trunk
........
r378854 | rmudgett | 2013-01-09 17:22:00 -0600 (Wed, 09 Jan 2013) | 1 line
Fix logger.c function definition.
........
r378858 | rmudgett | 2013-01-09 17:23:41 -0600 (Wed, 09 Jan 2013) | 6 lines
Trivial misc bridge code changes.
* softmix_bridge_thread() was redundantly initializing an 8K buffer.
* Promoted a debug message to a warning in multiplexed_add_or_remove().
........
r378859 | rmudgett | 2013-01-09 17:51:45 -0600 (Wed, 09 Jan 2013) | 6 lines
* Simple optimization of bridge_playfile().
* Squeezed some redundancy out of update_bridge_vars().
* Wrapped long line in __ast_change_name_nolink().
........
* Revert the -r341580 and -r341599 changes adding the queues.conf
check_state_unknown option as it was added in an attempt to fix this
problem. The fix did not need to be optional. The fix should not have
tried to explicitly set the device state. Setting the device state by
something other than the device introduces a race condition. I also could
not see how the change would be effective other than delaying the
app_queue code long enough for the device state to propagate to app_queue.
........
Merged revisions 378663 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378683 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378687 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r378691 | rmudgett | 2013-01-08 18:05:35 -0600 (Tue, 08 Jan 2013) | 10 lines
app_queue: Fix incorrect assertion.
(issue ASTERISK-16115)
........
Merged revisions 378689 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378690 from http://svn.asterisk.org/svn/asterisk/branches/11
................
* Revert the -r341580 and -r341599 changes adding the queues.conf
check_state_unknown option as it was added in an attempt to fix this
problem. The fix did not need to be optional. The fix should not have
tried to explicitly set the device state. Setting the device state by
something other than the device introduces a race condition. I also could
not see how the change would be effective other than delaying the
app_queue code long enough for the device state to propagate to app_queue.
........
Merged revisions 378663 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378683 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378687 from http://svn.asterisk.org/svn/asterisk/branches/11
Mark Michelson [Mon, 7 Jan 2013 22:16:06 +0000 (22:16 +0000)]
Address review board feedback from Matt and Richard
* Remove extraneous whitespace
* Bump up debug levels of messages and add identifying info to messages.
* Account for potential failures of ao2_link()
* Add additional test and some more test data
* Add some comments in places where they could be useful
* Make threadpool listeners and their callbacks optional
Rewrite skinny dialing to remove threaded simpleswitch
This rewrite changes skinny dialing from the threaded simpleswitch
to a scheduled timeout approach. There were some underlying issues
with the threaded simple switch with occasional corruption and
possible segfaults.
Damien Wedhorn [Sun, 6 Jan 2013 20:45:12 +0000 (20:45 +0000)]
Rewrite skinny dialing to remove threaded simpleswitch
This rewrite changes skinny dialing from the threaded simpleswitch
to a scheduled timeout approach. There were some underlying issues
with the threaded simple switch with occasional corruption and
possible segfaults.
res_srtp: Prevent a crash from occurring due to srtp_create failures in srtp_create
Under some circumstances, libsrtp's srtp_create function deallocates memory that
it wasn't initially responsible for allocating. Because we weren't initially
aware of this behavior, this memory was still used in spite of being unallocated
during the course of the srtp_unprotect function. A while back I made a patch
which would set this value to NULL, but that exposed a possible condition where
we would then try to check a member of the struct which would cause a segfault.
In order to address these problems, ast_srtp_unprotect will now set an error value
when it ends without a valid SRTP session which will result in the caller of
srtp_unprotect observing this error and hanging up the relevant channel instead of
trying to keep using the invalid session address.
Jonathan Rose [Fri, 4 Jan 2013 23:14:54 +0000 (23:14 +0000)]
res_srtp: Prevent a crash from occurring due to srtp_create failures in srtp_create
Under some circumstances, libsrtp's srtp_create function deallocates memory that
it wasn't initially responsible for allocating. Because we weren't initially
aware of this behavior, this memory was still used in spite of being unallocated
during the course of the srtp_unprotect function. A while back I made a patch
which would set this value to NULL, but that exposed a possible condition where
we would then try to check a member of the struct which would cause a segfault.
In order to address these problems, ast_srtp_unprotect will now set an error value
when it ends without a valid SRTP session which will result in the caller of
srtp_unprotect observing this error and hanging up the relevant channel instead of
trying to keep using the invalid session address.
Fix SIP Notify Messages To Have The Proper IP Address In The FROM Field
On a multihomed server when sending a NOTIFY message, we were not figuring out
which network should be used to contact the peer.
This patch fixes the problem by calling ast_sip_ouraddrfor() and then
build_via() so that our NOTIFY message contains the correct IP address.
Also, a debug message is being added to help follow the call-id changes that
occur. This was helpful for confirming that the IP address was set properly
since the call-id contains the IP address. It also will be helpful for
troubleshooting purposes when following a call in the debug logs.
(closes issue ASTERISK-20805)
Reported by: Bryan Hunt
Tested by: Bryan Hunt, Michael L. Young
Patches:
asterisk-20805-notify-ip-v2.diff uploaded by Michael L. Young (license 5026)
Merged revisions 378554 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378559 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r378585 | kmoore | 2013-01-04 16:19:16 -0600 (Fri, 04 Jan 2013) | 13 lines
Fix pjproject compilation in certain circumstances
On a fresh checkout of Asterisk 11, running make before ./configure
could cause the pjproject subdirectory to get in an odd state that
would prevent compilation. This patch by Tilghman prevents that from
occurring.
Kinsey Moore [Fri, 4 Jan 2013 22:19:16 +0000 (22:19 +0000)]
Fix pjproject compilation in certain circumstances
On a fresh checkout of Asterisk 11, running make before ./configure
could cause the pjproject subdirectory to get in an odd state that
would prevent compilation. This patch by Tilghman prevents that from
occurring.
(closes issue ASTERISK-20681)
Reported by: Dinesh Ramjuttun
Tested by: danilo borges, Steve Lang
patches:
20121208__ccar_solved.diff.txt uploaded by Tilghman Lesher (license 5003)
........
Merged revisions 378582 from http://svn.asterisk.org/svn/asterisk/branches/11
Fix SIP Notify Messages To Have The Proper IP Address In The FROM Field
On a multihomed server when sending a NOTIFY message, we were not figuring out
which network should be used to contact the peer.
This patch fixes the problem by calling ast_sip_ouraddrfor() and then
build_via() so that our NOTIFY message contains the correct IP address.
Also, a debug message is being added to help follow the call-id changes that
occur. This was helpful for confirming that the IP address was set properly
since the call-id contains the IP address. It also will be helpful for
troubleshooting purposes when following a call in the debug logs.
(closes issue ASTERISK-20805)
Reported by: Bryan Hunt
Tested by: Bryan Hunt, Michael L. Young
Patches:
asterisk-20805-notify-ip-v2.diff uploaded by Michael L. Young (license 5026)
Fix Queue Log Reporting Every Call COMPLETECALLER With "h" Extension Present
When the "h" extension is present within the context of the queue, all calls
are being reported COMPLETECALLER even when the agent is hanging up the call.
This patch checks to see if the agent hung-up or not instead of only relying on
checking if the queue (caller) channel hung-up or not. It would appear that
having the h extension in the mix, the pbx goes to the h extension,
"hanging-up" the queue channel and triggering the reporting of COMPLETECALLER.
(closes issue ASTERISK-20743)
Reported by: call
Tested by: call, Michael L. Young
Patches:
asterisk-20743-q-cmplt-caller.diff
uploaded by Michael L. Young (license 5026)
Fix Queue Log Reporting Every Call COMPLETECALLER With "h" Extension Present
When the "h" extension is present within the context of the queue, all calls
are being reported COMPLETECALLER even when the agent is hanging up the call.
This patch checks to see if the agent hung-up or not instead of only relying on
checking if the queue (caller) channel hung-up or not. It would appear that
having the h extension in the mix, the pbx goes to the h extension,
"hanging-up" the queue channel and triggering the reporting of COMPLETECALLER.
(closes issue ASTERISK-20743)
Reported by: call
Tested by: call, Michael L. Young
Patches:
asterisk-20743-q-cmplt-caller.diff
uploaded by Michael L. Young (license 5026)
* Made agent_cont_sleep() and agent_ack_sleep() stop waiting if the wrapup
time expires. agent_cont_sleep() had tried but returned the wrong value
to stop waiting.
* Made agent_ack_sleep() take a struct agent_pvt pointer instead of a void
pointer for better type safety.
........
Merged revisions 378486 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378487 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Richard Mudgett [Thu, 3 Jan 2013 19:42:54 +0000 (19:42 +0000)]
chan_agent: Fix wrapup time wait response.
* Made agent_cont_sleep() and agent_ack_sleep() stop waiting if the wrapup
time expires. agent_cont_sleep() had tried but returned the wrong value
to stop waiting.
* Made agent_ack_sleep() take a struct agent_pvt pointer instead of a void
pointer for better type safety.
........
Merged revisions 378486 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378487 from http://svn.asterisk.org/svn/asterisk/branches/11
Merged revisions 378456 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378457 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r378460 | kmoore | 2013-01-03 12:51:43 -0600 (Thu, 03 Jan 2013) | 13 lines
Add missing test event
This test event was missing from channel.c causing the dial_LS_options
test to fail intermittently because of a race condition where most code
paths emitted the test event but this one did not. The dial_LS_options
test should stop bouncing now.
........
Merged revisions 378455 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378459 from http://svn.asterisk.org/svn/asterisk/branches/11
................
Kinsey Moore [Thu, 3 Jan 2013 18:51:43 +0000 (18:51 +0000)]
Add missing test event
This test event was missing from channel.c causing the dial_LS_options
test to fail intermittently because of a race condition where most code
paths emitted the test event but this one did not. The dial_LS_options
test should stop bouncing now.
........
Merged revisions 378455 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378459 from http://svn.asterisk.org/svn/asterisk/branches/11
Prevent crashes in res_xmpp when receiving large messages
Similar to r378287, res_xmpp was marshaling data read from an external source
onto the stack. For a sufficiently large message, this could cause a stack
overflow. This patch modifies res_xmpp in a similar fashion to res_jabber by
removing the stack allocation, as it was unnecessary.
Merged revisions 378411 from http://svn.asterisk.org/svn/asterisk/branches/11
................
r378414 | tilghman | 2013-01-03 10:04:11 -0600 (Thu, 03 Jan 2013) | 11 lines
Add aliases to the Directory.
This is an interesting feature that allows additional strings to be used to
search the Directory, primarily intended to be used with nicknames, but could
be used with affiliations and the like. Because the name field is used in
more than one place (such as email notifications), it is important that these
additional strings not be placed in the name field, but be specified
separately.
Tilghman Lesher [Thu, 3 Jan 2013 16:04:11 +0000 (16:04 +0000)]
Add aliases to the Directory.
This is an interesting feature that allows additional strings to be used to
search the Directory, primarily intended to be used with nicknames, but could
be used with affiliations and the like. Because the name field is used in
more than one place (such as email notifications), it is important that these
additional strings not be placed in the name field, but be specified
separately.
projects / thirdparty / asterisk.git / log
