If conditions were right it was possible for both the PBX core and chan_sip to deadlock by both having a lock that the other
wants. In the case of the PBX core it had the contexts lock and wanted a SIP dialog lock, while in the case of chan_sip it
had the SIP dialog lock and wanted the contexts lock.
This fix unlocks the SIP dialog before getting the extension state so that the other thread will not block on trying to lock
it. Once the extension state is retrieved the SIP dialog is locked again and life carries on.
As the SIP dialog is reference counted it is not possible for it to go away after unlocking.
(closes issue ASTERISK-20437)
Reported by: jhutchins
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk v1.8 and later was not as vulnerable to this issue.
* Made find_call() lock each private as it processes the found dialogs.
(Primary cause of ABE-2876)
* Made the other functions that traverse the dialogs container lock each
private as it examines them.
* Fix race condition in sip_call() if the thread that sent the INVITE is
held up long enough for a response to be processed. The p->initid for the
INVITE retransmission could be added after it was canceled by the response
processing.
* Made __sip_destroy() clean up resource pointers after freeing. This is
primarily defensive in case someone has a stale private pointer.
* Removed redundant memset() in reqprep(). The call to init_req() already
does the memset() and is the first reference to req in reqprep().
* Removed useless set of req.method in transmit_invite(). The calls to
initreqprep() and reqprep() have to do this because they memset() the req.
JIRA ABE-2876
..........
Merged -r373423 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A change was committed to fix direct media ACL support. This change wrongly assumed that
only a single channel technology structure exists for chan_sip. This is in fact false as
a second exists for calls using SIP INFO DTMF. The code which performs direct media ACL
checking now checks for both the non-INFO DTMF and INFO DTMF channel technology structures.
(closes issue ASTERISK-20409)
Reported by: michele cicciotti privatewave
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves two sources of memory leaks when using TLS in Asterisk:
1) It removes improper initialization (and multiple re-initializations) of
portions of the SSL library. Asterisk calls SSL_library_init and
SSL_load_error_strings during SSL initialization; collectively this
obviates the need for calling any of the following during initialization
or client connection handling:
* ERR_load_crypto_strings (handled by SSL_load_error_strings)
* OpenSSL_add_all_algorithms (synonym for SSL_library_init)
* SSLeay_add_ssl_algorithms (synonym for SSL_library_init)
2) Failure to completely clean up all memory allocated by Asterisk and by
the SSL library for TLS clients. This included not freeing the SSL_CTX
object in the SIP channel driver, as well as not clearing the error
stack when the TLS client exited.
Note that these memory leaks were found by Thomas Arimont, and this patch
was essentially written by him with some minor tweaks.
(closes issue AST-889)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
patches:
(bugAST-889.patch) by Thomas Arimont (license 5525)
Review: https://reviewboard.asterisk.org/r/2105
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "autodestruct with owner in place" message is typically
indicative of a channel reference leak. Printing out the name
of the channel in the message may be helpful when trying to
debug the issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a CLI warning when a SDP offer is rejected due to UDPTL
initialization failure. Previously, there was no indication of the
reason for offer rejection in this case.
(closes issue ASTERISK-20357)
Reported-by: Francesco Usseglio Gaudi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to 1.8, it was not necessary for an explicit "type" to be set for an
asterisk LDAP realtime peer. Now the routine find_peer actually checks the
type field during registration and fails to find the peer if it is not set.
The attached patches make the realtime type equal whatever type is being
searched for if the type is 0 upon return from routine build_peer.
(closes issue ASTERISK-17222)
Reported by: John Covert
Patch by: David Vossel
Tested by: Darren Sessions
Review: https://reviewboard.asterisk.org/r/2095/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes three main issues
* Change asprintf() uses to ast_asprintf() so that it
pairs properly with ast_free() and no longer causes
MALLOC_DEBUG to freak out.
* When ast_asprintf() fails, set the pointer NULL if
it will be referenced later.
* Fix some memory leaks that were spotted while taking
care of the first two points.
(Closes issue ASTERISK-20135)
reported by Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2071
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously the pvt SIP_OUTGOING flag was used instead, which will frequently
flip during reinvites.
(closes issue AST-897)
Reported by: Thomas Arimont
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Under certain conditions, a SIP transaction involving directmedia wouldn't
trigger a re-invite because the SDP answer was included in an ACK instead
of in a message that we would have triggered the invite with. This patch
just queues a source change control frame if the dialog is using
directmedia when we find sdp for an ACK.
(closes issue AST-913)
Reported by: Thomas Arimont
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The other instance of this bug was fixed by jcolp/file in r121496. If
we are destroying a dialog only set the MWI dialog pointer on the
related peer to NULL if it is the dialog currently being destroyed.
(closes issue ASTERISK-20119)
Patch-by: Misha Vodsedalek
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is based on the review request posted by Walter Doekes
(referenced lower in the commit message)
The main fix here is to treat the IPorHost portion of the dial
string as a temporary outbound proxy. This ensures requests
get sent to the proper location.
Due to the age of the request, some parts were no longer relevant.
For instance, the request moved outbound proxy parsing code into
a single method. This is done in a previous commit, so it was not
necessary to do again.
Also, the review request fixed some errors with regards to request
routing for CANCEL and ACK requests. This has also been fixed in
more recent commits.
(closes issue ASTERISK-19677)
reported by Walter Doekes
Review https://reviewboard.asterisk.org/r/1859
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With a large number of SIP peers registered, performing a SIP reload causes a
flood of SIP OPTIONS request packets. These are immediately sent out, and, as
responses come back, can cause peers to be flagged as 'lagged' due to handling
of the many response messages.
This fix prevents this "packet storm" and schedules the pokes for a random
time. That time varies between 1 ms and the peer's qualify time, or, if
the qualify time is unknown, the global qualifyfreq setting.
The committed patch has some very small modifications to the patch schmidts
wrote for the review.
(closes issue ASTERISK-19154)
Reported by: Nicolo Mazzon
patches:
issue19154.patch license #6034 uploaded by schmidts
Review: https://reviewboard.asterisk.org/r/1652
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This replaces all calls to alloca() with ast_alloca() which calls gcc's
__builtin_alloca() to avoid BSD semantics and removes all NULL checks
on memory allocated via ast_alloca() and ast_strdupa().
(closes issue ASTERISK-20125)
Review: https://reviewboard.asterisk.org/r/2032/
Patch-by: Walter Doekes (wdoekes)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370642 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.
For those who are having some deja vu, that's because this
patch was originally committed to trunk since there is a
new configuration option added. After seeing a bug report
about audio being slow to set up on SIP calls, it became
apparent that this patch would be the best solution for
resolving the issue. The patch is unintrusive and will
have no effect unless the option is explicitly enabled.
(closes issue AST-896)
reported by Thomas Arimont
(closes issue ASTERISK-19857)
reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If pedantic mode is enabled, outbound invites will have double-escaped
contacts. This avoids setting an already-escaped string into a field
where it is expected to be unescaped.
(closes issue ASTERISK-20023)
Reported by: Walter Doekes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When removing the warning for AST_CONTROL_FLASH from sip_indicate, I also
inadvertently changed the return value, which would likely make the indication
not be sent in audio. This fixes that while still removing the warning message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip channels can receive flash control frames when connected to analog
phones and possibly for other reasons. There really isn't a reason to warn when
these frames are received, we can safely ignore them.
Patches:
dahdi_sip_flash.diff uploaded by Jonathan Rose (license 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Commits r369557 and r369579 were done to improve handling of re-INVITEs
when the UA that was supposed to receive the re-INVITE fails to respond.
A limitation of those patches occurred when a UA sent a provisional
response to the re-INVITE. This triggered a sending of a BYE in
check_pending. This patch tweaks the handling of the re-INVITE such that
a BYE is not sent in response to those messages.
(issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies
patches:
(reinvite_tweak.diff license #5012 by Steve Davies)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is no need to call check_pendings() on a final response to an INVITE
when destroying the scheduler entry as it will be done later during normal
processing.
(issue ASTERISK-19992)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A previous attempt at fixing this issue had negative side effects related
to attended transfers which this patch should resolve. Many thanks to
Steve Davies for all of the good suggestions and testing.
(closes issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies, Terry Wilson
Review: https://reviewboard.asterisk.org/r/2009/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The basic problem is that if a re-INVITE is sent by Asterisk and it receives a
provisional response, but no final response, then the dialog is never torn
down. In addition to leaking memory, this also leaks file descriptors and will
eventually lead to Asterisk no longer being able to process calls.
This patch just keeps track of whether there is an outstanding re-INVITE, and if
there is goes ahead and cleans up everything as though there was no outstanding
reinvite.
Review: https://reviewboard.asterisk.org/r/2009/
(closes issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies, Terry Wilson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Match our local tag to whatever to-tag was sent in the initial INVITE.
Because the size of the to-tag may not fit in the buffer in the sip_pvt,
it has been changed to a string field.
(closes issue ASTERISK-19892)
reported by Walter Doekes
Review: https://reviewboard.asterisk.org/r/1977
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A sip_pvt may not have relatedpeer set if a call doesn't match up
with a peer. If there is no relatedpeer, there is no direct media
ACL to apply, so just return that it is allowed.
(closes issue ASTERISK-20040)
Reported by: Terry Wilson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369214 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369195 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369066 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling ast_set_hangupsource() with the channel lock held can result in a
deadlock because the function also locks the bridged channel.
(issue ASTERISK-19537)
(closes issue ASTERISK-19801)
Reported by: Alec Davis
(closes issue AST-891)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of these were just saving returned values without using them and
in some cases the variable being saved to could be removed as well.
(issue ASTERISK-19672)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368738 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When changing between different modes of hold, the flags were not being
cleared out properly causing a failure to change hold states.
(closes issue ASTERISK-19919)
Patch-by: Morten Tryfoss
Reported-by: Morten Tryfoss
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368586 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368498 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368218 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367730 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. However, the value was still
presented when, either by AMI or CLI, a 'sip show peer [peer]' command
was executed. The output of the command would always display the erroneous
value of 32767/65535 for 'LastMsgsSent'.
This patch 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTOBJ_UNREF sets the variable to NULL after unreffing it, so the variable
should definitely not be used after that. To solve this in the two cases
that affect subscribing for MWI notifications, we instead save the ref
locally, and unref them in the error conditions.
(closes issue ASTERISK-19827)
Reported by: B. R
Review: https://reviewboard.asterisk.org/r/1940/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367266 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@367002 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
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366944 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@366880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
