When Asterisk receives an INVITE from an external domain when allowexternaldomains=no
send a 403 instead of a 404. This is consistent with Asterisk's behavior when receiving
a REGISTER in this situation.
(Closes issue ASTERISK-19601)
Reported by Matthew Jordan
Patches:
ASTERISK-19601-no401.patch uploaded by Mark Michelson (License #5049)
........
Merged revisions 369302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369303 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The sendonly/recvonly/sendrecv/inactive media stream attributes were
parsed for video, but nothing was ever done with them. With this code
removed, an UNSUPPORTED message is produced when these attributes are
used in conjunction with a video stream which is the better behavior
since they were never really supported in the first place.
........
Merged revisions 369195 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369206 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a minimal implementation of the "Who Hung Up?" Asterisk 11
work to chan_dahdi.c for the MFC/R2 DAHDI subtech. Given the way that
OpenR2 interfaces with chan_dahdi, it is much harder to expose the
type of protocol information that is available in PRI, SS7, or other
channel technologies.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is part of the DAHDI support for the Asterisk 11 "Who Hung Up?"
project and covers the implementation for the technologies implemented
in sig_analog.c and sig_pri.c. Tested on a local machine to verify
protocol and cause information is available.
Review: https://reviewboard.asterisk.org/r/1953/
(issue SWP-4222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel drivers that allow native bridging need to handle
AST_CONTROL_PVT_CAUSE_CODE frames and previously did not handle them
properly, usually breaking out of the native bridge. This change
corrects that behavior and exposes the available cause code information
to the dialplan while native bridges are in place. This required
exposing the HANGUPCAUSE hash setter outside of channel.c, so
additional documentation has been added.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk was incorrectly setting the destination of CANCELs
and ACKs for error responses to the URI of the initial INVITE.
This resulted in further requests, such as INVITEs with authentication
credentials, to be routed incorrectly. Instead, when these CANCEL
or ACKs are to be sent, we should simply keep the destination the
same as what it previously was. There is no need to alter it any.
(closes issue ASTERISK-20008)
Reported by Marcus Hunger
Patches:
ASTERISK-20008.patch uploaded by Mark Michelson (license #5049)
........
Merged revisions 369066 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369067 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added test to skinny_register to only allow device to register against
a device that is not already registered.
Addback l->device test for skinny_show_lines. Fixes segfault if a line
is configured but not configured to a device. Reverses part of r368680.
Removed redundant l->device tests in subsubstate and dumpsub. l->device
will always be valid if these routines are called. Reverses 368948 -
discussed with mjordan on irc.
Some indentation cleanup.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change replaces the static array of four representable media
streams with an AST_LIST so that chan_sip can keep track of offered
media streams. This allows chan_sip to deal with offers containing
multiple same-type streams and many other situations without rejecting
the SDP offer in its entirety, yet still generating a valid response.
This also covers cases where Asterisk can not comprehend the offer if
it is in the correct format.
Previously, chan_sip would reject SDP offers or entirely ignore
individual stream offers in an effort to be more compatible which
would often result in invalid SDP responses.
Review: https://reviewboard.asterisk.org/r/1988/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continuing with the Who Hung Up? project for Asterisk 11, this adds
support to IAX2 for the HANGUPCAUSE hash.
Additionally, this breaks out some functionality in frame.c for getting
information about frame types and subclasses.
Review: https://reviewboard.asterisk.org/r/1941/
(issue SWP-4222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST-2012-008 (r367844) fixed a denial of service attack exploitable in the
Skinny channel driver that occurred when certain messages are sent after a
previously registered station sends an Off Hook message. Unresolved in that
patch is an issue in the Asterisk 10 releases, wherein, if a Station Key
Pad Button Message is processed after an Off Hook message, the channel driver
will inappropriately dereference a NULL pointer.
This patch fixes those places where the message handling or the channel
callback functions would attempt to dereference the line's pointer to the
device.
(issue ASTERISK-19905)
Reported by: Christoph Hebeisen
Tested by: mjordan, Christoph Hebeisen
Patches:
AST-2012-009-10.diff uploaded by mjordan (license 6283)
........
Merged revisions 368947 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On incoming calls, we were setting the cid_tag on the dialog only if there was
no remote party information (Remote-Party-ID or P-Asserted-Identity) present.
The Caller ID tag is an invented parameter, though, and should be set no matter
the circumstance.
(closes issue ASTERISK-19859)
Reported by Thomas Arimont
(closes issue AST-884)
Reported by Trey Blancher
........
Merged revisions 368807 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368808 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r367163, "send to voicemail" functionality was added to the SIP channel
driver. This required updating the party redirecting information for the
channel based on the headers provided in the REFER request. When the
redirecting party information is updated on the channel, a call to
ast_indicate_data occurs. Because handle_request_refer still had the sip_pvt
locked, a deadlock could occur between the pbx_thread and the do_monitor thread
servicing the REFER request.
This patch preserves the proper locking order between the channel and the
sip_pvt by ensuring that the sip_pvt is unlocked prior to updating the party
redirecting information on the channel.
(closes issue AST-903)
Reported by: Matt Jordan
patches:
jira_ast_903_trunk.patch by rmudgett (license 5621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ANI2 information is now parsed out of SIP From headers when present in
the oli, isup-oli, and ss7-oli parameters and is available via the
CALLERID(ani2) dialplan function.
(closes issue ASTERISK-19912)
Patch-by: Rob Gagnon
Review: https://reviewboard.asterisk.org/r/1947/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original was testing for d->session, setting and testing again (all nested).
Removed duplicate testing and restructured function to test/return and then
the main code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Removed d->registered which was mirroring d->session. Changed relevant
references to use d->session instead.
Moved setting and unsetting of l->device from session register to device
configuration. As such, l->device will always be valid unless it is has not
been configured to a device. Revised various test where checking if a device
is registered to use l->device->session.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A deadlock can occur when a POTS phone tries to flash hook to originate a
second call for 3-way or transfer. If another process is scanning the
channels container when the POTS line flash hooks then a deadlock will
occur.
* Release the channel and private locks when creating a new channel as a
result of a flash hook.
(closes issue ASTERISK-19842)
Reported by: rmudgett
Tested by: rmudgett
........
Merged revisions 368644 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368645 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a dialog-starting INVITE contains a to-tag, then Asterisk
will respond with a 481. In this case, the resulting incoming
ACK would not be matched, so Asterisk would continue retransmitting
the 481 until the transaction times out.
There were two issues. Asterisk, upon creating a sip_pvt would generate
a local tag. However, when the time came to transmit the 481, since there
was a to-tag in the INVITE, Asterisk would place this original to-tag
in the 481 response. When the ACK came in, Asterisk would attempt to
match the to-tag in the ACK to the generated local tag. Unfortunately,
Asterisk never actually transmitted a response with the generated local
tag, so the to-tag in the ACK would not match.
The other problem was that when the 481 was sent, nothing was set
on the sip_pvt to indicate what CSeq is expected in the ACK.
To fix the first problem, we zero out the to-tag seen in the incoming
INVITE. This way, Asterisk, when time to send a response, will send
its generated local tag instead.
To fix the second problem, we set the sip_pvt's pendinginvite to the
CSeq of the INVITE when we send a 481.
(closes issue ASTERISK-19892)
Reported by Mark Michelson
........
Merged revisions 368625 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368629 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was essentially duplicated functionality where normal channels used
AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used
AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage
into AST_CAUSE_ANSWERED_ELSEWHER usage.
Review: https://reviewboard.asterisk.org/r/1944
(closes issue ASTERISK-19865)
Patch-by: Birger Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 351130 broke corect HANGUPCAUSE setting
for the 404 case in chan_sip. Other cases were also
potentially broken. This patch fixes the relaying
of causes to be what they used to be.
(closes issue ASTERISK-19914)
Reported by Pavel Troller
Tested by Walter Doekes (via a reviewboard test to be committed later)
Patches:
chan_sip.diff uploaded by Pavel Troller (license #6302)
........
Merged revisions 368498 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368499 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Presence support has been added. This is accomplished by
allowing for presence hints in addition to device state
hints. A dialplan function called PRESENCE_STATE has been
added to allow for setting and reading presence. Presence
can be transmitted to Digium phones using custom XML
elements in a PIDF presence document.
Voicemail has new APIs that allow for moving, removing,
forwarding, and playing messages. Messages have had a new
unique message ID added to them so that the APIs will work
reliably. The state of a voicemail mailbox can be obtained
using an API that allows one to get a snapshot of the mailbox.
A voicemail Dialplan App called VoiceMailPlayMsg has been
added to be able to play back a specific message.
Configuration hooks have been added. Configuration hooks
allow for a piece of code to be executed when a specific
configuration file is loaded by a specific module. This is
useful for modules that are dependent on the configuration
of other modules.
chan_sip now has a public method that allows for a custom
SIP INFO request to be sent mid-dialog. Digium phones use
this in order to display progress bars when files are played.
Messaging support has been expanded a bit. The main
visible difference is the addition of an AMI action
MessageSend.
Finally, a ParkingLots manager action has been added in order
to get a list of parking lots.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk should not accept SDP offers that contain unknown RTP profiles (for
audio/video streams) or unknown top-level media types. When it does, it answers
with an SDP that does not match the offer properly, and this will nearly
always result in a broken call. This patch causes such offers to be rejected.
Review: https://reviewboard.asterisk.org/r/1811/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 'Unsupported media type' is only reported when that is in fact the case,
not when a supported media type is included in an 'm' line that has an
invalid format.
* All warning messages related to parsing 'm' lines now include the 'm' line contents.
* (minor bugfix) newline added to port-number-zero warning messages.
* Warning messages improved to use RFC-specified terminology for various items.
* Warnings for offers that include more than one port for a single media type now
include the media type.
Review: https://reviewboard.asterisk.org/r/1811/
........
Merged revisions 368218 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368267 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk servers are set up back-to-back, and
direct media is to be used betweeen endpoints, it is
fairly common for the two Asterisk servers to send
direct media reinvites to each other simultaneously.
This results in 491s and ACKs being exchanged between
the servers. While the media eventually gets set up
properly, the problem is that there can be a noticeable
delay for the streams to stabilize.
This patch adds a new directmedia option called "outgoing".
With this set, an immediate direct media reinvite will only
be sent if the call direction is outgoing. For incoming
dialogs, an immediate direct media reinvite will not be sent,
but further "reactionary" direct media reinvites may be sent.
Review: https://reviewboard.asterisk.org/r/1954
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a skinny session is unregistered, the corresponding device pointer is set
to NULL in the channel private data. If the client was not in the on-hook state
at the time the connection was closed, the device pointer can later be
dereferened if a message or channel event attempts to use a line's pointer to
said device.
The patches prevent this from occurring by checking the line's pointer in
message handlers and channel callbacks that can fire after an unregistration
attempt.
(closes issue ASTERISK-19905)
Reported by: Christoph Hebeisen
Tested by: mjordan, Damien Wedhorn
Patches:
AST-2012-008-1.8.diff uploaded by mjordan (license 6283)
AST-2012-008-10.diff uploaded by mjordan (licesen 6283)
........
Merged revisions 367844 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367845 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made schedule_delivery() set the received frame f->data.ptr to NULL if
the datalen is zero.
* Fix queue_signalling() memcpy() size error.
* Made queue_signalling() not use C++ keyword variable names.
(closes issue ASTERISK-19597)
Reported by: mgrobecker
Patches:
jira_asterisk_19597_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Michael L. Young
........
Merged revisions 367781 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367782 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pvt_sip allowtransfer was not being set to that of the peer's setting.
Therefore, the global allowtransfer setting was being used instead which would
lead to calls not being transfered if the global setting was set to 'no' despite
the setting on the peer being 'yes' and vice versa, calls would be allowed to
transfer even if the peer's setting was 'no' but the global setting was 'yes'.
(Closes issue ASTERISK-19856)
Reported by: Jacek
Tested by: Michael L. Young, Jacek
Patches:
issue-asterisk-19856-branch10-v3.diff uploaded by
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1923/
........
Merged revisions 367730 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367731 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When remotely bridging calls with directmedia, Asterisk would check
the address of the peers/users holding directmedia ACLs (set via
directmediapermit/directmediadeny) instead of the bridged peer. This
is similar to r366547, but trunk specific and involves changes to
the rtpengine instead of just chan_sip.
(closes issue AST-876)
review: https://reviewboard.asterisk.org/r/1924/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, MWI logic utilized a counter called 'lastmsgssent' to know whether
or not MWI NOTIFY requests had been sent to a specific peer. When MWI
notifications were changed to use the internal event framework, this value was
no longer needed for its original purpose. Hence, it was no longer updated
with the new/old message counts for a peer. The value was previously removed
for Asterisk 10; however, since it was still present in Asterisk 1.8 and still
useful for reporting purposes, it was decided to re-add the value.
This patch re-adds the 'LastMsgsSent' field in the response to an AMI/CLI 'sip
show peer [peer]' command, and makes it so that the value of lastmsgssent is
updated appropriately. The value should now display the new/old message counts
for a particular peer.
(closes issue ASTERISK-17866)
Reported by: Steve Davies
patches by:
ast-17866-rb1272.patch (License #5041 by irroot)
Modified slightly for this commit
Review: https://reviewboard.asterisk.org/r/1939
........
Merged revisions 367362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367369 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change accommodates two methods by which calls can be directed to
a user's voicemail.
* Incoming calls can be redirected to any user's voicemail.
* Established calls can be blind transferred to any user's voicemail.
Digium phones indicate the desire to direct a call to voicemail by using
a Diversion header with a reason parameter of "send_to_vm".
This patch adds the "send_to_vm" reason as a valid redirecting reason. In
addition, chan_sip.c has been modified to update redirecting information
on the transferred channel by reading a Diversion header on a REFER request.
(closes issue AST-871)
Reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/1925
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This addresses core findings 4 and 6.
Moises Silva helped me by stating that a break could be
safely added to the case where it is added in chan_dahdi.c
In say.c, I have added a comment indicating that static analysis
complains but that it is currently unknown if this is correct.
This fixes all core findings of this type.
(closes issue ASTERISK-19662)
reported by Matthew Jordan
........
Merged revisions 367027 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367028 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SSL_CTX structures were allocated but never freed. This was a bigger
issue for clients than servers since new SSL_CTX structures could be
allocated for each connection. Servers, on the other hand, typically
set up a single SSL_CTX for their lifetime.
This is solved in two ways:
1. In __ssl_setup(), if a tcptls_cfg has an ssl_ctx on it, it is
freed so that a new one can take its place.
2. A companion to ast_ssl_setup() called ast_ssl_teardown() has
been added so that servers can properly free their SSL_CTXs.
(issue ASTERISK-19278)
........
Merged revisions 367002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367003 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds to what was fixed in r366880. Specifically, it addresses the
following:
* chan_sip: dispose of an allocated frame in off nominal code paths in
sip_rtp_read
* func_odbc: when disposing of an allocated resultset, ensure that any rows
that were appended to that resultset are also disposed of
* cli: free the created return string buffer in another off nominal code
path
* chan_dahdi: free a frame that was allocated by the dsp layer if we choose
not to process that frame
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
........
Merged revisions 366944 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366948 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
