This makes it clear that the ARI API calls for listing channels and
bridges will list all channels or bridges in the system and not just
those that are in or are controlled by a Stasis application.
(closes issue ASTERISK-22635)
Reported by: Kevin Harwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@401087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds the list of expected errors to the /bridges/{bridgeId}/record
ARI documentation so that outbound 4xx errors validate properly.
Previously, this would result in a response validation failure.
(closes issue ASTERISK-22627)
Reported by: Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@401018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
........
Merged revisions 400970 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400971 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Because I added a wiki_description to models and not their properties, the
rendered wiki page had the model description instead of the property
descriptions, which looks very silly indeed.
(closes issue ASTERISK-22705)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the server didn't exist that we are trying to register to the log message
would say that a 408 was received from that server when in reality one wasn't.
Added log messages stating no response was received if the response does not
exist.
(closes issue ASTERISK-22554)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2893/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The INVITE session state callback wrongly assumes that a session will always exist, but
when rapidly terminating the session this assumption goes out the window. As all handler
code for the INVITE session state callback requires the session it will now just exit
immediately if no session exists.
(closes issue ASTERISK-22668)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When generating the list of authentication credentials to pass to
PJSIP, Asterisk was using the raw pointer of a pj_str_t which is not
always NULL-terminated. This sometimes resulted in incorrect text for
the realm and a failure to match the realm for authentication purposes
which was causing the outbound nominal auth pjsip basic call test to
bounce. This now uses the pj_str_t that contains the realm instead of
generating a new one. Thanks to John Bigelow for helping to narrow this
down.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The crash is caused by a race condition when switching between native RTP
and softmix bridging technologies. In this situation, the bridging
technology is switched from native RTP to softmix, and then back to native
RTP fast enough that the softmix private data gets destroyed before the
softmix mixing thread gets started.
Thanks to Kinsey Moore for the crash analysis.
* Fix race condition when starting the softmix mixing thread and switching
to another bridge technology.
(closes issue ASTERISK-22678)
Reported by: John Bigelow
Patches:
jira_asterisk_22678_v12.patch (license #5621) patch uploaded by rmudgett
Tested by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes two issues when setting an outbound proxy:
1. The outbound proxy URI was not parsed and validated during configuration.
2. If an outgoing dialog was created and the outbound proxy could not be set an assertion would
occur because the usage count on the dialog was not decremented.
The documentation has also been updated to specify that a full URI must be specified for
the outbound proxy.
(closes issue ASTERISK-22672)
Reported by: Antti Yrjola
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using 'lu' will produce a compiler warning for some versions of gcc and on some
architectures. 'z' should be portable as a format specifier for size_t.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support to the PJSIP stack in Asterisk for SIP header
manipulation. Note that this is analagous to SIPAddHeader/SIPRemoveHeader.
For PJSIP_HEADER, an incoming supplemental session callback is registered that
takes the pjsip_hdrs from the incoming session and stores them in a linked
list in the session datastore. Calls to PJSIP_HEADER traverse over the list
and return the nth matching header where 'n' is the 'number' argument to the
function.
When adding a header, the first call creates a datastore and linked list and
adds the datastore to the session. The header is then created as a pjsip_hdr
and added to the list. An outgoing supplemental session callback then
traverses the list and adds the headers to the outgoing pjsip_msg.
When removing a header, the list created with PJSIP_HEADER(add,...) is
traversed and all matching entries are removed.
(closes issue ASTERISK-22498)
Reported by: George Joseph
patch:
res_pjsip_header_funcs_v1.patch uploaded by george.joseph (License 6322)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When running configure, libiodbc2 development headers will fulfill the
requirement for ODBC development headers, but will not function
properly. This adds a warning when libiodbc2 development headers are
detected instead of unixodbc development headers.
(closes issue ASTERISK-22459)
Reported by: Patrick Maille
Tested by: Walter Doekes
Patches:
issueA22459_warn_when_using_iodbc.patch uploaded by Walter Doekes (License 5674)
........
Merged revisions 400767 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400768 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjsip_strerror is only aware of PJSIP-specific error
codes. pj_strerror() is aware of all PJProject error
codes and OS-specific error codes.
This specifically fixes an oft-seen error in transport
configuration code where EADDRINUSE would result in
"Unknown PJSIP error 120098" instead of a useful
message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ConfBridge now has the ability to set the language of announcements to the
conference. The language can be set on a bridge profile in
confbridge.conf or by the dialplan function
CONFBRIDGE(bridge,language)=en.
(closes issue ASTERISK-19983)
Reported by: Jonathan White
Patches:
M19983_rev2.diff (license #5138) patch uploaded by junky (modified)
Tested by: rmudgett
........
Merged revisions 400741 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AST_CONFIG dialplan function defined in func_config.c allocates its
config file list entries using ast_malloc. List entry allocations
destined for use with Asterisk's linked list API must be ast_calloc()d
or otherwise initialized so that list pointers are set to NULL. These
uses of ast_malloc have been replaced by ast_calloc to prevent
dereferencing of uninitialized pointer values when traversing the list.
(closes issue ASTERISK-22483)
Reported by: Brian Scott
........
Merged revisions 400694 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400697 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ensure that when chan_sip binds to the IPv6 any address ([::]), IPv4
candidates are also added.
(closes issue ASTERISK-21917)
Reported by: Torrey Searle
Patches:
0023_ipv6_stun_crash.patch uploaded by Torrey Searle (License 5334)
........
Merged revisions 400681 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you run Asterisk in the background and then connect to
it through a separate console, the thread that runs CLI commands
is not registered with PJLIB. Thus PJLIB does not like it when
you attempt to send OPTIONS requests from that thread. So now
we push the task into the threadpool, which we know to be registered
with PJLIB.
Thanks to Antti Yrjola for reporting this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The https://reviewboard.asterisk.org/r/2888/ review changes manager to not
subscribe to stasis when it is disabled for performance reasons. When
manager is disabled app_queue and res_agi decline to load and fail to
clean up what they have already allocated.
* Made app_queue and res_agi clean up allocated resources when they
decline to load.
* Made app_queue and res_agi use their own subscriptions to the stasis
topics instead of borrowing manager's message router structure
inappropriately.
(closes issue ASTERISK-22604)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/2902/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Commit r62462 added two extra fields for logging "the original position the
caller entered the queue at, and the amount of time the caller was waiting in
the queue." But when r75969 was merged from 1.4 into trunk (r75977), these two
fields disappeared. Those two extra fields were not logged in 1.4 and when the
patch was merged, those fields went away.
Therefore, this is a regression and was caught by the reporter because he was
reading the awesome "Asterisk: The Definitive Guide" book.
(closes issue ASTERISK-22197)
Reported by: Dalius M.
Tested by: Dalius M.
Patches:
asterisk-22197-q-log-exitwithkey.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2901/
........
Merged revisions 400622 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400623 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes the res_pjsip_logger do a few things... First, it
will be built and installed by default now, so end users won't need
to enable it in menuselect. Second, while it is loaded, it no longer
will immediately issue log messages. Upon loading, it is in the
disabled state and must be turned on with the new CLI command. The
CLI command 'pjsip set logger <on/off/host> has been added and can be
used to do the following:
pjsip set logger on:
Enables logger for all PJSIP traffic
pjsip set logger off:
Disables logger for all PJSIP traffic
pjsip set logger host <host>:
Enables logger for the specific host
Review: https://reviewboard.asterisk.org/r/2900/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds an /applications API to ARI, allowing explicit management of
Stasis applications.
* GET /applications - list current applications
* GET /applications/{applicationName} - get details of a specific application
* POST /applications/{applicationName}/subscription - explicitly subscribe to
a channel, bridge or endpoint
* DELETE /applications/{applicationName}/subscription - explicitly unsubscribe
from a channel, bridge or endpoint
Subscriptions work by a reference counting mechanism: if you subscript to an
event source X number of times, you must unsubscribe X number of times to stop
receiveing events for that event source.
Review: https://reviewboard.asterisk.org/r/2862
(issue ASTERISK-22451)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes said publication for a few reasons:
(1) It is unnecessary. Association of the channel technology with a specific
channel is an implementation detail that should be assumed to "just happen",
and consumers of Stasis don't need to be informed about it.
(2) Publication of said message can now cause crashes, as the actual creation
of a channel in normal locations now stages its messages. As a result, things
that create dummy channels (such as the SIP RTP QOS unit test) and associate
them with a channel technology were now crashing, as the channel itself was
not known by Stasis.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r337595, additional security events were added for chan_sip
authentication failures. The new IEs added to the existing invalid
password event were defined as required IEs, but existing users of the
event did not set the new IEs and could not since they didn't apply to
existing uses. They are now marked as optional IEs.
(closes issue ASTERISK-22578)
Reported by: Matt Jordan
........
Merged revisions 400421 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400440 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a party leaves a bridge, there may be more participants in the bridge than expected.
As such, it is important not to make assumptions regarding the list of channels in a
bridge.
This change makes it so that when a party leaves a native RTP bridge, we unbridge it and
the party it was bridged with. Previously, the first and last channels in the list were
unbridged since it was assumed that these were the two channels that had been bridged. As
previously stated, a new party had been inserted into the bridge, so this logic did not
work properly.
(closes issue ASTERISK-22615)
reported by Matt Jordan
(closes issue ASTERISK-22532)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2899
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
