The principal behind this patch is simple. During a transfer,
we manipulate channels that are owned by a separate thread than
the one we currently are running in, so it makes sense that we
need to grab a reference to the channels so that they cannot
disappear out from under us.
In the wild, crashes were sometimes seen when the transferring
party would hang up the call before the transfer target answered
the call. The most common place to see the crash occur was when
attempting to send a connected line update to the transferer
channel.
(closes issue ASTERISK-20226)
Reported by Jared Smith
Patches:
ASTERISK-20226.patch uploaded by Mark Michelson (License #5049)
Tested by: Jared Smith
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For 1.8, 10, 11 and trunk we are are improving the code readability.
For 11 and trunk, auto nat detection was added. The natdetected flag was being
set to 1 when the host address in the VIA header did not specifiy a port. This
patch fixes this by setting the port on the temporary sock address used to
SIP_STANDARD_PORT in order for the sock address comparison to work properly.
(closes issue ASTERISK-20724)
Reported by: Michael L. Young
Patches:
asterisk-20724-set-port-v2.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2206/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at some debug logs, I noticed that it was being reported that the
SDP origin line was unsupported or failed. Upon looking into this on my local
machine, I found that I too was getting this debug message yet everything seemed
to be getting processed properly. What was discovered is, that, the variable to
determine what is displayed in the debug message for the SDP line that was
processed, was not being set for the origin line when the result was successful.
This patch fixes this and was tested on local machine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a "sip reload" is issued for a SIP peer, then his
IP address will be cleared, thus resulting in forgetting the
public IP address. Asterisk will then attempt to route SIP
traffic to the private IP address.
The fix here is to make "sip reload" ignore realtime peers
when "host = dynamic" is spotted. Realtime peers can now only
have their IP address reset if they have gone from being not
dynamic to being dynamic.
(closes issue ASTERISK-18203)
reported by daren ferreira
(closes issue ASTERISK-20572)
reported by JoshE
Patches:
fix_nat_realtime.diff uploaded by JoshE (license #6075)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A check was added for direct media ACLs that immediately forbid remote bridging if there
was no bridged channel. This caused directrtpsetup to no longer function as it needs this
information before bridging actually occurs.
Logic has now been adjusted so if there is no bridged channel a remote bridge will still
be attempted.
(closes issue ASTERISK-20511)
Reported by: kristoff
Review: https://reviewboard.asterisk.org/r/2146/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP session timer mechanism contains a mandatory 'refresher' parameter
(included in the Session-Expires header) which is used in the session timer
offer/answer signaling within a SIP Invite dialog. It looks like asterisk is
interpreting the uac resp. uas role only as the initial role of client and
server (caller is uac, callee is uas). The standard rfc 4028 however assigns
the client role to the ((RE)-Invite) requester, the server role to the
((RE)-Invite) responder.
This patch has Asterisk track the actual refresher as "us" or "them" as opposed
to relying on just the configured "uas" or "uac" properties.
(closes issue AST-922)
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/2118/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When setting CALLERID(pres)=unavailable in the dialplan, the From header
in the SIP message contains "Anonymous" <sip:Anonymous@anonymous.invalid>.
For consistency, Asterisk should use a lowercase a in the userpart of the
URI.
* Make the From header use a lowercase A in the userpart of the anonymous
URI.
(closes issue ASTERISK-19838)
Reported by: Antti Yrjola
Patches:
chan_sip_patch_ASTERISK-19838.patch (license #6383) patch uploaded by Antti Yrjola
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
