| Age | Commit message (Collapse) | Author |
|---|
|
This works the same as for AMI manager variables. Set
"channelvars=foo,bar" in your ari.conf general section, and then the
channel variables "foo" and "bar" (along with their values), will
appear in every Stasis websocket channel event.
ASTERISK-26492 #close
patches:
ari_vars.diff submitted by Mark Michelson
Change-Id: I5609ba239259577c0948645df776d7f3bc864229
|
|
This reverts commit f073f648b87d45e4729969fd2d83695c300757d1.
Multiple testsuite failures were detected after the fact.
Change-Id: I968c380418bf65c7166f6ecff30fe8e247ea6682
|
|
There are several places in Asterisk that have duplicated logic
for deferring important frames until later.
This commit adds a couple of API calls to facilitate this automatically.
ast_channel_start_defer_frames(): Future reads of deferrable frames on
this channel will be deferred until later.
ast_channel_stop_defer_frames(): Any frames that have been deferred get
requeued onto the channel.
ASTERISK-26343
Change-Id: I3e1b87bc6796f222442fa6f7d1b6a4706fb33641
|
|
|
|
|
|
|
|
When a channel is made the video source, the bridge holds a reference to
it. Whenever the video source changes, that reference is released.
However, a ref leak does occur if the channel leaves the bridge (such as
being hung up) while it is the video source, as the bridge never
releases the ref in such a case.
This patch adds a line to the bridge_channel_internal_join routine such
that, when a channel finishes its time in the bridge, it notifies the
bridge via ast_bridge_remove_video_src that if it is a video source its
reference should be released.
ASTERISK-26555 #close
Change-Id: I3a2f5238a9d2fc49c591f0e65199d782ab0be76a
|
|
It's actually quite useful to see the source of a video stream change.
This doesn't happen terribly often, even with talk detection - but when
it does, it's nice to know which channel is now providing your video
stream.
As a verbose 5 level message, it shouldn't be terribly spammy or costly
to have, and is 'lower level' then most other verbose messages that the
bridge system emits.
ASTERISK-26555
Change-Id: Ia1c20ecafa9670171fd38bddcf3beccae47fb15c
|
|
The readdir_r function has been deprecated and should no longer be used. This
patch removes the readdir_r dependency (replaced it with readdir) and also moves
the directory search code to a more centralized spot (file.c)
Also removed a strict dependency on the dirent structure's d_type field as it
is not portable. The code now checks to see if the value is available. If so,
it tries to use it, but defaults back to using the stats function if necessary.
Lastly, for most implementations of readdir it *should* be thread-safe to make
concurrent calls to it as long as different directory streams are specified.
glibc falls into this category. However, since it is possible that there exist
some implementations that are not safe, locking has been added for those other
than glibc.
ASTERISK-26412
ASTERISK-26509 #close
Change-Id: Id8f54689b1e2873e82a09d0d0d2faf41964e80ba
|
|
Since adding all remaining rates of Signed Linear (ASTERISK-24274), SILK
(Gerrit 3136) and Codec 2 (ASTERISK-26217), no RTP Payload Type is left in the
dynamic range (96-127). RFC 3551 section 3 allows to reassign other ranges.
Consequently, when the dynamic range is exhausted, this change utilizes payload
types in the range between 35 and 63 giving room for another 29 payload types.
ASTERISK-26311 #close
Change-Id: I7bc96ab764bc30098a178b841cbf7146f9d64964
|
|
|
|
ASTERISK-25070
Change-Id: I43bf94d2d36d3d8a8d0df40cd6c027d65a462814
|
|
The NewConnectedLine event has been added by commit fe7671f, but the
documentation was missing.
ASTERISK-26537 #close
Change-Id: I7fc331f18caa28492da9303e576f70884ca8c9e6
|
|
|
|
Every ao2 object contains storage for a private variable data_size,
though the value is never read if AO2_DEBUG is disabled. This change
makes the variable conditional, reducing memory usage.
ASTERISK-26524 #close
Change-Id: If859929e507676ebc58b0f84247a4231e11da07f
|
|
main/Makefile includes third-party/pjproject/build.mak but
doesn't set PJDIR beforehand so "include $(PJDIR)/version.mak"
evaluates to "/version.mak". Fix is to set PJDIR in main/Makefile
before the include.
Change-Id: I0f7c67d60209049056fe9c4b041bf0463aa95604
|
|
It is only safe to run ast_register_cleanup callbacks when all modules
have been unloaded. Previously these callbacks were run during graceful
shutdown, making it possible to crash during shutdown.
ASTERISK-26513 #close
Change-Id: Ibfa635bb688d1227ec54aa211d90d6bd45052e21
|
|
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
|
|
|
|
Change-Id: I7c1f4eb051177ee22cbe97e063d4a3effe29be30
|
|
ARI and AMI allow for an explicit channel ID to be specified
when originating channels. Unfortunately, there is nothing in
place to prevent someone from using the same ID for multiple
channels. Further complicating things, adding ID validation to channel
allocation makes it impossible for ARI to discern why channel allocation
failed, resulting in a vague error code being returned.
The fix for this is to institute a new method for channel errors to be
discerned. The method mirrors errno, in that when an error occurs, the
caller can consult the channel errno value to determine what the error
was. This initial iteration of the feature only introduces "unknown" and
"channel ID exists" errors. However, it's possible to add more errors as
needed.
ARI uses this feature to determine why channel allocation failed and can
return a 409 error during origination to show that a channel with the
given ID already exists.
ASTERISK-26421
Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06
|
|
ASTERISK-26444 #close
Change-Id: I91d645b7e6e5dba35f8c410df2be77a8c0e3acb8
|
|
|
|
CDRs form chains. When the root of the chain is destroyed, it then
unreferences the next CDR in the chain. That CDR is destroyed, and it
then unreferences the next CDR in the chain. This repeats until the end
of the chain is reached. While this typically does not cause any sort of
problems, it is possible in strange scenarios for the CDR chain to grow
way longer than expected. In such a scenario, the destruction pattern
can result in a stack overflow.
This patch fixes the problem by switching from a recursive pattern to an
iterative pattern for destruction. When the root CDR is destroyed, it is
responsible for iterating over the rest of the CDRs and unreferencing
each one. Other CDRs in the chain, since they are not the root, will
simply destroy themselves and be done. This causes the stack depth not
to increase.
ASTERISK-26421 #close
Reported by Andrew Nagy
Change-Id: I3ca90c2b8051f3b7ead2e0e43f60d2c18fb204b8
|
|
Since Asterisk 1.8, the command "core set debug" on the command-line interface
asks not for a file (.c) but a module name. This change shows modules (.so) on
the auto-completion via a tabulator or the question mark. Now, when you
partially type a module name, TAB or ?, you get the correct candidiates.
ASTERISK-26480
Change-Id: I1213f1dd409bd4ff8de08ad80cb0c73cafb1bae0
|
|
ast_set_default_eid was searching for ethX, emX, enoX, ensX and even
pciD#U interface names. While this was a good attempt, it wasn't
inclusive enough to capture interfaces like enp6s0 or ens6d1, etc.
Rather than relying on interface names, we now simply find the first
interface returned by the OS that has a hardware address and that
address isn't all 0x00 or all 0xff. The code IS different for BSD,
Solaris and Linux based on what method is available for enumerating
interfaces.
Tested on:
FreeBSD9
CentOS6
Ubuntu14
Fedora24
I was unable to test on Solaris at this time but the code for Solaris
is used elsewhere at Digium.
Change-Id: Iaa6db87ca78a9a375e47d70e043ae08c1448cb72
|
|
|
|
|
|
|
|
Added needed UTF-8 checks before constructing json objects in various
files for strings obtained outside the system. In this case string values
from a channel driver's peer and not from the user setting channel
variables.
* aoc.c: Fixed type mismatch in s_to_json() for time and granularity json
object construction.
ASTERISK-26466
Reported by: Richard Mudgett
Change-Id: Iac2d867fa598daba5c5dbc619b5464625a7f2096
|
|
* Updated unit test as ast_json_name_number() is now NULL tolerant.
ASTERISK-26466 #close
Reported by: Richard Mudgett
Change-Id: I7d4e14194f8f81f24a1dc34d1b8602c0950265a6
|
|
Since the json library does not make the check function public we
recreate/copy the function in our interface module.
ASTERISK-26466
Reported by: Richard Mudgett
Change-Id: I36d3d750b6f5f1a110bc69ea92b435ecdeeb2a99
|
|
* In s_to_json() removed unnecessary ast_json_ref() to ast_json_null()
when creating the type json object. The ref is a noop.
Change-Id: I2be8b836876fc2e34a27c161f8b1c53b58a3889a
|
|
|
|
|
|
Remote asterisk consoles should only display verbose log messages
created by the daemon. The first patch for ASTERISK-26410 caused
a couple verbose messages to be printed when the rasterisk process
ended.
ASTERISK-26410
Change-Id: Ie2a1bb3753ad2724c0349ec1a336f52f7117b52a
|
|
The main frame read and write handlers in main/channel.c don't use the
optimum placement in the processing flow for calling audiohooks
callbacks, as far as codec translation is concerned. This change places
the audiohooks callback code:
* After the channel read translation if the frame is not linear before
the translation, thereby increasing the chance that the frame is linear
as required by audiohooks
* Before the channel write translation if the frame is linear at this
point
This prevents the audiohooks code from instantiating additional
translation paths to/from linear where a linear frame format is already
available, saving valuable CPU cycles
ASTERISK-26419
Change-Id: I6edd5771f0740e758e7eb42558b953f046c01f8f
|
|
This change introduced some fax test failures
that have not yet been addressed. So this is
not forgotten I'm submitting a change which
reverts it.
This reverts:
d56fc3b36b7bb59b5506129b9895b6c3341350c9.
ASTERISK-25629
Change-Id: Ibc2f23c38643f5a2c89cf8915ae2d805b81bc3d5
|
|
Asterisk only supports mono audio at the moment.
This patch adds interleaved two-channel audio to Asterisk's channels.
ASTERISK-26292
Change-Id: I7a547cea0fd3c6d1e502709d9e7e39605035757a
|
|
* Compile __ast_assert_failed unconditionally.
* Use __ast_assert_failed to log messages from log_bad_ao2
* Remove calls to ast_assert(0) that happen after log_bad_ao2 was run.
Change-Id: I48f1af44b2718ad74a421ff75cb6397b924a9751
|
|
This allows asterisk to compiled with LOW_MEMORY to load modules built
without LOW_MEMORY.
ASTERISK-26398 #close
Change-Id: I24b78ac9493ab933b11087a8b6794f3c96d4872d
|
|
Verbose messages should be printed to the console if the sublevel is
less than option_verbose. This fix ensures the welcome message with
copyright and license are printed at daemon and interactive rasterisk
startup.
ASTERISK-26410 #close
Change-Id: Ia44235e30ec328aba92ea2c8a837b094e65c9a03
|
|
Users upgrading from asterisk 13.5 to a later version and who use
realtime with peers that have mailboxes were experiencing runaway
situations that manifested as a continuous stream of taskprocessor
congestion errors, memory leaks and an unresponsive chan_sip.
A related issue was that setting rtcachefriends=no NEVER worked in
asterisk 13 (since the move to stasis). In 13.5 and earlier, when a
peer tried to register, all of the stasis threads would block and
chan_sip would again become unresponsive. After 13.5, the runaway
would happen.
There were a number of causes...
* mwi_event_cb was (indirectly) calling build_peer even though calls to
mwi_event_cb are often caused by build_peer.
* In an effort to prevent chan_sip from being unloaded while messages
were still in flight, destroy_mailboxes was calling
stasis_unsubscribe_and_join but in some cases waited forever for the
final message.
* add_peer_mailboxes wasn't properly marking the existing mailboxes
on a peer as "keep" so build_peer would always delete them all.
* add_peer_mwi_subs was unsubscribing existing mailbox subscriptions
then just creating them again.
All of this was causing a flood of subscribes and unsubscribes on
multiple threads all for the same peer and mailbox.
Fixes...
* add_peer_mailboxes now marks mailboxes correctly and build_peer only
deletes the ones that really are no longer needed by the peer.
* add_peer_mwi_subs now only adds subscriptions marked as "new" instead
of unsubscribing and resubscribing everything. It also adds the peer
object's address to the mailbox instead of its name to the subscription
userdata so mwi_event_cb doesn't have to call build_peer.
With these changes, with rtcachefriends=yes (the most common setting),
there are no leaks, locks, loops or crashes at shutdown.
rtcachefriends=no still causes leaks but at least it doesn't lock, loop
or crash. Since making rtcachefriends=no work wasnt in scope for this
issue, further work will have to be deferred to a separate patch.
Side fixes...
* The ast_lock_track structure had a member named "thread" which gdb
doesn't like since it conflicts with it's "thread" command. That
member was renamed to "thread_id".
ASTERISK-25468 #close
Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0
|
|
|
|
|
|
|
|
When retrieving presence state information there is no
guarantee that the subtype and message passed in are
set to NULL. This change ensures they are.
ASTERISK-26397 #close
Change-Id: If38cd730e409e9a9b6eb9adef6591d15a9e61f86
|
|
|
|
|
|
|
