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
SendText now accepts new channel variables that can be used
to override the To and From display names and set the Content-Type
of a message. Since you can now set Content-Type, other text/*
content types are now valid.
Change-Id: I648b4574478119f95de09d9f08e9595831b02830
Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge. res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.
res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame. On a normal
point-to-point call, the frames are forwarded between the two
correctly. bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants. Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.
* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload. A channel
driver can queue a frame of that type when it receives a message
from outside. A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties. If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this. Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.
* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel. This allows the chat client user to set a friendly name
for the chat.
* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).
* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.
* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.
* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.
Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489
(cherry picked from commit be7d4faed5)
Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge. res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.
res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame. On a normal
point-to-point call, the frames are forwarded between the two
correctly. bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants. Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.
* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload. A channel
driver can queue a frame of that type when it receives a message
from outside. A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties. If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this. Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.
* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel. This allows the chat client user to set a friendly name
for the chat.
* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).
* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.
* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.
* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.
Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489
(cherry picked from commit be7d4faed5)
Asterisk uses Reference Counting to track whether a module can be unloaded.
Every consumer who requires a module, increases the reference count. When the
consumer goes, is unloaded itself, it has to decrease the reference count on
all its used/required modules. That way
core stop gracefully
works on the command-line interface (CLI): One module after the other is
unloaded. A recent change broke this for the module res_pjsip.
ASTERISK-27861
Change-Id: I261abcb411d026bbb0691cc78f28300bfd3103a3
The module (res_)pjsip_transport_management got moved into res_pjsip. It is no
longer an independent/external module with (un)load_module and therefore has to
register just internally with res_pjsip.
ASTERISK-27860
Change-Id: Icd0413be7d2e98b92f51e6d6c353f2570bb4be95
A new branch was created for what will be Asterisk certified 13.21. A couple
of things needed to be done to the branch in order to complete initialization:
Modified the version file to reflect the certified version.
Updated all extended modules to be disabled by default.
Change-Id: Ie1dd3cb146391dea92c9e3ef906dde8d7241fee2
Similar to pjproject's PJ_ASSERT_RETURN macro, this one will do the
following...
If the assert passes... NoOp
If the assert fails and AST_DEVMODE is defined, execute ast_assert()
then, if DO_CRASH isn't set, return from the calling function with
the supplied value.
If the assert fails and AST_DEVMODE is not defined, return from the
calling function with the supplied value.
The macro will execute a return without a value if one isn't suppled.
Change-Id: I0003844affeab550d5ff5bca7aa7cf8a559b873e
This reverts a problem introduced by the fix for ASTERISK_24329.
Now, when an announcement is played while waiting in a queue, music on
hold will not restart from the beginning of the sound file and will
instead pick up where it left off. However, the incorrect behavior in
ASTERISK_24329 is now present again; if an announcement X seconds
long is played when music on hold starts, music on hold will start X
seconds into the file.
ASTERISK-27774 #close
Reported by: lvl
Change-Id: I86b2885ee7063268f9b9747eddb788336ade989b
When a scheduled task is created you can pass in the
AST_SIP_SCHED_TASK_TRACK flag. This new flag causes scheduling events to
be logged.
Change-Id: I91967eb3d5a220915ce86881a28af772f9a7f56b
ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer. If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer. Reentrancy issues could result if the
task does not execute with the right serializer.
The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936). A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().
However, there are a few places where this unexpected behavior is still
required to avoid deadlocks. The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer. I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().
* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous(). ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in. Both functions
behave the same if the current thread is not a SIP servant.
* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.
ASTERISK_26806
Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3
* Fix the periodic interval wander because it may take significant time
between the sched thread queueing the task in the serializer and the
serializer actually executing the task. The time it takes to actually
execute the task was already taken into account.
* Pass a schtd ref to the serializer when we queue a scheduled task on
the serializer. We don't want it going away on us while it is in the
serializer queue.
* Skip the scheduled task if the task was canceled between queueing the
task to the serializer and the serializer actually executing the task.
* Reorder struct ast_sip_sched_task to avoid unnecessary padding. Removed
task_id and added next_periodic.
* Hold a ref to the passed in serializer so the serializer cannot go away
on the scheduled task.
ASTERISK_26806
Change-Id: I6c8046b75f6953792c8c30e55b836a4291143f24
* A side benefit is that the scheduled tasks are not completely blocked
while the CLI command executes.
* Adjusted the "Task Name" column width to have more room for longer
names.
Change-Id: Iec64aa463ee8b10eef90120e00c38b1fb444087e
If it is not defined, it will add MYSQL_PORT definition. After some
research on MySQL/MariaDB development tree, I couldn't find any reference
to MYSQL_PORT definition in include files.
ASTERISK-27782 #close
Change-Id: Ieee56c836fc2e8bd021c456145bba04c6068bb77
It now appends the external IP address on the
o= line of the SDP packet. The decision was made to write
the numeric IP address as opposed to the RFC that states
the FQDN should be used if and when available. We believe
the usage of literal IP address will help avoid
potential problems.
ASTERISK-27614 #close
Change-Id: I84f3360f3606b8c4e8d161edb228799ec0b8a302
This patch adds support to send in-dialog SIP NOTIFY commands on
chan_pjsip channels, similar to the functionality recently added
for chan_sip (ASTERISK_27461).
This extends res_pjsip_notify to allow for in-dialog messages.
ASTERISK-27697
Change-Id: If7f3151a6d633e414d5dc319d5efc1443c43dd29
* Removed several invalid uses of OBJ_NOLOCK. These uses resulted in the
'tasks' container being accessed without a lock in a multi-threaded
environment. A recipe for crashes.
* Removed needlessly obtaining schtd object references. If the caller
providing you a pointer to an object doesn't have a valid reference then
you cannot safely get one from it.
* Getting a ref to 'tasks' when you aren't copying the pointer into
another location is useless. The 'tasks' container pointer is global.
* Removed many unnecessary uses of RAII_VAR.
* Make ast_sip_schedule_task() name parameter const.
ASTERISK_26806
Change-Id: I5c62488e651314e2a1dbc01f5b078a15512d73db
* Consistently use spaces in rest-api-templates/asterisk_processor.py.
* Exclude third-party from docs/full-en_US.xml.
* Add docs/full-en_US.xml to .gitignore.
* Use list() to convert python3 view.
* Use python3 print function.
* Replace cmp() with equivalent equation.
* Replace reference to out of scope subtype variable with name
parameter.
* Use unescaping triple bracket notation in mustache templates where
needed. This causes behavior of Python2 to be maintained when using
Python3.
* Fix references to has_websocket / is_websocket in
res_ari_resource.c.mustache.
* Update calculation of has_websocket to use any().
* Use unicode mode for writing output file in transform.py.
* Replace 'from swagger_model import *' with explicit import of required
symbols.
* Add missing 'import os'
* Fix invalid reference to swagger_version from exception handler.
I have not tested voicemailpwcheck.py, only the print syntax has
been fixed.
Change-Id: If5c5b556a2800d41a3e2cfef080ac2e151178c33
There is a problem when an INVITE-with-Replaces transfer targets a channel
in a ConfBridge. The transfer will unconditionally swap out the
ConfBridge channel. Unfortunately, the ConfBridge state will not be aware
of this change. Unexpected behavior will happen as a result since
ConfBridge channels currently can only be replaced by a masquerade and not
normal bridge channel moves.
* We just need to pretend that the channel isn't in a bridge (like other
transfer methods already do) so the transfer channel will masquerade into
the ConfBridge channel.
Change-Id: I209beb0e748fa4f4b92a576f36afa8f495ba4c82
Given the below call scenario:
A -> Ast1 -> B
C <- Ast2 <- B
1) A calls B through Ast1
2) B calls C through Ast2
3) B transfers A to C
When party B transfers A to C, B sends a REFER to Ast1 causing Ast1 to
send an INVITE with replaces to Ast2. Ast2 then leaks a channel ref of
the channel between Ast1 and Ast2.
Channel ref leaks are easily seen in the CLI "core show channels" output.
The leaked channels appear in the output but you can do nothing with them
and they never go away unless you restart Asterisk.
* Properly account for the channel refs when imparting a channel into a
bridge when handling an INVITE with replaces in handle_invite_replaces().
The ast_bridge_impart() function steals a channel ref but the code didn't
account for how many refs were held by the code at the time and which ref
was stolen.
* Eliminated RAII_VAR in handle_invite_replaces().
ASTERISK-27740
Change-Id: I7edbed774314b55acf0067b2762bfe984ecaa9a4
Asterisk requires GNU C extensions. On some systems certain libraries
may incorrectly push -std=c99 into CFLAGS, thus breaking the build.
This change causes that flag to be stripped so the Asterisk build is not
broken by those libraries. This change is made for both pkgconfig and
tool based libraries.
ASTERISK-27629 #close
Change-Id: I13389613b194abbac77becf90cd950dc168704db
* Replace all 'else if' statements with 'elif'.
* Use loop to detect versioned lua headers and libraries.
The loop for detecting lua fixes a bug where LUA_INCLUDE would be
appended with the directory of every lua version after the first one is
found.
Change-Id: I3276f9aee955014108345be6092f51c932b43a0f
There have been cases that when the transaction timer callback is called
the tsx is already destroyed. This causes a crash. We now check the
tsx state and return if the tsx is already destroyed.
Change-Id: If93acd5e48d9ca5bb553f2405d5afc836842fe1c
Added a new pj_timer_entry_reset function that resets a timer_entry
for re-use.
Changed direct settings of timer_entry fields to use
pj_timer_entry_init and pj_timer_entry_reset.
Fixed issues where timers were being rescheduled incorrectly.
Change-Id: I5b624bfbc5c1429117484b9b24567293002148e6
