Reported by: MVF
Patches:
bug11736-2.diff uploaded by oej (license 306)
Tested by: oej, MVF, revolution
(russellb: This was the showstopper for the release.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@100740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@100581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@100465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
over 20 years ago... Resetting chan_sip to the size of BUFSIZ that I expected in my old
head to avoid to heavy memory allocations on some systems.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
masquerade, the monitors on the two channels involved are swapped. In 99% of the cases
this results in the desired effect. However, if monitoring a local channel, this caused
the monitor which was on the local channel to get moved onto a channel which is immediately
hung up after the masquerade has completed. By swapping the monitors prior to the masquerade,
we avoid the problem by tricking the masquerade into placing the monitor back onto the channel
where we want it.
During the investigation of the issue, the channel's monitor was the only thing that was swapped
in such a manner which did not make sense to have done. All other variable swapping made sense.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the local_pvt was held and it was attempting to lock a channel, which is the
incorrect locking order.
(closes issue #11730)
Reported by: UDI-Doug
Patches:
11730.patch uploaded by putnopvut (license 60)
Tested by: UDI-Doug
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
buffer, instead of a massive buffer on the stack. This fixes a crash reported
by Qwell due to running out of stack space when building with LOW_MEMORY defined.
On a very related note, the usage of BUFSIZ in various places in chan_sip is
arbitrary and careless. BUFSIZ is a system specific define. On my machine,
it is 8192, but by definition (according to google) could be as small as 256.
So, this buffer in check_auth was 16 kB. We don't even support SIP messages
larger than 4 kB! Further usage of this define should be avoided, unless it
is used in the proper context.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
translator pvt is freed before we use the frame, bad things happen.
2) Getting a failure from ast_sched_delete means that the schedule
ID is currently running. Don't just ignore it.
(Closes issue #11698)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As underlined in issue #10437 by Josh, we need to prevent a possible
memory leak. We only set the name part of the caller id, the number
part is not relevant when dealing with JIDs.
Closes issue #11549.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This deadlock was introduced by the fix to ensure that channels are properly
locked when handling channel variables. There were sections of this code where
the channel pvt was locked before the channel lock, when in fact it _must_ be
the other way around.
(closes issue #11582)
Reported by: bugi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I wonder if Asterisk can run at all without res_features. My guess is that
there's propably a lot of more modules and the core that depends on it.
Reported by: caio1982
(closes issue #11574)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Isue #10690.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to reinvite each other in 1.4 and trunk.
This patch implements support for the 491 error code that
Asterisk 1.4 generates on situations where we get an
incoming INVITE and already has one in progress.
Thanks to mavetju for reporting and to Raj Jain for an
excellent explanation of the problem.
Patch by myself. Tested with 8 Asterisk servers connected
to each other in a training network.
Closes issue #10481
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_uri_decode function as opposed to my home-rolled one. Also added
comments.
Thanks to oej for pointing me in the right direction
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in extensions.conf AND maintain their escaped characters when forming URI's
(closes issue #10681, reported by cahen, patched by me, code review by file)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
asterisk channel must be locked, as this data may change at any time.
(I have seen numerous reports of crashes related to the handling of channel
variables. There are a couple of issues on the bug tracker related to it,
but it has also been noted on IRC and mailing lists. So, I am finding and
fixing some places where channel variables are handled improperly.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and ast_string_field_free_all to ast_string_field_reset_all
to avoid misuse (due to too similar names and an error in
documentation). Fix two related memory leaks in app_meetme.
No need to merge to trunk, different fix already applied there.
Not applicable to 1.2
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a race condition related to the handling of POKEing peers. Essentially,
a reference to a peer is held by the scheduler when there are pending callbacks,
but the reference count didn't reflect it. So, it was possible for a peer to hit
a reference count of zero and have its destructor begin to be called at the same
time that the scheduler thread ran a POKE related callback. If that happened,
a crash would likely occur.
(closes issue #11082, closes issue #11094)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@87686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sense for it to default to off. The default configuration file has it on, and
proper RFC behavior, as indicated by a comment in the code, is for it to be on.
So, let's have it on by default to make lives easier.
(closes issue #10954, suggested by jtodd)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85604 65c4cc65-6c06-0410-ace0-fbb531ad65f3
due to various buffer sizes around the code, but I still didn't like seeing a
non length-limited copy of data coming off of the wire into a stack buffer, as
this would be a problem in the future if buffer sizes elsewhere got changed or
size limitations removed ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change h323 to only remove the Makefile on a dist-clean, rather than a clean.
This fixes a bug I found with trying to run make after a make clean
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84291 65c4cc65-6c06-0410-ace0-fbb531ad65f3
session at Astricon. chan_sip did not output any message when a call was
rejected because the extension was not found. This adds a verbose message
(at verbose level 3) to note when this happens.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@83941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
peers. Instead, use an iterator. By using an iterator, the peers container
is not locked while the POKE is being done. It can cause a deadlock if the
peers container is locked because poking a peer will try to lock pvt structs,
while there is a lot of other code that will hold a pvt lock when trying to
go lock the peers container.
(reported to me directly by Loic Didelot. Thank you for the debug info!)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@83175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: dimas
Patches:
chan_sip.patch uploaded by dimas (license 88)
Read in subscribecontext option in general to be the default.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@83070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: kenw
Patches:
9724.txt uploaded by russell (license 2)
Tested by: kenw, russell
Resolve a deadlock that occurs when doing a SIP transfer to parking.
I come across this type of deadlock fairly often it seems. It is very important
to mind the boundary between the channel driver and the core in respect to the
channel lock and the channel-pvt lock. Channel drivers lock to lock the
pvt and then the channel once it calls into the core, while the core will do
it in the opposite order. The way this is avoided is by having channel drivers
either release their pvt lock while calling into the core, or such as in this
case, unlocking the pvt just long enough to acquire the channel lock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also changed load_module function to use defines rather than numbers for return values.
Issue 10651, patch by rbraun_proformatique, with additions by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jamesgolovich
Patches:
asterisk-iaxfirmwareleak.diff.txt uploaded by jamesgolovich (license 176)
Fix memory leak when unloading chan_iax2. The firmware files were not being freed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
handling blocks in the code for building peers. The peer object destructor
does this and doing it twice will cause a crash.
(closes issue #10625, reported by and patched by pnlarsson)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: casper
Patches:
chan_sip.c.80129.diff uploaded by casper (license 55)
Remove needless check for AUTH_UNKNOWN_DOMAIN. It was impossible for it to ever be that value.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
not return because it blocks. later chan_misdn would try to queue a frame like
a AST_CONTROL_ANSWER which could result in a deadlock situation. misdn_read
will now not block forever anymore, and we don't queue the ANSWER frame at all
when we already was called with misdn_answer -> answer would be called twice.
Also we don't explicitly send a RELEASE_COMPLETE on receiption of a RELEASE
anymore, because mISDN does that for us, this resulted in a problem on some
switches, which would block our port after some calls for a short while.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
he doesn't cause a queue's announce file to be interrupted. Also went ahead and did the
same for the '*' key and for ending a call.
(closes issue #10528, reported by deskhack, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jesselang
Patches:
chan_sip-ChannelReload-20080825.patch uploaded by jesselang (license 202)
Remove an extra \r\n to make the ChannelReload event conform with every other event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
places that scheduled items to be executed by the scheduler thread did not
signal the scheduler thread to wake up so that it could recalculate the time
until the next action. These changes will make the scheduler thread more
responsive and ensure that actions get executed as close to when intended as
possible instead of it being possible for very long delays.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
starts, then don't give up on poking peers. Allow the poke to get rescheduled
so that it will work once the dnsmgr is able to resolve the host.
(closes issue #10521, patch by jamesgolovich)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Googletalk calls are answered too early, which results in CDRs wrongly
stating that a call was ANSWERED when the calling party cancelled a
call before before being established.
We must not answer the call upon reception of a 'transport-accept' iq
packet, but this packet still needs to be acknowledged, otherwise the
remote peer would close the call (like in #8970).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the peers and users are being stored in a linked list, that they go in the
list in the same order that the older code used. This is necessary to maintain
the behavior of which peers and users get matched when traversing the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects. It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them. The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.
To accomplish this, I used the astobj2 reference counted object model. This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone. I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.
As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating. Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.
The use of the hash table will be made the default in trunk. It is not the default
in 1.4 because it changes the behavior slightly. Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration. The hash table does not guarantee any order in the container,
so this behavior will be going away. It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.
If you have any questions, feel free to ask on the asterisk-dev list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
limit on how many history entires will be stored for each SIP dialog. It is
currently set to 50, but can be increased if deemed necessary.
(closes issue #10421, closes issue #10418, patches suggested by jmoldenhauer,
patches updated by me)
(Security implications documented in AST-2007-020)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_read to return NULL in the case that the channel has been hung up.
(crash reported by anonymouz666 on IRC in #asterisk-dev)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Caused by fix for issue 9938.
I basically took the code that existed before 9938 was fixed, and
copied it into a new function - ast_unescape_semicolon
There should be very few places this will be needed (pbx_config
does NOT need this (see issue 9938 for details))
Issue 10430, patch by me, with help/ideas from murf (thanks murf).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to the scheduler to ensure that they don't overwrite the ID of a previously
scheduled item. If there is one, it should be removed.
(closes issue #10391, closes issue #10256, probably others, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and scheduling multi-threaded. Unfortunately, we have to do some expensive
deadlock avoidance when queueing frames on to the ast_channel owner of the IAX2
pvt struct. This was already handled for regular frames, but ast_queue_hangup
and ast_queue_control were still used directly. Making these changes introduced
even more places where the IAX2 pvt struct can disappear in the context of a
function holding its lock due to calling a function that has to unlock/lock it
to avoid deadlocks. I went through and fixed all of these places to account for
this possibility.
(issue #10362, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ringinuse=no for the queue.
(closes issue #10215, reported by Doug, repaired by me)
Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: irroot
Patches:
sip_timeout.patch uploaded by irroot (license 52)
Change hardcoded timer value to defined value. I'm doing this in 1.4 as well so if it needs to be changed in the future this place would not have been forgotten.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
core issue. You can not call find_callno() while holding a pvt lock as this
function has to lock another (every) other pvt lock. Doing so can lead to a
classic deadlock. So, I am tracking down all of the code paths where this
can happen and fixing them.
The fix I committed earlier today was along the same theme. This patch fixes
some code down the path of authenticate_reply.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
call find_callno. You can't hold a pvt lock while calling find_callno because
it goes through and locks every single one looking for a match.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: haklin
Don't set the callerid name and number a second time on a newly created channel. ast_channel_alloc itself already sets it and setting it twice would cause a memory leak.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Olle Johansson
Jason Parker
Christian Richter
Mark Michelson
Tilghman Lesher
Joshua Colp
Philippe Sultan
Kevin P. Fleming
Luigi Rizzo
Dwayne M. Hubbard
Jim Dixon