This patch, originally submitted by jozza, enables custom modules to send actions to AMI
and receive messages from AMI via a hook interface. Included is a simple test module to
illustrate the interface.
(closes issue #14635)
Reported by: jozza
Review: https://reviewboard.asterisk.org/r/412/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a side project I've been poking at this week. The intent is to discuss
Asterisk architecture in a top down fashion to help new developers understand how
Asterisk is put together. There is a ton of stuff to write about, so this will
just continue to evolve over time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226138 | tilghman | 2009-10-27 15:16:49 -0500 (Tue, 27 Oct 2009) | 7 lines
Manager output is not always NULL-terminated, so force a NULL at the end of the filestream.
(closes issue #15495)
Reported by: pdf
Patches:
20090916__issue15495.diff.txt uploaded by tilghman (license 14)
Tested by: pdf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226159 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code committed in revision 225405 was broken; instead of removing the unreference code,
the logic used to decide when to do it should have been reversed. This patch corrects the
situation, and makes reference counting work properly again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What this patch fixes
1.Moves sip TCP/TLS connection setup into the TCP helper thread:
Connection setup takes awhile and before this it was being
done while holding the monitor lock.
2.Moves TCP/TLS writing to the TCP helper thread: Through the
use of a packet queue and an alert pipe, the TCP helper thread
can now be woken up to write data as well as read data.
3.Locking error: sip_xmit returned an XMIT_ERROR without giving
up the tcptls_session lock. This lock has been completely removed
from sip_xmit and placed in the new sip_tcptls_write() function.
4.Memory leak: When creating a tcptls_client the tls_cfg was alloced
but never freed unless the tcptls_session failed to start. Now the
session_args for a sip client are an ao2 object which frees the
tls_cfg on destruction.
5.Pointer to stack variable: During sip_prepare_socket the creation
of a client's ast_tcptls_session_args was done on the stack and
stored as a pointer in the newly created tcptls_session. Depending
on the events that followed, there was a slight possibility that
pointer could have been accessed after the stack returned. Given
the new changes, it is always accessed after the stack returns
which is why I found it.
Notable code changes
1.I broke tcptls.c's ast_tcptls_client_start() function into two
functions. One for creating and allocating the new tcptls_session,
and a separate one for starting and handling the new connection.
This allowed me to create the tcptls_session, launch the helper
thread, and then establish the connection within the helper thread.
2.Writes to a tcptls_session are now done within the helper thread.
This is done by using an alert pipe to wake up the thread if new
data needs to be sent. The thread's sip_threadinfo object contains
the alert pipe as well as the packet queue.
3.Since the threadinfo object contains the alert pipe, it must now be
accessed outside of the helper thread for every write (queuing of a
packet). For easy lookup, I moved the threadinfo objects from a
linked list to an ao2_container.
(closes issue #13136)
Reported by: pabelanger
Tested by: dvossel, whys
(closes issue #15894)
Reported by: dvossel
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/380/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an object is being unlinked from its container *and* being returned to
the caller, we do not want to decrement the reference count after unlinking
it from the container, as the reference that the container held is what we
are returning to the caller... and if it was the only remaining reference to
the object, that could result in the object being destroyed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing
"desk to desk" between offices each with an asterisk box over the ISDN
should then be possible, without a whole load of DDI numbers required.
(closes issue #15604)
Reported by: alecdavis
Patches:
asterisk_subaddr_trunk.diff11.txt uploaded by alecdavis (license 585)
Some minor modificatons were made.
Tested by: alecdavis, rmudgett
Review: https://reviewboard.asterisk.org/r/405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch finishes the implementation of OBJ_MULTIPLE in astobj2 (the
case where multiple results need to be returned; OBJ_NODATA mode
already was supported). In addition, it converts ast_channel_iterators
(only the targeted versions, not the ones that iterate over all
channels) to use this method.
During this work, I removed the 'ao2_flags' arguments to the
ast_channel_iterator constructor functions; there were no uses of that
argument yet, there is only one possible flag to pass, and it made the
iterators less 'opaque'. If at some point in the future someone really
needs an ast_channel_iterator that does not lock the container, we can
provide constructor(s) for that purpose.
Review: https://reviewboard.asterisk.org/r/379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224855 | tilghman | 2009-10-20 17:07:11 -0500 (Tue, 20 Oct 2009) | 5 lines
Pay attention to the return value of the manipulate function.
While this looks like an optimization, it prevents a crash from occurring
when used with certain audiohook callbacks (diagnosed with SVN trunk,
backported to 1.4 to keep the source consistent across versions).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Two examples of its use are included, and the usage could be expanded in some
cases into certain configuration options where time periods are specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r223485 | russell | 2009-10-11 12:22:52 -0500 (Sun, 11 Oct 2009) | 6 lines
Don't use data outside of its scope.
The purpose of this code was to have a hangup frame put on the list of deferred
frames. However, the code that read the hangup frame was outside of the scope
of where the hangup frame was declared.
........
r223486 | russell | 2009-10-11 12:25:06 -0500 (Sun, 11 Oct 2009) | 2 lines
Remove some unnecessary code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
Make filestream frame handling safer by isolating frames before returning them.
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.
This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.
In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).
(issue #15586)
Reported by: globalnetinc
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has had the ability to control T.38 FAX error correction mode on a per-peer
(or global) basis for a couple of releases now, which is where it should have been
all along. This patch removes the ability to configure it in udptl.conf, but issues
a warning if the user tries to do, telling them to look at sip.conf.sample for how
to configure it now. For any SIP peers that are T.38 enabled in sip.conf, there is
already a default for FEC error correction even if the user does not specify any mode,
so this change will not turn off error correction by default, it will have the same
default value that has been in the udptl.conf sample file.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_cel_report_event would geet a reference to the
bridged channel. However, certain return paths, such
as if CEL was not enabled, would result in a reference
leak. All return paths now properly unref the channel.
(closes issue #15991)
Reported by: mmichelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Including version.h here causes this file to get recompiled after
every commit or update, which is not needed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_channel_get_full() tries to use OBJ_POINTER to optimize name-based
channel lookups, but this will not work properly when the channel's full
name was not supplied; for name-prefix searches, there is no value in
doing a hash-based lookup, and in fact doing so could result in many
channels being skipped.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the functionality here is gained simply by setting the feature flag
on the bridge config. However, the dial limit functionality has been moved from
app_dial to the features code and has been made public so both app_dial and
the bridge app can use it.
(closes issue #13165)
Reported by: tim_ringenbach
Patches:
app_bridge_options_r138998.diff uploaded by tim ringenbach (license 540),
modified by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218867 | dbrooks | 2009-09-16 13:00:45 -0500 (Wed, 16 Sep 2009) | 13 lines
Fixes CID pattern matching behavior to mirror that of extension pattern matching.
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In passing, correct the formatting of the Timestamp attribute so that there is a
space after the colon and before the value.
(closes issue #15861)
Reported by: Ivan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a document describing the language prompt submission process,
licensing terms and other issues related to that process. In addition, it
modifies the sound file searching process to support language codes with
any number of suffices (not limited to just "xx" or "xx_YY"), so that prompts
can be named with gender, customer/company, etc. suffices as well.
(closes issue #15771)
Reported by: jtodd
Patches:
language-criteria.txt uploaded by jtodd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Init the parkings list member of struct parkinglot.
Thanks Sean for the explanation why this should be here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One note on defining _POSIX_C_SOURCE: while this feature test macro
works to require certain behaviors on Linux, it works differently on *BSD
platforms to REMOVE certain API calls that are not in the POSIX specification,
such as vasprintf(3). Thus, defining it while depending upon vasprintf (and
other extensions to the POSIX standard) to be defined is a recipe to ensure
that Asterisk is only buildable on Linux.
Hence, this define which was meant to INCREASE portability, effectively
ensures the opposite.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines
Modify comment to be a bit more accurate.
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #15786)
Reported by: a_villacis
Patches:
asterisk-1.6.2.0-beta4-manager-fix-crash-on-include-nonexistent-file.patch uploaded by a villacis (license 660)
(Plus a few of my own, to catch the remaining places within manager.c where it could have been a problem)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added DYNAMIC_FEATURENAME which holds the last triggered dynamic feature.
Added DYNAMIC_PEERNAME which holds the unique channel name on the other side
and is set when a dynamic feature is triggered.
(closes issue #14663)
Reported by: tamiel
Patches:
20090313_features.diff uploaded by tamiel (license 712)
Tested by: tamiel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines
ast_write() ignores ast_audiohook_write() results
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r212763 | seanbright | 2009-08-18 12:36:00 -0400 (Tue, 18 Aug 2009) | 11 lines
Delay the creation of temporary files until we have a valid manager command to handle.
Without this patch, asterisk creates a temporary file before determining if the
specified command is valid. If invalid, we weren't properly cleaning up the file.
(closes issue #15730)
Reported by: zmehmood
Patches:
M15730.diff uploaded by junky (license 177)
Tested by: zmehmood
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logic here was reversed as ast_safe_system returns -1 on error and not on
success. Fix suggested by reporter.
(closes issue #15667)
Reported by: loic
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on a post on the gcc-help mailing list and some subsequent reading,
we can increase our portability to various platforms by directly defining
the POSIX and X/OPEN API feature sets we wish to have available. This patch
does that, and also includes a double-check to ensure that the system
we are compiling on can actually provide the requested feature sets.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
documentation of a function/application.
This will make reading the docs on the CLI way more easy.
(closes issue #15694)
Reported by: mvanbaak
Patches:
2009081100-extralinesoptionlist.diff.txt uploaded by mvanbaak (license 7)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Even though the get_channel_by_name() API advertised that you could search by
name or uniqueid (just as the old API did), searching by uniqueid was not
actually implemented. This patch fixes that problem.
The ast_channel_get_full() function now makes a second search attempt by
uniqueid if the parameter was a name. The channel comparison function also
now knows how to compare by unqieueid.
Finally, a bug was fixed in passing where OBJ_POINTER was being passed in some
scenarios where it should not have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.
(closes issue #15649)
Reported by: dazza76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The find_channel_by_group callback was only looking at the channel that was
attempting to make the pickup instead of the other channels in the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) | 18 lines
Allow for UDPTL to use only even-numbered ports if desired.
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Requiring 'module reload' to reload everything, including
core etc makes russell very unhappy.
The default configuration already loads the 'friendly' aliases template.
Added 'reload=module reload' to that template.
Also removed the comment in main/cli.c that reload should come back.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208746 | jpeeler | 2009-07-25 01:19:50 -0500 (Sat, 25 Jul 2009) | 7 lines
Fix compiling under dev-mode with gcc 4.4.0.
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I keep getting annoyed at having to type "module reload" to reload everything,
so I'm adding a note that we need to add "reload" back. "module reload" doesn't
really make sense as the command to reload everything, including the core.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208706 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207647 | kpfleming | 2009-07-21 08:04:44 -0500 (Tue, 21 Jul 2009) | 12 lines
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines
Only do the chan->fdno check in ast_read() in a developer build.
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206867 | dvossel | 2009-07-16 16:24:16 -0500 (Thu, 16 Jul 2009) | 8 lines
avoid segfault caused by user error
If the CALLERPRES() dialplan function is set to nothing,
a segfault occurs. This is user error to begin with, but
I'd rather see a cli warning message than have Asterisk
crash on me.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces the security events API. This API is to be used by
Asterisk components to report events that have security implications.
A simple example is when a connection is made but fails authentication. These
events can be used by external tools manipulate firewall rules or something
similar after detecting unusual activity based on security events.
Inside of Asterisk, the events go through the ast_event API. This means that
they have a binary encoding, and it is easy to write code to subscribe to these
events and do something with them.
One module is provided that is a subscriber to these events - res_security_log.
This module turns security events into a parseable text format and sends them
to the "security" logger level. Using logger.conf, these log entries may be
sent to a file, or to syslog.
One service, AMI, has been fully updated for reporting security events.
AMI was chosen as it was a fairly straight forward service to convert.
The next target will be chan_sip. That will be more complicated and will
be done as its own project as the next phase of security events work.
For more information on the security events framework, see the documentation
generated from doc/tex/. "make asterisk.pdf"
Review: https://reviewboard.asterisk.org/r/273/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pthread implementations. Casting it to an unsigned int fixes compiler warnings.
Tested on OpenBSD and Linux both 32 and 64 bit
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Park() was not respecting the arguments passed to it. Any extension/context/priority
given to it was being ignored. This patch remedies this.
(closes issue #15380)
Reported by: DLNoah
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While doing some reading about OpenSSL, I noticed a couple of things that
needed to be improved with our usage of OpenSSL.
1) We had initialization of the library done in multiple modules. This has now
been moved to a core function that gets executed during Asterisk startup.
We already link OpenSSL into the core for TCP/TLS functionality, so this
was the most logical place to do it.
2) OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows applications that request T.38 negotiation on a channel that
does not support it to get the proper indication that it is not supported, rather
than thinking that negotiation was started when it was not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204681 | dvossel | 2009-07-02 10:05:57 -0500 (Thu, 02 Jul 2009) | 14 lines
Improved mapping of extension states from combined device states.
This fixes a few issues with incorrect extension states and adds
a cli command, core show device2extenstate, to display all possible
state mappings.
(closes issue #15413)
Reported by: legart
Patches:
exten_helper.diff uploaded by dvossel (license 671)
Tested by: dvossel, legart, amilcar
Review: https://reviewboard.asterisk.org/r/301/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204556 | tilghman | 2009-06-30 15:23:51 -0500 (Tue, 30 Jun 2009) | 6 lines
More incorrect language codes, plus ensuring that regionalizations use the specified language, and not English for grammar.
(closes issue #15022)
Reported by: greenfieldtech
Patches:
20090519__issue15022.diff.txt uploaded by tilghman (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203785 | russell | 2009-06-26 16:16:39 -0500 (Fri, 26 Jun 2009) | 15 lines
Don't fast forward past the end of a message.
This is nice change for users of the voicemail application. If someone gets a
little carried away with fast forwarding through a message, they can easily
get to the end and accidentally exit the voicemail application by hitting the
fast forward key during the following prompt.
This adds some safety by not allowing a fast forward past the end of a message.
(closes issue #14554)
Reported by: lacoursj
Patches:
21761.patch uploaded by lacoursj (license 707)
Tested by: lacoursj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also change the default casing of the string contants to lowercase. This really
just saves us from have to lowercase them later when displaying them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matthew Nicholson
Joshua Colp
David Vossel
Tilghman Lesher
Mark Michelson
Olle Johansson
Russell Bryant
David Brooks
Jason Parker
Kevin P. Fleming
Richard Mudgett
Terry Wilson
Jeff Peeler
Sean Bright
Michiel van Baak