Separate "name" into "classname" and "name".
Use '.' for classname separator instead of '/'.
Prefix reserved words with '_'.
Wrap output with a top-level "testsuites" element.
Change-Id: Iec1a985eba1c478e5c1d65d5dfd95cb708442099
There is a rare case (do to the infrequent timing involved) where
CDR submission threads in batch mode can deadlock with a currently
running CDR batch process. This patch should remove the need for
holding the lock in the scheduler and should clean a few code
paths up that inconsistently submitted new work to the CDR batch
processor.
ASTERISK-27909
Change-Id: I6333e865db7c593c102c2fd948cecdb96481974d
Reported-by: Denis Lebedev
The AMI action was directly sending the text to the channel driver.
However, this makes two threads attempt to handle media and runs afowl of
CHECK_BLOCKING.
* Queue a read action to make the channel's media handling thread actually
send the text message. This changes the AMI actions success/fail response
to just mean the text was queued to be sent not that the text actually got
sent. The channel driver may not even support sending text messages.
ASTERISK-27943
Change-Id: I9dce343d8fa634ba5a416a1326d8a6340f98c379
In addition to text/* content types, incoming_in_dialog_request now
accepts application/* content types.
Also fixed a length issue when copying the body text. It was one
character short.
ASTERISK-27942
Change-Id: I4e54d8cc6158dc47eb8fdd6ba0108c6fd53f2818
* changes:
channel.c: Make CHECK_BLOCKING() save thread LWP id for messages.
channel.c: Fix usage of CHECK_BLOCKING()
autoservice: Don't start channel autoservice if the thread is a user interface.
With ./configure --enable-dev-mode[=noisy], the build fails because every
warning gets an error. Therefore, Asterisk has to be free of warnings and this
variable must go.
Change-Id: I63dd2bc4833b9bdb04602f83422d16caf289d46a
There can be one and only one thread handling a channel's media at a time.
Otherwise, we don't know which thread is going to handle the media frames.
ASTERISK-27625
Change-Id: I4d6a2fe7386ea447ee199003bf8ad681cb30454e
There can be one and only one thread handling a channel's media at a time.
Otherwise, we don't know which thread is going to handle the media frames.
ASTERISK-27625
Change-Id: Ia341f1a6f4d54f2022261abec9021fe5b2eb4905
The CHECK_BLOCKING() macro is used to indicate if a channel's handling
thread is about to do a blocking operation (poll, read, or write) of
media. A few operations such as ast_queue_frame(), soft hangup, and
masquerades use the indication to wake up the blocked thread to reevaluate
what is going on.
ASTERISK-27625
Change-Id: I4dfc33e01e60627d962efa29d0a4244cf151a84d
Executing dialplan functions from either AMI or ARI by getting a variable
could place the channel into autoservice. However, these user interface
threads do not handle the channel's media so we wind up with two threads
attempting to handle the media.
There can be one and only one thread handling a channel's media at a time.
Otherwise, we don't know which thread is going to handle the media frames.
ASTERISK-27625
Change-Id: If2dc94ce15ddabf923ed1e2a65ea0ef56e013e49
In Asterisk there are some dynamic codecs that have
a fixed payload number. This number was being improperly
used to negotiate the codec, instead of using the name
and sample rate. This could result in the wrong payload
number being negotiated for a codec.
This change makes it so that only static payloads
will be negotiated using their payload number.
ASTERISK-27848
Change-Id: Ia865830170fd3f808cdb33104f3d4c4ffdc77570
Before Asterisk sends an HTTP response (at least in the case of errors),
it attempts to read & discard the content of the request. If the client
lies about the Content-Length, or the connection is closed from the
client side before "Content-Length" bytes are sent, the request handling
thread will busy loop.
ASTERISK-27807
Change-Id: I945c5fc888ed92be625b8c35039fc6d2aa89c762
ast_indicate is invoked with the bridge locked. As ast_indicate locks the
other end of the bridge as well this can lead to a deadlock in some situations.
(Especially when a different thread does the same in the reverse order).
This patch calls ast_indicate after unlocking the bridge which fixes the
deadlock. Calling ast_indicate with these parameters without locking the
bridge should be safe as this is done at different places without a
bridge lock.
ASTERISK-27094 #close
Reported-by: David Brillert
Change-Id: I5f86c1e2ce75b9929a36ab589b18c450e62ea35f
There was no real reason to limit the conteny type to text/plain other
than that's what it was limited to before. Now any text/* content
type will be allowed for channel drivers that don't support enhanced
messaging and any type will be allowed for channel drivers that do
support enhanced messaging.
Change-Id: I94a90cfee98b4bc8e22aa5c0b6afb7b862f979d9
asterisk/tcptls.h was included (explicitly, implicitly, or transitively). Those
inclusions got replaced by forward declarations. As side effect, the inclusions
got completed.
ASTERISK-27878
Change-Id: I9d102728e30336d6522e5e4ae9e964013a0835f7
Additionally, this change allows auto-negotiation of the elliptic curve/group
for servers, not only with OpenSSL 1.0.2 but also with OpenSSL 1.1.0 and newer.
This enables X25519 (since OpenSSL 1.1.0) and X448 (since OpenSSL 1.1.1) as a
side-effect.
ASTERISK-27876
Change-Id: I62c2aba4a630aefc231b71f646207e8c027d9497
When RTP was originally created it had the ability to place a single
extension in an RTP packet. In practice people wanted to potentially
put multiple extensions in one and so RFC 5285 (obsoleted by RFC
8285) came into existence. This allows RTP extensions to be negotiated
with a unique identifier to be used in the RTP packet, allowing
multiple extensions to be present in the packet.
This change extends the RTP engine API to add support for this. A
user of it can enable extensions and the API provides the ability to
retrieve the information (to construct SDP for example) and to provide
negotiated information (from SDP). The end result is that the RTP
engine can then query to see if the extension has been negotiated and
what unique identifier is to be used. It is then up to the RTP engine
implementation to construct the packet appropriately.
The first extension to use this support is abs-send-time which is
defined in the REMB draft[1] and is a second timestamp placed in an
RTP packet which is for when the packet has left the sending system.
It is used to more accurately determine the available bandwidth.
ASTERISK-27831
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
Change-Id: I508deac557867b1e27fc7339be890c8018171588
__ast_channel_alloc_ap() had a failure exit path that hadn't setup the fd
descriptors to -1 yet. The destructor would then attempt to close these
fd's that had never been opened.
Change-Id: Icf21093f36c60781e8cf6ee9d586536302af33e3
The config engine destroy_func callback function returns the number of
rows deleted or -1 on error. But the function
ast_destroy_realtime_fields treated non-zero return values as error.
ASTERISK-27863
Change-Id: Ied02b38e8196cb03043e609a0679feebd288d17b
This function originally was used in chan_sip to enable some simplifying
assumptions and eventually was copy and pasted into res_pjsip_logger and
res_hep. Since it's replicated in three places, it's probably best to
move it into the public netsock2 API for these modules to use.
Change-Id: Id52e23be885601c51d70259f62de1a5e59d38d04
Mantis-3709 (Commit 68ff3c3, Asterisk 1.2) added support for the video format
H.263+. For this, the RTP payload ID 103 got assigned statically. Commit f1aadc8
assigned another payload ID 98 for this format in Asterisk 1.6.
Change-Id: I90e35b158487f8f1f8187da6241b54cd3b74e667
This fixes build warnings found by GCC 8. In some cases format
truncation is intentional so the warning is just suppressed.
ASTERISK-27824 #close
Change-Id: I724f146cbddba8b86619d4c4a9931ee877995c84
George Joseph
Joshua Colp
Matthew Fredrickson
Richard Mudgett
Alexander Traud
Jenkins2
Sean Bright
Pirmin Walthert
Alexei Gradinari
Kevin Harwell
Corey Farrell