Introduce a ChannelTransfer event and the ability to notify progress to
ARI. Implement emitting this event from the PJSIP channel instead of
handling the transfer in Asterisk when configured.
Introduce a dialplan function to the PJSIP channel to switch between the
"core" and "ari-only" behavior.
UserNote: Call transfers on the PJSIP channel can now be controlled by
ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only)
dialplan function.
Certain channel options are not set anywhere or
exposed in any way to users, making them unusable.
This exposes some of these options which make sense
for users to manipulate at runtime.
Resolves: #442
T.140 data in RTP is not zero terminated, so when we are queuing a text
frame on a bridge we need to ensure that we are passing a zero
terminated string.
ASTERISK-28974 #close
Change-Id: Ic10057387ce30b2094613ea67e3ae8c5c431dda3
Allow passing a topology from the called channel back to the
calling channel.
* Added a new function ast_queue_answer() that accepts a stream
topology and queues an ANSWER CONTROL frame with it as the
data. This allows the called channel to indicate its resolved
topology.
* Added a new virtual function to the channel tech structure
answer_with_stream_topology() that allows the calling channel
to receive the called channel's topology. Added
ast_raw_answer_with_stream_topology() that invokes that virtual
function.
* Modified app_dial.c and features.c to grab the topology from the
ANSWER frame queued by the answering channel and send it to
the calling channel with ast_raw_answer_with_stream_topology().
* Modified frame.c to automatically cleanup the reference
to the topology on ANSWER frames.
Added a few debugging messages to stream.c.
Change-Id: I0115d2ed68d6bae0f87e85abcf16c771bdaf992c
* ast_frame_subclass2str() and ast_frame_type2str() now return
a pointer to the buffer that was passed in instead of void.
This makes it easier to use these functions inline in
printf-style debugging statements.
* Added many missing control frame entries in
ast_frame_subclass2str.
Change-Id: Ifd0d6578e758cd644c96d17a5383ff2128c572fc
This patch allows a user of AMI to now specify the type of message
content contained within by setting the 'Content-Type' parameter.
Note, the AMI version has been bumped for this change.
ASTERISK-28945 #close
Change-Id: Ibb5315702532c6b954e1498beddc8855fabdf4bb
* Pass caller information to frame allocation functions.
* Disable caching as it interfers with MALLOC_DEBUG reporting.
* Stop using ast_calloc_cache.
Change-Id: Id343cd80a3db941d2daefde2a060750fea8cd260
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
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
This change extends the existing AST_FRAME_RTCP frame type to be
able to contain additional RTCP message types, such as feedback
messages. The payload type is contained in the subclass which allows
knowing what is in the frame itself.
The RTCP feedback message type is now handled and REMB[1] messages
are raised with their containing information.
This also fixes a bug where all feedback messages were triggering
video updates instead of just FIR and FUR.
Finally RTCP frames are now passed up through the Asterisk core to
what is handling the channel, mapped appropriately in the case of
bridging, and written to an outgoing stream. Since RTCP frames are
on a per-stream basis this is only done on multistream capable
channels.
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
ASTERISK-27758
ASTERISK-26366
Change-Id: I680da0ad8d5059d5e9655d896fb9d92e9da8491e
Some endpoints do not like a stream being reused for a new
media stream. The frame/jitterbuffer can rely on underlying
attributes of the media stream in order to order the packets.
When a new stream takes its place without any notice the
buffer can get confused and the media ends up getting dropped.
This change uses the SSRC change to determine that a new source
is reusing an existing stream and then bridge_softmix renegotiates
each participant such that they see a new media stream. This
causes the frame/jitterbuffer to start fresh and work as expected.
ASTERISK-27277
Change-Id: I30ccbdba16ca073d7f31e0e59ab778c153afae07
This change does a few things to improve packet loss and renegotiation:
1. On outgoing RTP streams we will now properly reflect out of order
packets and packet loss in the sequence number. This allows the
remote jitterbuffer to better reorder things.
2. Video updates can now be discarded for a period of time
after one has been sent to prevent flooding of clients.
3. For declined and removed streams we will now release any
media session resources associated with them. This was not
previously done and caused an issue where old state was being
used for a new stream.
4. RTP bundling was not actually removing bundled RTP instances
from the parent. This has been resolved by removing based on
the RTP instance itself and not the SSRC.
5. The code did not properly handle explicitly unbundling an
RTP instance from its parent. This now works as expected.
ASTERISK-27143
Change-Id: Ibd91362f0e4990b6129638e712bc8adf0899fd45
This change adds a few things to facilitate stream topology changing:
1. Control frame types have been added for use by the channel driver
to notify the application that the channel wants to change the stream
topology or that a stream topology change has been accepted. They are
also used by the indicate interface to the channel that the application
uses to indicate it wants to do the same.
2. Legacy behavior has been adopted in ast_read() such that if a
channel requests a stream topology change it is denied automatically
and the current stream topology is preserved if the application is
not capable of handling streams.
Tests have also been written which confirm the multistream and
non-multistream behavior.
ASTERISK-26839
Change-Id: Ia68ef22bca8e8457265ca4f0f9de600cbcc10bc9
This change introduces an ast_read_stream function and callback in
the channel technology which allows reading frames from all streams
and not just the default streams.
The stream number has also been added to frames. This is to allow the
case where frames are queued onto the channel instead of being read
directly from the driver.
This change does impose a restriction on reading though: a chain of
frames can only contain frames from the same stream.
ASTERISK-26816
Change-Id: I5d7dc35e86694df91fd025126f6cfe0453aa38ce
This change adds experimental support for providing RTCP
feedback information to codec modules so they can dynamically
change themselves based on conditions.
ASTERISK-26584
Change-Id: Ifd6aa77fb4a7ff546c6025900fc2baf332c31857
It was possible for a frame to be re-inserted into a jitter buffer after it
had been removed from it. A case when this happened was if a frame was read
out of the jitterbuffer, passed to the translation core, and then multiple
frames were returned from said translation core. Upon multiple frames being
returned the first is passed on, but sebsequently "chained" frames are put
back into the read queue. Thus it was possible for a frame to go back into
the jitter buffer where this would cause problems.
This patch adds a flag to frames that are inserted into the channel's read
queue after translation. The abstract jitter buffer code then checks for this
flag and ignores any frames marked as such.
Change-Id: I276c44edc9dcff61e606242f71274265c7779587
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
........
Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
........
Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an endpoint fails to include the T38MaxBitRate attribute during negotiation,
Asterisk will negotiate a bit rate of 2400 instead of the ITU recommended
bit rate of 14400. This patch fixes this by making AST_T38_RATE_14400 the
'default' value of the enum by assigning it a value of 0, such that if an
endpoint fails to include the attribute, the default will be 14400.
Note that Walter Doekes included the nice comment in frame.h about why we are
purposefully assigning AST_T38_RATE_14400 a value of 0.
(closes issue ASTERISK-22275)
Reported by: Andreas Steinmetz
patches:
fax-fix.patch uploaded by anstein (License 6523)
........
Merged revisions 397256 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397257 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch implements the controls from ARI recordings. The controls
are:
* DELETE /recordings/live/{recordingName} - stop recording and
discard it
* POST /recordings/live/{recordingName}/stop - stop recording
* POST /recordings/live/{recordingName}/pause - pause recording
* POST /recordings/live/{recordingName}/unpause - resume recording
* POST /recordings/live/{recordingName}/mute - mute recording (record
silence to the file)
* POST /recordings/live/{recordingName}/unmute - unmute recording.
Since this underlying functionality did not already exist, is was
added to app.c by a set of control frames, similar to how playback
control works. The pause/mute control frames are toggles, even though
the ARI controls are idempotent, to be consistent with the playback
control frames.
(closes issue ASTERISK-22181)
Review: https://reviewboard.asterisk.org/r/2697/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the API that binds the Stasis dialplan application to external
Stasis applications. It also adds the beginnings of WebSocket
application support.
This module registers a dialplan function named Stasis, which is used
to put a channel into the named Stasis app. As a channel enters and
leaves the Stasis diaplan application, the Stasis app receives a
'stasis-start' and 'stasis-end' events.
Stasis apps register themselves using the stasis_app_register and
stasis_app_unregister functions. Messages are sent to an application
using stasis_app_send.
Finally, Stasis apps control channels through the use of the
stasis_app_control object, and the family of stasis_app_control_*
functions.
Other changes along for the ride are:
* An ast_frame_dtor function that's RAII_VAR safe
* Some common JSON encoders for name/number, timeval, and
context/extension/priority
Review: https://reviewboard.asterisk.org/r/2361/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the capability for asynchronous manipulation of audio being
played back to a channel though a new AMI action "ControlPlayback". The
ControlPlayback action supports a number of operations, the availability of
which depend on the application being used to send audio to the channel.
When the audio playback was initiated using the ControlPlayback application
or CONTROL STREAM FILE AGI command, the audio can be paused, stopped,
restarted, reversed, or skipped forward. When initiated by other mechanisms
(such as the Playback application), the audio can be stopped, reversed, or
skipped forward.
Review: https://reviewboard.asterisk.org/r/2265/
(closes issue ASTERISK-20882)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HANGUPCAUSE hash (trunk only) meant to replace SIP_CAUSE has now
been replaced with the HANGUPCAUSE and HANGUPCAUSE_KEYS dialplan
functions to better facilitate access to the AST_CAUSE translations
for technology-specific cause codes. The HangupCauseClear application
has also been added to remove this data from the channel.
(closes issue SWP-4738)
Review: https://reviewboard.asterisk.org/r/2025/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continuing with the Who Hung Up? project for Asterisk 11, this adds
support to IAX2 for the HANGUPCAUSE hash.
Additionally, this breaks out some functionality in frame.c for getting
information about frame types and subclasses.
Review: https://reviewboard.asterisk.org/r/1941/
(issue SWP-4222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r336307 | jrose | 2011-09-16 16:09:20 -0500 (Fri, 16 Sep 2011) | 20 lines
Merged revisions 336294 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r336294 | jrose | 2011-09-16 14:53:40 -0500 (Fri, 16 Sep 2011) | 13 lines
Fix bad RTP media bridges in directmedia calls on peers separated by multiple Asterisk nodes.
In a situation involving devices on separate Asterisk trunks, the remote RTP bridge would
break when starting a call with directmedia. This patch queues a new type of control frame
so that our RTP bridge loop can properly detect when these situations occur and check to see
if peers need to be updated in order to send their media to the proper location.
(Closes issue ASTERISK-18340)
Reported by: Thomas Arimont
(Closes issue ASTERISK-17725)
Reported by: kwk
Tested by: twilson, jrose
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines
Merged revisions 335064 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines
Updated SIP 484 handling; added Incomplete control frame
When a SIP phone uses the dial application and receives a 484 Address
Incomplete response, if overlapped dialing is enabled for SIP, then
the 484 Address Incomplete is forwarded back to the SIP phone and the
HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete
application dialplan logic was automatically triggered; now, explicit
dialplan usage of the application is required.
Additionally, this patch adds a new AST_CONTOL_FRAME type called
AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame,
it is an indication that the dialplan expects more digits back from the
device. If the device supports overlap dialing it should attempt to
notify the device that the dialplan is waiting for more digits; otherwise,
it can handle the frame in a manner appropriate to the channel driver.
(closes issue ASTERISK-17288)
Reported by: Mikael Carlsson
Tested by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/1416/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue #16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue #18171)
Reported by: SantaFox
(closes issue #18185)
Reported by: kwemheuer
(closes issue #18211)
Reported by: zahir_koradia
(closes issue #18230)
Reported by: vmarrone
(closes issue #18299)
Reported by: mbrevda
(closes issue #18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a new manager command to mute/unmute MixMonitor audio on a channel.
Added a new feature to audiohooks so that you can mute either read / write
(or both) types of frames - this allows for MixMonitor to mute either side
of the conversation without affecting the conversation itself.
(closes issue #16740)
Reported by: jmls
Review: https://reviewboard.asterisk.org/r/487/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
