| Age | Commit message (Collapse) | Author |
|---|
|
In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.
Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.
Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16
|
|
A previous commit added plumbing to bridge_softmix to allow for an SFU
experience with Asterisk. This commit adds an option to app_confbridge
that allows for a confbridge to actually make use of the SFU video mode.
SFU mode is implemented in a "set it and forget it" kind of way. That
is, when the bridge is created, if SFU mode is enabled, then the video
mode gets set to SFU and cannot be changed. Future improvements may
allow for a hybrid experience (e.g. forward multiple video streams,
specifically those of the most recent talkers), but for this addition,
no such capability is present.
Change-Id: I87bbcb63dec6dbbb42488f894871b86f112b2020
|
|
This sets up the "plumbing" in bridge_softmix to
be able to accommodate Asterisk asking as an SFU
(selective forwarding unit) for conferences.
The way this works is that whenever a channel enters or leaves a
conference, all participants in the bridge get sent a stream topology
change request. The topologies consist of the channels' original
topology, along with video destination streams corresponding to each
participants' source video streams. So for instance, if Alice, Bob, and
Carol are in the conference, and each supplies one video stream, then
the topologies for each would look like so:
Alice:
Audio,
Source video(Alice),
Destination Video(Bob),
Destination video (Carol)
Bob:
Audio,
Source video(Bob)
Destination Video(Alice),
Destination video (Carol)
Carol:
Audio,
Source video(Carol)
Destination Video(Alice),
Destination video (Bob)
This way, video that arrives from a source video stream can then be
copied out to the destination video streams on the other participants'
channels.
Once the bridge gets told that a topology on a channel has changed, the
bridge constructs a map in order to get the video frames routed to the
proper destination streams. This is done using the bridge channel's
stream_map.
This change is bare-bones with regards to SFU support. Some key features
are missing at this point:
* Stream limits. This commit makes no effort to limit the number of
streams on a specific channel. This means that if there were 50 video
callers in a conference, bridge_softmix will happily send out topology
change requests to every channel in the bridge, requesting 50+
streams.
* Configuration. The plumbing has been added to bridge_softmix, but
there has been nothing added as of yet to app_confbridge to enable SFU
video mode.
* Testing. Some functions included here have unit tests.
However, the functionality as a whole has only been verified by
hand-tracing the code.
* Selectivenss. For a "selective" forwarding unit, this does not
currently have any means of being selective.
* Features. Presumably, someone might wish to only receive video from
specific sources. There are no external-facing functions at the moment
that allow for users to select who they receive video from.
* Efficiency. The current scheme treats all video streams as being
unidirectional. We could be re-using a source video stream as a
desetnation, too. But to simplify things on this first round, I did it
this way.
Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d
|
|
Rather than removing format_mp3 from ALL_C_MODS (which caused format_mp3
to not show up in menuselect), use .PHONY targets when the necessary
source files are not present.
ASTERISK-23951
Reported by: Tzafrir Cohen
Change-Id: I0a7512c51acc9e86043671795020b0de725bd9e8
|
|
Some of the test names were actually reserved words (true, false,
int, null, string, bool). When the jenkins test results analyzer
does its thing it tries to create a map using the test names as
keys and fails because they're reserved words.
Added "type_" to those test names.
Change-Id: I90d809f46969c78a1c605b736ff0635196a2cf1b
|
|
|
|
During the channel flag audit an incorrect change was
done. The flag should be cleared on the second channel.
ASTERISK-26469
Change-Id: I770c5a389550a2fb5a6ade942fccbb2e1d9199c8
|
|
ASTERISK-25294 #close
Reported by: Tzafrir Cohen
ASTERISK-26976 #close
Reported by: Alex
Change-Id: I789b1c3d1ed31365bbd9339fa58ef36f48833c40
|
|
|
|
|
|
|
|
|
|
|
|
ASTERISK-23951 #close
Reported by: Tzafrir Cohen
Change-Id: Iebf181d44bb735787fde4b5be863c4d7e2478a30
|
|
Enables runtime configuration of busy_timeout for sqlite databases.
Default timeout remains 1000ms.
ASTERISK-27014 #close
Change-Id: I8921a3aac3c335843be4cb17d2dd0a5c157a36da
|
|
|
|
...that can only be run by explicitly calling it with
'test execute category /DO_NOT_RUN/ name RAISE_SEGV'
This allows us to more easily test CI and debugging tools that
should do certain things when asterisk coredumps.
To allow this a new member was added to the ast_test_info
structure named 'explicit_only'. If set by a test, the test
will be skipped during a 'test execute all' or
'test execute category ...'.
Change-Id: Ia3a11856aae4887df9a02b6b081cc777b36eb6ed
|
|
|
|
|
|
|
|
|
|
This change allows the format of the EAGI audio pipe to be changed by
setting the dialplan variable 'EAGI_AUDIO_FORMAT' to the name of one of
the loaded formats.
ASTERISK-26124 #close
Change-Id: I7a10fad401ad2a21c68c2e7246fa357d5cee5bbd
|
|
Documented the 'beep' option in both the parameters list and the command
description.
ASTERISK-23839 #close
Change-Id: I4970395c922dbdce3f7cf0f56d5b065ec9aa53ea
|
|
Explicitly check that the appropriate number of arguments were passed to
SET VARIABLE before attempting to reference them. Also initialize the
arguments array to zeroes before populating it.
ASTERISK-22432 #close
Change-Id: I5143607d80a2724f749c1674f3126b04ed32ea97
|
|
If the generated XML documentation for a command does not end with a \n,
the postamble of the usage message does not appear on its own line.
ASTERISK-25662 #close
Change-Id: If190f1e9e37fe215fed95897d78d4a6e142b0020
|
|
Some devices separate format attributes with a semicolon followed by a
space, so trim blanks before trying to match them.
ASTERISK-27008 #close
Change-Id: Ia44cb2e4fef5c73dc541a29da79cb0e19c22d9cc
|
|
A change was done which added an 'in_call' flag to queue
members that was set to true while talking to an agent.
Unfortunately in practice this does not accurately reflect
whether they are talking to an agent or not. If a Local
channel is involved and a transfer is performed then the
app_queue application would incorrectly think the agent
was still in a call with the caller. This was done to
fix a race condition between an agent becoming available
by device state and the checking of the last call information
for the wrapup time. There was a small window where the
last call information would be the previous value instead
of the new one.
This change goes about fixing the original issue in a
different way by considering the call completed if device
state is received which would make the agent available
and if they are currently in a call. If this occurs the
last call information is updated before the agent becomes
available ensuring that old information is not present
when checking if the member should be called. This also
improves the transfer situation by actually updating
and enforcing the wrapup time.
ASTERISK-26399
ASTERISK-26400
ASTERISK-26715
ASTERISK-26975
Change-Id: Ife1cb686e3173b3a6d368601adef9aff69d4beea
|
|
|
|
When user leaves a conference, its channel calls async_play_sound_file()
in order to play the name announcement and then unlinks the sound file.
The async_play_sound_file() function adds a task to conference playback queue,
which then runs playback_common() function in a different thread.
It leads to a race condition when, in some cases, channel thread may unlink
the sound file before playback_common() had a chance to open it.
This patch creates a file deletion task, that is queued after playback.
ASTERISK-27012 #close
Change-Id: I412f7922d412004b80917d4e892546c15bd70dd3
|
|
When using rtcp mux if an rtcp payload came in it would still use the srtp
unprotect algorithm instead of the srtp unprotect rtcp method. Since rtcp
data was being passed to the rtp unprotect method this would result in an
error.
This patch ensures that the correct unprotect method is chosen by making
sure the passed in rtcp flag is appropriately set when rtcp mux is enabled
and an rtcp payload is received.
ASTERISK-26979 #close
Change-Id: Ic5409f9d1a267f1d4785fc5aed867daaecca6241
|
|
If we are offered or are offering RTCP-MUX, don't consider RTCP ICE
candidates. This confuses certain browsers (current Firefox for
example) and causes intial audio setup delays.
ASTERISK-26982 #close
Change-Id: Ifeaf47e83972fe8dbe58b7fb3d6d1823400cfb91
|
|
Additional variable to work alongside QUEUE_MAX_PENALTY and QUEUE_MIN_PENALTY,
including an extra parameter in queuerules.conf. This value causes lower
Agent penalty values to "raise up" so that they can join higher penalty agents
and be treated equally after a period of time.
ASTERISK-26995 #close
Change-Id: If1c6421a983667a5ac4c359f6dac25b212b4c459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ASTERISK-26939 #close
Change-Id: I7ea235ab39833a187db4e078f0788bd0af0a24fd
|
|
The while(1) loop in skinny_session wasn't checking for EOF so
a packet that was longer than a header but still truncated
would spin the while loop infinitely. Not only does this
permanently tie up a thread and drive a core to 100% utilization,
the call of ast_log() in such a tight loop eats all available
process memory.
Added poll with timeout to top of read loop
ASTERISK-26940 #close
Reported-by: Sandro Gauci
Change-Id: I2ce65f3c5cb24b4943a9f75b64d545a1e2cd2898
|
|
ASTERISK-26938 #close
Change-Id: I266490792fd8896a23be7cb92f316b7e69356413
|
|
Change-Id: I5661478f9cf12d431f730e42be79323b62831e92
|
|
If the channel does not have multi-stream support then this application acts
just like app_echo. If it does have multi-stream support then each stream is
echoed back to itself (one-to-one).
If a "num" is specified, then a new topology is made that contains clones (from
the channel's topology) of all media types that are not equal to the given
"type". If the media type differs then the first stream matching the "type" is
cloned into the new topology and then up to "num" - 1 of the same stream are
also cloned into it. Any additional streams from the original topology matching
the "type" are subsequently ignored (i.e. not added to the new topology).
For this same case when a frame is read from a stream that frame is still
echoed back like before, but now that frame is also echoed out to the
additional streams that matched on the specified "type".
ASTERISK-26997 #close
Change-Id: I254144486734178e196c7f590a26ffc13543ff2c
|
|
Added functions that convert a string to an unsigned integer or unsigned long.
A couple of unit test were also created to test the routines. The reasons for
adding these conversion utilities (and hopefully eventually more) are as
follows:
* Conversion routines are functionally contained with consistent and
better error checking
* The function names offer a better description of what is happening
* It encourages code reuse for easier bug fixing at a single source
* It's simpler to use
* It's unit testable
For instance, currently in a lot of places when converting to an integer or
similar the "sscanf" function is used. When using "sscanf" it may not be
immediately clear what's happening as it lacks semantic naming. Limited error
checking is usually done as well. For example, most of the time a check is done
to make sure the value converted, but does not check for overflows or negative
valued conversions when converting unsigned numbers.
Why use/wrap "strtoul" and not "sscanf" then? Primarily, it lacks some of the
built in error handling that "strtoul" has. For instance "strtoul" contains
overflow checks. Less so, but can still factor as reasons, "sscanf" is slightly
more complex in its use. And maybe a bit controversial, but it may be ("big if")
potentially slower than "strtoul" in some cases.
Change-Id: If7eaca4a48f8c7b89cc8b5a1f4bed2852fca82bb
|
|
|
|
|
|
When manipulating flags on a channel the channel has to be
locked to guarantee that nothing else is also manipulating
the flags. This change introduces locking where necessary to
guarantee this. It also adds helper functions that manipulate
channel flags and lock to reduce repeated code.
ASTERISK-26789
Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
|
|
Retransmissions of an initial INVITE could be queued in the serializer
before we have processed the first INVITE message. If the first INVITE
message doesn't get completely processed before the retransmissions are
seen then we could try to setup the same call from the retransmissions. A
symptom of this is seeing a (key exists) message associated with an
INVITE. An earlier change attempted to address this kind of problem by
calculating a distributor serializer to use for unassociated messages.
Part of that change also made incoming calls keep using that distributor
serializer. (ASTERISK-26088) However, some leftover code was still
deferring the INVITE processing to the session's serializer even though we
were already in that serializer. This not only is unnecessary but would
cause the same call resetup problem.
* Removed the code to defer processing the initial INVITE to the session's
serializer because we are already running in that serializer.
ASTERISK-26998 #close
Change-Id: I1e822d82dcc650e508bc2d40d545d5de4f3421f6
|
|
|
|
Change-Id: Ie1c2d83af66f27a449da09a68d987e0992627fee
|
