This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new operation for stored recordings, copy. It takes an
existing stored recording and makes a copy of it in the same directory
or a relative directory under the stored recording directory.
/ari/recordings/stored/{recordingName}/copy?destinationRecordingName={copy_name}
This is particularly useful for voicemail-esque applications, which may need to
copy or move recordings around a directory structure.
Review: https://reviewboard.asterisk.org/r/3768/
ASTERISK-24036 #close
Reported by: Sam Galarneau
Tested by: Sam Galarneau
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most channel drivers let you specify a default accountcode to be set on
channels associated with a particular peer/endpoint/object. Prior to this
patch, chan_pjsip/res_pjsip did not support such a setting.
This patch adds a new setting to the res_pjsip endpoint object, 'accountcode'.
When a channel is created that is associated with an endpoint with this value
set, the channel will automatically have its accountcode property set to the
value configured for the endpoint.
Review: https://reviewboard.asterisk.org/r/3724/
ASTERISK-24000 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.
* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.
* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.
* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.
AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3720/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two bugs:
1. When originating a channel into a Stasis application, we already create a
subscription for the channel that is going into our Stasis app.
Unfortunately, when you create a Local channel and pass it off to a Stasis
app, you really aren't creating just one channel: you're creating two. This
patch snags the second half of the Local channel pair (assuming it is a
Local channel pair, but luckily core_local is kind about such assumptions)
and subscribes to it as well.
2. Subscriptions are a bit sticky right now. If a subscription is made, the
'interest' count gets bumped on the Stasis subscription - but unless
something explicitly unsubscribes the channel, said subscription sticks
around. This is not much of a problem is a user is creating the subscription
- if they made it, they must want it. However, when we are creating
implicit subscriptions, we need to make sure something clears them out.
This patch takes a pessimistic approach: it watches the cache updates
coming from Stasis and, if we notice that the cache just cleared out an
object, we delete our subscription object. This keeps our ao2 container of
Stasis forwards in an application from growing out of hand; it also is a
bit more forgiving for end users who may not realize they were supposed to
unsubscribe from that channel that just hung up.
Review: https://reviewboard.asterisk.org/r/3710/
ASTERISK-23939 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.
* Add http.conf session_keep_alive option to enable persistent
connections.
* Parse and discard optional chunked body extension information and
trailing request headers.
* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k. The previous
1k was kind of small.
* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function. manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()
* Add missing va_end() in ast_ari_response_error().
* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().
ASTERISK-23552 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of various PJSIP AMI actions were failing to parse out and place the
ActionID into their responses. This patch updates the various PJSIP actions
such that the passed in ActionID is emitted on any event list complete events,
as well as any intermediate events created as a result of the action.
ASTERISK-23947 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3675/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This macro replaces one object reference with another cleaning up the original.
param dst Pointer to the object that will be cleaned up.
param src Pointer to the object replacing it.
src's ref count is bumped if it's non-NULL.
dst's ref count is decremented if it's non-NULL.
src is assigned to dst,
This patch was reviewed on IRC by coreyfarrell and mjordan.
Tested by: George Joseph
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@416995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_ext_tool_check.m4 isn't handling cases where a path to a package is
provided (E.G. --with-mysqlclient=/some/sysroot) and the package has a config
tool (E.G. mysql_config) and the package has its own subdirectories in include
or lib. For example, mysql's libraries are in ${MYSQLCLIENT_DIR}/usr/lib/mysql
but ast_ext_tool_check sets MYSQLCLIENT_LIB to ${MYSQLCLIENT_DIR}/usr/lib.
libxml2 has the same problem with its includes. They're in
${LIBXML2_DIR}/usr/include/libxml2 not directly in ${LIBXML2_DIR}/usr/include.
Both cause configure to fail and there are others in the same boat.
The problem is caused by logic in ast_ext_tool_check that overrides the result
of the config tool's --cflags and --libs options if package_DIR is set.
This patch prepends package_DIR (if specified) to the -L and -I results from
the package's config tool instead of overriding them.
A regenerated ./configure and include/asterisk/autoconfig.h.in are included
but can be regenerated by running ./bootstrap.sh at any time.
Tested by: George Joseph
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3550/
........
Merged revisions 416929 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 416930 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@416931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added ast_sockaddr_cidr_bits() to count the 1 bits in an ast_sockaddr.
* Added ast_ha_join_cidr() which uses ast_sockaddr_cidr_bits() for the netmask
instead of ast_sockaddr_stringify_addr.
* Changed res_pjsip_endpoint_identifier_ip to call ast_ha_join_cidr() instead
of ast_ha_join() for the CLI output.
This is a CLI change only. AMI was not affected.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@416737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@416211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@415896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes res_pjsip_pubsub persist inbound subscriptions in sorcery. By default
this uses the local astdb but it can also be configured to store within an outside
database. When Asterisk is started these subscriptions are recreated if they have not
expired. Notifications are sent to the devices which have subscribed and they are none
the wiser that the system has restarted.
Review: https://reviewboard.asterisk.org/r/3598/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@415766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a re-do of r414122.
When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures
This patch is nearly identical with the one proposed in r414122, save for the
following changes:
- We explicitly clear the UNBRIDGE flag when setting an after goto on a
channel in a bridge
- Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it
https://reviewboard.asterisk.org/r/3585/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@415443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new channel function TALK_DETECT that, when set on a
channel, causes events indicating the start/stop of talking on a channel to be
emitted to both AMI and ARI clients.
The function allows setting both the silence threshold (the length of silence
after which we decide no one is talking) as well as the talking threshold (the
amount of energy that counts as talking). Parameters can be updated on a channel
after talk detection has been enabled, and talk detection can be removed at
any time.
The events raised by the function use a nomenclature similar to existing AMI/ARI
events.
For AMI: ChannelTalkingStart/ChannelTalkingStop
For ARI: ChannelTalkingStarted/ChannelTalkingFinished
Review: https://reviewboard.asterisk.org/r/3563/
ASTERISK-23786 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the semantic versioning of ARI to 1.3.0 and AMI to 2.3.0 to account for
backwards compatible changes going from 12.2.0 to 12.3.0.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply enabling PJSIP to negotiage a video codec (e.g., h264) would leak
video RTP ports if the codec were not negotiated by an incoming call.
* Made add_sdp_streams() associate the handler with the media stream if
the handler handled the media stream. Otherwise, when the
ast_sip_session_media object was destroyed it didn't know how to clean up
the RTP resources.
* Fixed sdp_requires_deferral() associating the handler with the media
stream when deciding if the SDP processing needs to be deferred for T.38.
Like the leaked video RTP ports, the T.38 handler needs to clean up
allocated resources from deciding if SDP processing needs to be deffered.
* Cleaned up some dead code in handle_incoming_sdp() and
sdp_requires_deferral().
ASTERISK-23721 #close
Reported by: cervajs
Review: https://reviewboard.asterisk.org/r/3571/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
User events can now be generated from ARI. Events can be signalled with
arbitrary json variables, and include one or more of channel, bridge, or
endpoint snapshots. An application must be specified which will receive
the event message (other applications can subscribe to it). The message
will also be delivered via AMI provided a channel is attached. Dialplan
generated user event messages are still transmitted via the channel, and
will only be received by a stasis application they are attached to or if
the channel is subscribed to.
This change also introduces the multi object blob mechanism used to send
multiple snapshot types in a single message. The dialplan app UserEvent
was also changed to use multi object blob, and a new stasis message type
created to handle them.
ASTERISK-22697 #close
Review: https://reviewboard.asterisk.org/r/3494/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes res_corosync such that it works with Asterisk 12. This
restores the functionality that was present in previous versions of
Asterisk, and ensures compatibility with those versions by restoring the
binary message format needed to pass information from/to them.
The following changes were made in the core to support this:
* The event system has been partially restored. All event definition and
event types in this patch were pulled from Asterisk 11. Previously, we had
hoped that this information would live in res_corosync; however, the
approach in this patch seems to be better for a few reasons:
(1) Theoretically, ast_events can be used by any module as a binary
representation of a Stasis message. Given the structure of an ast_event
object, that information has to live in the core to be used universally.
For example, defining the payload of a device state ast_event in
res_corosync could result in an incompatible device state representation
in another module.
(2) Much of this representation already lived in the core, and was not
easily extensible.
(3) The code already existed. :-)
* Stasis message types now have a message formatter that converts their
payload to an ast_event object.
* Stasis message forwarders now handle forwarding to themselves. Previously
this would result in an infinite recursive call. Now, this simply creates a
new forwarding object with no forwards set up (as it is the thing it is
forwarding to). This is advantageous for res_corosync, as returning NULL
would also imply an unrecoverable error. Returning a subscription in this
case allows for easier handling of message types that are published directly
to an aggregate topic that has forwarders.
Review: https://reviewboard.asterisk.org/r/3486/
ASTERISK-22912 #close
ASTERISK-22372 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.
The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
enter a bridge together, the framehook remains on the transfer target
channel until both channels are in the bridge. As it consumes voice frames,
the initial bridge type is a simple bridge. The framehook is removed when
both channels are in the bridge; however, this does not currently cause the
bridging framework to re-evaluate the bridge. This patch adds a
AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
framehook is removed so the bridge can re-evaluate itself.
(2) When a channel leaves a native RTP bridge, it may be leaving due to being
hung up. Sending a re-INVITE to a channel that is about to be hung up is
not nice - in fact, there's a good chance we'll send the BYE request before
the channel has had a chance to send back a 200 OK. To be somewhat nicer,
this patch adds a function to channel.h that allows the bridging framework
to query for exactly why a channel is leaving a bridge via the channel's
soft hangup flags. This allows it to only send the re-INVITE if there's a
chance the channel will survive the native bridging experience.
Review: https://reviewboard.asterisk.org/r/3535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@414122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When overlap dialing is enabled, the lack of inband audio available
information in the SETUP_ACKNOWLEDGE events causes an interoperability
problem with SIP. sig_pri doesn't know if there is dialtone present when
a SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an
AST_CONTROL_PROGRESS frame. The SIP channel driver then sends out a 183
Session Progress and blocks the desired 180 Ringing message when the
ALERTING message comes in.
* Made the configure script detect if the installed version of libpri
supports the SETUP_ACKNOWLEDGE enhancements.
* Using the new API, made generate an AST_CONTROL_PROGRESS frame on an
incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio
is present instead of assuming that dialtone is present.
* Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio
available indication only if dialtone is expected. The change also makes
the fallback behaviour of sending the PROGRESS message better by sending
it only if dialtone is expected.
* Changed receiving a PROCEEDING message to not generate an
AST_CONTROL_PROGRESS frame if the progress indication ie indicates
non-end-to-end-ISDN. This helps interoperability with SIP.
* Changed sending a PROCEEDING message in response to an
AST_CONTROL_PROCEEDING frame to not indicate inband audio available. It
was silly to do so anyway because the channel driver doesn't know if
inband audio is even available. This helps interoperability with SIP.
This patch and a corresponding change in libpri work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.
AST-1338 #close
Reported by: Tyler Stewart
Review: https://reviewboard.asterisk.org/r/3521/
........
Merged revisions 413714 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 413765 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413650 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed early exit in sip_msg_send() not destroying the message iterator.
* Made ast_msg_var_iterator_next() and ast_msg_var_iterator_destroy()
tolerant of a NULL iter parameter in case ast_msg_var_iterator_init()
fails.
* Made ast_msg_var_iterator_destroy() clean up any current message data
ref.
* Made struct ast_msg_var_iterator, ast_msg_var_iterator_init(),
ast_msg_var_iterator_next(), ast_msg_var_unref_current(), and
ast_msg_var_iterator_destroy() use iter instead of i.
* Eliminated RAII_VAR usage in res_pjsip_messaging.c:vars_to_headers().
........
Merged revisions 413139 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original commit for spinlock was missing "destroy" implementations.
Most of them are no-ops but phtread_spin and pthread_mutex do need their
locks destroyed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are cases in Asterisk where it might be desirable to lock
a short critical code section but not incur the context switch
and yield penalty of a mutex or rwlock. The primary spinlock
implementations execute exclusively in userspace and therefore
don't incur those penalties. Spinlocks are NOT meant to be a
general replacement for mutexes. They should be used only for
protecting short blocks of critical code such as simple compares
and assignments. Operations that may block, hold a lock, or
cause the thread to give up it's timeslice should NEVER be
attempted in a spinlock.
The first use case for spinlocks is in astobj2 - internal_ao2_ref.
Currently the manipulation of the reference counter is done with
an ast_atomic_fetchadd_int which works fine. When weak reference
containers are introduced however, there's an additional comparison
and assignment that'll need to be done while the lock is held.
A mutex would be way too expensive here, hence the spinlock.
Given that lock contention in this situation would be infrequent,
the overhead of the spinlock is only a few more machine instructions
than the current ast_atomic_fetchadd_int call.
ASTERISK-23553 #close
Review: https://reviewboard.asterisk.org/r/3405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously multiple play actions against a bridge at one time would cause
the sounds to play simultaneously on the bridge. Now if a sound is already
playing, the play action will queue playback to occur after the completion
of other sounds currently on the queue.
(closes issue ASTERISK-22677)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Restore the reason value set by pbx_outgoing_attempt() to use
AST_CONTROL_xxx values as all the consumers were expecting rather than
cause codes.
* Fixed the dial routines to set cause codes for more than just
ast_request() so pbx_outgoing_attempt() reason codes will function.
* Fix inconsistent locked_channel return status in pbx_outgoing_attempt().
The chanel may not have been locked or the channel may have been a stale
pointer.
* Fixed the OutgoingSpoolFailed channel to run dialplan whenever the
dialing fails for an originate exten and 1 < synchronous.
* Fix incorrect ast_cond_wait() usage in pbx_outgoing_attempt().
Indroduced by issue ASTERISK-22212 patch.
* Made struct pbx_outgoing use the ao2 lock instead of its own lock for
the cond wait mutex. No sense in having two locks associated with the
same struct when only one is needed.
Review: https://reviewboard.asterisk.org/r/3421/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).
(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The failing assertion ensures that the final snapshot gets generated so
CDR records can get finalized. The only place where a channel staging
snapshot flag could be left set is in chan_sip.c:handle_request_bye().
The function could return before clearing the flag because the channel
could dissappear while the function had to have the channel unlocked.
* Fixed handle_request_bye() channel snapshot staging coverage area to not
have a return in the middle of it and be unable to clear the staging flag.
* Pushed the channel snapshot staging coverage area into
ast_rtp_instance_set_stats_vars() to ensure that the staging is not
interrutped.
* Made callers of ast_rtp_instance_set_stats_vars() not call it with any
channels or channel driver private locks held to eliminate the deadlock
potential. The callers must hold references to the passed in channel and
rtp objects.
* Eliminated sip_hangup() trying to get the bridge peer. It is futile at
this point because the channel could never be in a bridge.
Review: https://reviewboard.asterisk.org/r/3431/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While the vast majority of bridge snapshot creation is locked properly,
there are currently some instances that are not. This adds the missing
locking to ensure bridge state is not malleable during snapshot
creation.
(closes issue ASTERISK-22904)
Review: https://reviewboard.asterisk.org/r/3415/
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
Every run will now blow away the previous run (as large ref files
sometimes caused issues). We now also no longer open/close the file
on each write, instead relying on fflush to make sure data gets written
to the file (in case the ao2 call being performed is about to cause a
crash)
(3) It goes with a comma delineated format for the ref debug file. This
makes parsing much easier. This also now includes the thread ID of the
thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
contrib/scripts folder.
Review: https://reviewboard.asterisk.org/r/3377/
........
Merged revisions 412114 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412115 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
