Kevin Harwell [Mon, 6 Apr 2015 19:23:57 +0000 (19:23 +0000)]
res_pjsip: config option 'timers' can't be set to 'no'
When setting the configuration option 'timers' equal to 'no' the bit flag was
not properly negated. This patch clears all associated flags and only sets the
specified one. pjsip will handle any necessary flag combinations. Also went
ahead and did similar for the '100rel' option.
ASTERISK-24910 #close
Reported by: Ray Crumrine
Review: https://reviewboard.asterisk.org/r/4582/
........
Merged revisions 434131 from http://svn.asterisk.org/svn/asterisk/branches/13
Jonathan Rose [Tue, 12 May 2015 22:45:09 +0000 (17:45 -0500)]
app_voicemail: fix moving when old messages full
When completing voicemail playback of a message in the 'INBOX', the
message gets moved to the 'Old' messages folder. Without this patch, if
the 'Old' folder is already at its set limit, then the 'INBOX' message will
simply be deleted. With this patch, the flag to delete the message will be
removed if the save_to_folder function indicates that the message could
not be moved due to a full folder.
ASTERISK-25082 #close
Reported by: Jonathan Rose
Review: https://gerrit.asterisk.org/#/c/448/
Richard Mudgett [Tue, 12 May 2015 22:34:45 +0000 (17:34 -0500)]
chan_dahdi/sig_pri: Fix crash on ISDN call hangup collision.
If an ISDN call is hungup by both sides at the same time a crash could
happen.
* Added missing NULL checks for the owner channel after calling
pri_queue_pvt_cause_data() in two places. Code after those calls need to
check the owner channel pointer for NULL before use because
pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the
owner and the owner may get hung up.
ASTERISK-21893 #close
Reported by: Alexandr Gordeev
Kevin Harwell [Thu, 16 Apr 2015 15:51:50 +0000 (10:51 -0500)]
bridge.c: NULL app causes crash during attended transfer
Due to a race condition there was a chance that during an attended transfer the
channel's application would return NULL. This, of course, would cause a crash
when attempting to access the memory. This patch retrieves the channel's app
at an earlier time in processing in hopes that the app name is available.
However, if it is not then "unknown" is used instead. Since some string value
is now always present the crash can no longer occur.
Joshua Colp [Wed, 6 May 2015 18:24:29 +0000 (15:24 -0300)]
res_pjsip_exten_state: Fix race condition between sending NOTIFY and termination
The res_pjsip_exten_state module currently has a race condition between
processing the extension state callback from the PBX core and processing
the subscription shutdown callback from res_pjsip_pubsub. There is currently
no synchronization between the two. This can present a problem as while
the SIP subscription will remain valid the tree it points to may not.
This is in particular a problem as a task to send a NOTIFY may get queued
which will try to use the tree that may no longer be valid.
This change does the following to fix this problem:
1. All access to the subscription tree is done within the task that
sends the NOTIFY to ensure that no other thread is modifying or
destroying the tree. This task executes on the serializer for the
subscriptions.
2. A reference to the subscription serializer is kept to ensure it
remains valid for the lifetime of the extension state subscription.
3. The NOTIFY task has been changed so it will no longer attempt
to send a NOTIFY if the subscription has already been terminated.
Joshua Colp [Mon, 19 Jan 2015 13:18:32 +0000 (13:18 +0000)]
res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions.
The first thing this patch fixes is UAS dialogs. Previously if a transport was
configured on an endpoint and an inbound session was created there was no guarantee
that requests sent on the dialog would use the correct transport and address
information. This has now been fixed so an explicitly configured transport
is taken into account.
The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed
module attempts to determine what transport a message should go out on and what
addressing information should go into the message itself. In a scenario where
multiple transports exist bound to the same IP address but a different port the
code would incorrectly alter the transport and change the message to the wrong
transport. This change makes the res_pjsip_multihomed module smarter so it will
only change the transport and address information in the message when it is
possible and makes sense.
Joshua Colp [Mon, 4 May 2015 17:16:24 +0000 (14:16 -0300)]
stasis: Fix dial masquerade datastore lifetime
A recent change went into Asterisk which added reference counts to the
channels stored in a dial masquerade datastore. Unfortunately this
included a reference to the caller in a dialing operation. While all
of the dialed targets have the datastore removed from them upon dialing
completion this did not occur for the caller, causing it to have a
reference to itself that could go never go away (as it depended on
the destruction of the datastore which only happened when the channel
was destroyed). This resulted in the caller channel remaining on the
system despite it having hung up.
This change does the following to fix this issue:
1. The dial masquerade datastore is now removed from the caller upon
dialing completion, just like the dialed targets.
2. Upon destruction of the caller all the dialed targets are also
removed from the dial masquerade datastore (just in case).
3. The reference to the caller has been removed as it should not be
possible for the datastore to now be valid/useful after the lifetime
of the caller has ended.
Richard Mudgett [Wed, 29 Apr 2015 19:29:10 +0000 (14:29 -0500)]
chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option.
Some telco switches occasionally ignore ISDN RESTART requests. The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request. If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco. The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.
chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code. Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards. I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.
* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.
ASTERISK-25034 #close
Reported by: Richard Mudgett
Mark Michelson [Thu, 30 Apr 2015 20:20:43 +0000 (15:20 -0500)]
Prevent potential crash on blond transfer.
Scenario:
Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects
the incoming call (or some other immediate circumstance causes Carol not
to answer the call)
What occurs in this case is that when the bridge between Alice and Bob
breaks, Alice is told to masquerade into Bob's channel that had placed
the call to Carol. The actual masquerade goes down without a hitch.
However, a channel fixup callback that attempts to publish dial events
over Stasis has a crash. The reason for this crash is that the datastore
on Bob's channel that placed the outbound call to Carol only had a bare
pointer to Carol's channel. Since Carol rejected the incoming call,
Carol's channel has been hung up and freed, meaning accessing her
channel results in a crash.
The fix here is simple. The dial fixup code has been altered to hold
references to the involved channels and to drop those references when
freeing data.
The Asterisk 13 version of the fix for outbound registration was missing
a key component that set the outbound authenticator's callback that
creates an authenticated request based on an old request. This was
picked up by some outbound registration tests failing in the testsuite.
res_pjsip_outbound_registration: Fix double unref on error return.
When the PJSIP pjsip_regc_send function is invoked and an error
status returned the caller currently decrements the reference count
of the client state that it just incremented, assuming the
registration callback would not have been invoked. In practice
this is not correct. If the failure happens after the transaction
has been set up the callback will still be invoked. This will
cause the reference count to be incorrectly decremented twice, once
by the registration callback and second by the caller of
pjsip_regc_send.
This change makes it so that whether the callback is invoked or
not is known by the caller of pjsip_regc_send. Depending on
this it can know whether it is responsible for decrementing the
reference count of the client state or not.
Mark Michelson [Mon, 27 Apr 2015 21:56:31 +0000 (16:56 -0500)]
res_pjsip_outbound_registration: Don't fail on delayed processing: 13.
This is the Asterisk 13 version of a change to master that allows for
registration responses to be processed successfully potentially after
the original transaction has timed out. The main difference between this
and the master change is that the master version has API changes that
are unacceptable for 13. For 13, this is worked around by adding a new
API call that the outbound registration code uses instead.
The following is the text from the master version of this commit:
Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.
Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.
To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now also hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.
When problems occur regarding outbound registrations, it currently
is difficult to debug. Most off-nominal paths had warning messages,
but sometimes we want to know what's going on before hitting the
off-nominal path. This patch adds lots of debugging output that
should give a clearer picture of what is happening with regards
to outbound registrations.
Matthew Jordan [Sat, 11 Apr 2015 15:10:34 +0000 (15:10 +0000)]
res/res_pjsip_t38: Add missing initialization of t38faxmaxdatagram
Prior to this patch, the far_max_datagram value on the UDPTL structure would
remain -1 if the remote endpoint fails to provide the SDP media attribute
T38FaxMaxDatagram. This can result in the INVITE request being rejected. With
this patch, we will now properly initialize the value with either the default
value or with the value provided by pjsip.conf's t38_udptl_maxdatagram
parameter.
Mark Michelson [Thu, 23 Apr 2015 17:54:30 +0000 (12:54 -0500)]
res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX.
When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.
However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.
This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.
This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.
Mark Michelson [Wed, 15 Apr 2015 15:38:02 +0000 (10:38 -0500)]
Detect potential forwarding loops based on count.
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
Matt Jordan [Mon, 13 Apr 2015 14:54:18 +0000 (09:54 -0500)]
build_tools/make_version: Update version parsing for Git migration
External systems - such as the Asterisk Test Suite - require knowledge of the
upstream branch. Unfortunately, after moving to Git, the Asterisk version
currently consists of only a 'GIT" prefix followed by an object blob,
e.g., GIT-as08d7. This makes it difficult for such systems to know what
features are available in a particular check out of Asterisk.
This patch fixes this by hardcoding the branch in a variable in the
make_version script. Since the mainline branches are not changed often -
typically only once a year - this is a reasonable approach to solving
the problem, and is more reliable than parsing the output of 'git branch
-vv'. Branches that track off of an upstream primary branch will then get the
benefit of knowing which mainline branch they are currently based off
of.
Matt Jordan [Sun, 12 Apr 2015 17:59:22 +0000 (12:59 -0500)]
git migration: Remove support for file versions
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file.
As a result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Alter the "core show file version" CLI command such that it always
reports the version of Asterisk. The file version is no longer
available.
* main/manager: The Version key now always reports the Asterisk version.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action.
- Modification of the "core show file version" CLI command.
Matt Jordan [Sun, 12 Apr 2015 04:22:59 +0000 (23:22 -0500)]
.gitignore: Ignore tarballs (*.gz)
This patch updates the root .gitignore file to ignore files with a .gz
extension. This will cause git to ignore downloaded sound tarballs in
the the sounds/ directory.
res_pjsip_mwi: Send unsolicited MWI NOTIFY on startup and when endpoint registers.
Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon
a mailbox state change (such as a new message being left, or one being deleted).
In practice this is not sufficient to keep clients aware of the current MWI status.
This change makes the module send unsolicited MWI NOTIFY on startup so that
clients are guaranteed to have the most up to date MWI information. It also makes
clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware
of the current MWI status they receive it.
Jonathan Rose [Wed, 8 Apr 2015 18:19:26 +0000 (18:19 +0000)]
res_pjsip_t38: Fix FAX failures when using PJSIP with authentication
Without this patch, if a PJSIP endpoint with udptl enabled and authentication
set attempted to use sendFax, the FAX session would fail during setup. This
was because the invite issued in response to being auth challenged would cause
the PJSIP channel performing the FAX to receive a second T38 framehook and
this would cause frames to be consumed in an inappropriate manner.
ASTERISK-24933 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4577/
........
Merged revisions 434425 from http://svn.asterisk.org/svn/asterisk/branches/13
Jonathan Rose [Wed, 8 Apr 2015 17:24:23 +0000 (17:24 +0000)]
Security/tcptls: MitM Attack potential from certificate with NULL byte in CN.
When registering to a SIP server with TLS, Asterisk will accept CA signed
certificates with a common name that was signed for a domain other than the
one requested if it contains a null character in the common name portion of
the cert. This patch fixes that by checking that the common name length
matches the the length of the content we actually read from the common name
segment. Some certificate authorities automatically sign CA requests when
the requesting CN isn't already taken, so an attacker could potentially
register a CN with something like www.google.com\x00www.secretlyevil.net
and have their certificate signed and Asterisk would accept that certificate
as though it had been for www.google.com - this is a security fix and is
noted in AST-2015-003.
ASTERISK-24847 #close
Reported by: Maciej Szmigiero
Patches:
asterisk-null-in-cn.patch submitted by mhej (license 6085)
........
Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434384 from http://svn.asterisk.org/svn/asterisk/branches/13
Outbound SIP MESSAGEs had the potential to be sent out
of order from how they were specified in a set of
dialplan steps.
This change creates a serializer for sending outbound
MESSAGE requests on. This ensures that the MESSAGEs are
sent by Asterisk in the same order that they were sent
from the dialplan.
Mark Michelson [Wed, 1 Apr 2015 20:32:52 +0000 (20:32 +0000)]
core: avoid possible asterisk -r crash from long id
When connecting to the remote console, an id string
is first provided that consts of the hostname, pid,
and version. This is parsed by the remote instance
using a buffer that may be too short, and can allow
a buffer overrun because it is not terminated. This
patch adds termination and a larger buffer.
Review: https://reviewboard.asterisk.org/r/4182/
AFS-254
........
Merged revisions 429223 from http://svn.asterisk.org/svn/asterisk/branches/13
Ashley Sanders [Tue, 31 Mar 2015 22:34:48 +0000 (22:34 +0000)]
stasis: set a channel variable on websocket disconnect error
When an error occurs while writing to a web socket, the web socket is
disconnected and the event is logged. A side-effect of this, however, is that
any application on the other side waiting for a response from Stasis is left
hanging indefinitely (as there is no mechanism presently available for
notifying interested parties about web socket error states in Stasis).
To remedy this scenario, this patch introduces a new channel variable:
STASISSTATUS.
The possible values for STASISSTATUS are:
SUCCESS - The channel has exited Stasis without any failures
FAILED - Something caused Stasis to croak. Some (not all) possible
reasons for this:
- The app registry is not instantiated;
- The app requested is not registered;
- The app requested is not active;
- Stasis couldn't send a start message
ASTERISK-24802
Reported By: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/4519/
........
Merged revisions 433839 from http://svn.asterisk.org/svn/asterisk/branches/13
Mark Michelson [Fri, 27 Mar 2015 20:55:41 +0000 (20:55 +0000)]
Add stateful PJSIP response API call, and use it for out-of-dialog responses.
Asterisk had an issue where retransmissions of MESSAGE requests resulted in
Asterisk processing the retransmission as if it were a new MESSAGE request.
This patch fixes the issue by creating a transaction in PJSIP on the incoming
request. This way, if a retransmission arrives, the PJSIP transaction layer
will resend the response and Asterisk will not ever see the retransmission.
Richard Mudgett [Fri, 20 Mar 2015 19:57:58 +0000 (19:57 +0000)]
Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks.
Valgrind found some memory leaks associated with
ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending
responses to OPTIONS requests, processing MESSAGE requests, and
res_pjsip supplements implementing the incoming_request callback.
* Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in
res/res_pjsip.c:supplement_on_rx_request(),
res/res_pjsip/pjsip_options.c:send_options_response(),
res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and
res/res_pjsip_messaging.c:send_response().
* Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in
res/res_pjsip_nat.c:nat_on_rx_message().
* Fixed inconsistent but benign return value in
res/res_pjsip/pjsip_options.c:options_on_rx_request().
Richard Mudgett [Tue, 17 Mar 2015 21:56:23 +0000 (21:56 +0000)]
Audit ast_sockaddr_resolve() usage for memory leaks.
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Kevin Harwell [Tue, 17 Mar 2015 18:44:48 +0000 (18:44 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
Updated some documentation stating that endpoint identifiers registered without
a name are place at the front of the lookup list. Also renamed register method
'ast_sip_register_endpoint_identifier_by_name' to
'ast_sip_register_endpoint_identifier_with_name'
ASTERISK-24840
Reported by: Mark Michelson
........
Merged revisions 433031 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Tue, 17 Mar 2015 18:43:03 +0000 (18:43 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
This patch fixes previously reverted code that caused binary incompatibility
problems with some modules. And like the original patch it makes sure that
no matter what order the endpoint identifier modules were loaded, priority is
given based on the ones specified in the new global 'endpoint_identifier_order'
option.
ASTERISK-24840
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4489/
........
Merged revisions 433028 from http://svn.asterisk.org/svn/asterisk/branches/13
In this collection of small patches to prevent
Valgrind errors are: fixes for reference leaks
in config hooks, evaluating a parameter beyond
bounds, and accessing a structure after a lock
where it could have been already free'd.
Review: https://reviewboard.asterisk.org/r/4407/
........
r433005 | rmudgett | 2015-03-17 11:10:39 -0500 (Tue, 17 Mar 2015) | 1 line
res_pjsip: Add reason comment.
........
Merged revisions 431583,433005 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Mon, 9 Mar 2015 16:44:31 +0000 (16:44 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
It's possible to have a scenario that will create a conflict between endpoint
identifiers. For instance an incoming call could be identified by two different
endpoint identifiers and the one chosen depended upon which identifier module
loaded first. This of course causes problems when, for example, the incoming
call is expected to be identified by username, but instead is identified by ip.
This patch adds a new 'global' option to res_pjsip called
'endpoint_identifier_order'. It is a comma separated list of endpoint
identifier names that specifies the order by which identifiers are processed
and checked.
ASTERISK-24840 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4455/
........
Merged revisions 432638 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 4 Mar 2015 18:53:40 +0000 (18:53 +0000)]
translate: Prevent invalid memory accesses on fast shutdown
When a 'core restart now' or 'core stop now' is executed and a channel is
currently in a media operation, the translator matrix can be destroyed while a
channel is currently blocked on getting the best translation choice
(see ast_translator_best_choice). When the channel gets the mutex, the
translation matrix now has invalid memory, and Asterisk crashes.
This patch does two things:
(1) We now only clean up the translation matrix on a graceful shutdown. In that
case, there are no channels, and so there is no risk of this occurring.
(2) We also now set the __matrix and __indextable to NULL. In some initial
backtraces when this occurred, it looked as if there was a memory corruption
occurring, and it wasn't until we determined that something had restarted
Asterisk that the issue became clear. By setting these to NULL on shutdown,
it becomes a bit easier to determine why a crash is occurring.
Note that we could litter the code with NULL checks on the __matrix, but the
act of making the translation matrix cleaned up on shutdown should preclude
this issue from occurring in the first place, and this part of the code needs
to be as fast as possible.
Matthew Jordan [Mon, 2 Mar 2015 19:15:40 +0000 (19:15 +0000)]
res/res_pjsip_sdp_rtp: Revert portion of r432195
Unfortunately, while initial testing with ConfBridge did not reproduce the
audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing
did show that bridge_softmix and/or ConfBridge has a severe problem bridging
two or more participants at different sampling rates. Sometimes, it even picks
odd sampling rates that cause hideous audio problems.
This patch backs out the offending portion of the code until the issues in
the affected bridging modules can be more properly analyzed.
ASTERISK-24841
........
Merged revisions 432423 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Tue, 24 Feb 2015 22:01:09 +0000 (22:01 +0000)]
ARI/PJSIP: Apply requesting channel's format cap to created channels
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Wed, 11 Feb 2015 18:04:09 +0000 (18:04 +0000)]
res_pjsip: dtls_handler causes Asterisk to crash
There have been a couple of times where a crash occurred in the dtls_handler
section of the code for res_pjsip. Unfortunately, in working this issue the
problem was unable to be reproduced. After looking at the backtraces and
through the code the current best guess as to why this happened might be due
to a reentrance problem and the strtok function. So, the current fix is to
convert the strtok function into the reentrant version of the function,
strtok_r.
Kevin Harwell [Wed, 11 Feb 2015 17:52:35 +0000 (17:52 +0000)]
res_http_websocket: websocket write timeout fails to fully disconnect
When writing to a websocket if a timeout occurred the underlying socket did not
get closed/disconnected. This patch makes sure the websocket gets disconnected
on a write timeout. Also a notice is logged stating that the websocket was
disconnected.
ASTERISK-24701 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4412/
........
Merged revisions 431669 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431670 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Wed, 11 Feb 2015 17:48:10 +0000 (17:48 +0000)]
HTTP: Stop accepting requests on final system shutdown.
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
Kevin Harwell [Wed, 11 Feb 2015 16:19:35 +0000 (16:19 +0000)]
pjsip_options: Fix continued qualifies after endpoint/aor deletion
If you remove an endpoint/aor from pjsip.conf then do a core reload,
qualifies will continue even though the object are gone. This happens
because nothing clears out the qualify tasks.
This patch unschedules all existing qualify tasks before scheduling
new ones on reload.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4290/
........
Merged revisions 430064 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Fri, 30 Jan 2015 17:53:54 +0000 (17:53 +0000)]
app_agent_pool: Fix initial module load agent device state reporting.
When the app_agent_pool module initially loads there is a race condition
between the thread loading agents.conf and the device state internal
processing thread. If the device state internal processing thread handles
the agent creation state updates before the thread that loaded agents.conf
registers the device state provider callback then the cached agent state
is "Invalid". When a consumer module like app_queue asks for the agent state
it gets the cached "Invalid" state instead of the real state from the provider.
* Moved loading the agents.conf configuration to the last thing setup by
app_agent_pool in load_module(). Now the device state provider callback
is registered before the config is loaded so the agent creation state
updates are guaranteed to get the initial device state.
* Removed some now redundant config cleanup on error in load_config().
* Added lock protection when accessing the device state in
agent_pvt_devstate_get() and eliminated the RAII_VAR() usage.
Manager: Fix Manager Action ModuleLoad to give correct response when reloading
Prior to this patch, ModuleLoad would respond with an error indicating that
the requested module wasn't found in spite of finding and reloading the
module.
Mitigate possible HTTP injection attacks using CURL() function in Asterisk.
CVE-2014-8150 disclosed a vulnerability in libcURL where HTTP request injection
can be performed given properly-crafted URLs.
Since Asterisk makes use of libcURL, and it is possible that users of Asterisk may
get cURL URLs from user input or remote sources, we have made a patch to Asterisk
to prevent such HTTP injection attacks from originating from Asterisk.
Mark Michelson [Wed, 28 Jan 2015 21:30:40 +0000 (21:30 +0000)]
Fix file descriptor leak in RTP code.
SIP requests that offered codecs incompatible with configured values
could result in the allocation of RTP and RTCP ports that would not get
reclaimed later.
ASTERISK-24666 #close
Reported by Y Ateya
Review: https://reviewboard.asterisk.org/r/4323
AST-2015-001
........
Merged revisions 431300 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 431303 from http://svn.asterisk.org/svn/asterisk/branches/13
Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.
What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module. A similar race condition happens between a reload and the CLI/AMI
show registrations commands. The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.
* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.
* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().
* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process. The struct
ast_sorcery_observer callbacks are pushed to a different thread.
* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().
* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.
* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.
Kevin Harwell [Tue, 27 Jan 2015 23:02:42 +0000 (23:02 +0000)]
tcptls: Bad file descriptor error when reloading chan_sip
While running through some scenarios using chan_sip and tcp a problem would
occur that resulted in a flood of bad file descriptor messages on the cli:
tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor
The message is received because the underlying socket has been closed, so is
valid. This is probably happening because unloading of chan_sip is not atomic.
That however is outside the scope of this patch. This patch simply stops the
logging of multiple occurrences of that message.
ASTERISK-24728 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4380/
........
Merged revisions 431218 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431219 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Tue, 27 Jan 2015 19:25:15 +0000 (19:25 +0000)]
chan_sip: stale nonce causes failure
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
........
Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Tue, 27 Jan 2015 17:52:09 +0000 (17:52 +0000)]
app_confbridge: Repeatedly starting and stopping recording ref leaks the recording channel.
Starting and stopping conference recording more than once causes the
recording channels to be leaked. For v13 the channels also show up in the
CLI "core show channels" output.
* Reworked and simplified the recording channel code to use
ast_bridge_impart() instead of managing the recording thread in the
ConfBridge code. The recording channel's ref handling easily falls into
place and other off nominal code paths get handled better as a result.
Joshua Colp [Tue, 27 Jan 2015 17:35:36 +0000 (17:35 +0000)]
bridge / res_pjsip_sdp_rtp: Fix issues with media not being reinvited during direct media.
This change fixes two issues:
1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.
2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.
Matthew Jordan [Tue, 27 Jan 2015 17:18:46 +0000 (17:18 +0000)]
app_confbridge: Restore user's menu name to CLI output of 'confbridge list'
When issuing a 'confbridge list XXXX' CLI command, the resulting output no
longer displays the menu associated with a ConfBridge participant.
The issue was caused by ASTERISK-22760. When that patch was done, it removed
the copying of the menu name associated with the user from the actual user
profile.
This patch fixes the issue by copying the menu name over to the user profile
when the menu hooks are applied to the user. Since that function now does a
little bit more than just apply the hooks, the name of the function has been
changed to cover the copying of the menu name over as well.
In addition, there is a disparity between the menu name length as it is stored
on the conf_menu structure and the confbridge_user structure; this patch makes
the lengths match so that a strcpy can be used.
Review: https://reviewboard.asterisk.org/r/4372/
ASTERISK-24723 #close
Reported by: Steve Pitts
........
Merged revisions 431134 from http://svn.asterisk.org/svn/asterisk/branches/13
Joshua Colp [Tue, 27 Jan 2015 11:48:31 +0000 (11:48 +0000)]
res_parking: Fix crash due to race condition when unloading.
There is currently a race condition when unloading the res_parking
module. Depending on the will of the universe the subscription
invocation may occur AFTER the module is unloaded. This is because
the module does NOT use stasis_unsubscribe_and_join when terminating
the subscription. It merely uses stasis_unsubscribe.
This change makes it use stasis_unsubscribe_and_join which is documented
for usage in this exact scenario.
outbound_registration: Add 'pjsip send register' and update 'send unregister'
The current behavior of 'pjsip send unregister' is to send the unregister
(REGISTER with 0 exp) but let the next scheduled register proceed normally.
I don't think that's a good idea. If you unregister, it should stay
unregistered until you decide to start registrations again. So this patch
just adds a cancel_registration call to the current unregister_task to
cancel the timer.
Of course, now you need a way to start registration again so I've added
a 'pjsip send register' command that unregisters and cancels any existing
registration (the same as send unregister), then sends an immediate
registration and starts the timer back up again.
Both changes also ripple to AMI. There's a new PJSIPRegister command.
There's no harm in calling either command repeatedly. They don't care
about the actual state.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4301/
........
r430373 | gtjoseph | 2015-01-08 11:48:29 -0600 (Thu, 08 Jan 2015) | 25 lines
res_pjsip_outbound_registration: Fix several reload issues
There are 2 issues with reloading registrations...
1. The 'can_reuse_registration' test wasn't considering the intervals or
expiration in its determination of whether a registration changed or not so if
you changed any of the intervals or the expiration and reloaded, the object
would get reloaded but the actual timers wouldn't change.
can_reuse_registration now does a sorcery diff on the old and new objects
instead of discretely testing certain fields. Now if you change expiration for
instance, and reload, the timer is updated and re-registration will occur on the
new value.
2. If you mung up your password on an outbound registration you get a permanent
failure. If you fix the password (on the outbound_auth object) and reload,
nothing tells outbound_registration to try again because the registration itself
didn't change. This patch adds an observer on the "auth" object type and if any
auth changes, existing registration states are searched and those in a
REJECTED_PERMANENT state are retried.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4304/
........
r430395 | gtjoseph | 2015-01-08 15:37:42 -0600 (Thu, 08 Jan 2015) | 14 lines
Every time a registration started, sip_outbound_registration_response_cb bumps
the ref count on client_state then pushes a handle_registration_response task.
handle_registration_response never unreffed it though. So every time a
registration goes out, the ref count goes up by one.
This patch adds the unreffs to handle_registration_response.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4303/
........
Merged revisions 430223,430373,430395 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 21 Jan 2015 13:36:31 +0000 (13:36 +0000)]
channels/chan_sip: Fix registration leak during reload
When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.
Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.
Review: https://reviewboard.asterisk.org/r/4355/
ASTERISK-24640 #close
Reported by: Max Man
ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........
Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 21 Jan 2015 13:11:48 +0000 (13:11 +0000)]
apps/app_dial: Don't publish DialEnd twice on unexpected GoSub/Macro values
The Dial application has some interesting options with the mid-call Macro (M)
and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific
values, the Dial application will take some action upon the channels involved
in the dial operation (such as hanging up a particular party, etc.) The Dial
application ensures that a Stasis message is published in the event that
MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so
that there is a corresponding DialEnd event published in AMI/ARI for the
DialBegin event that preceeded it.
A bug exists where that same DialEnd event will be published on Stasis even if
the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial
application cares about. This causes two DialEnd events to be published - one
with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all
sorts of wrong.
This patch fixes the bug by ensuring that we only publish a DialEnd message to
Stasis if the Dial application's mid-call Macro/GoSub returns something that
Dial cares about.
Review: https://reviewboard.asterisk.org/r/4336
ASTERISK-24682 #close
Reported by: Matt Jordan
........
Merged revisions 430842 from http://svn.asterisk.org/svn/asterisk/branches/13
Mark Michelson [Mon, 19 Jan 2015 18:18:23 +0000 (18:18 +0000)]
Call extension state callbacks at hint creation.
When a hint gets created, any subsequent device or presence
state changes result in extension status events getting sent
out to interested parties. However, at the time of hint creation,
no such event gets sent out, so watchers of extension state are
potentially left in the dark until the first state change after
hint creation.
Patch contributed by John Hardin (License #6512)
........
Merged revisions 430776 from http://svn.asterisk.org/svn/asterisk/branches/13
Joshua Colp [Thu, 15 Jan 2015 12:11:07 +0000 (12:11 +0000)]
res_pjsip_outbound_registration: Fix race condition when reloading and listing registrations.
Due to the split of outbound registration state from configuration it is possible during
a reload for a "pjsip show registrations" CLI command to be executed which gets an older
snapshot of the configuration. This configuration may include outbound registrations which
have been removed due to a reload operation occurring at the same time. The code for
printing the outbound registration did not take this into account but now it does.
Matthew Jordan [Tue, 6 Jan 2015 22:46:26 +0000 (22:46 +0000)]
contrib/ast-db-manage: Correct down_revision path for user_eq_phone
When the user_eq_phone patch was backported to 13, it referenced the downward
revision that the PJSIP optimistic encryption option also references. This
creates a multi-path upgrade Exception when generating the SQL files.
This patch corrects this in the 13 branch. Note that trunk, which already
contained both of these features, is unaffected by this problem.
........
Merged revisions 430252 from http://svn.asterisk.org/svn/asterisk/branches/13
bridge: avoid leaking channel during blond transfer pt2
A blond transfer to a failed destination, when followed
by a recall attempt, lead to a leak of the reference to
the destination channel. In addition to correcting the
regression on the previous attempt (r429826) this fixes
the leak and two additional reference leaks on failures
of bridge_import.
Matthew Jordan [Wed, 24 Dec 2014 15:27:53 +0000 (15:27 +0000)]
res/res_agi: Make Verbose message for 'stream file' match other playbacks
The Verbose message displayed when a file is played back via 'stream file'
was formatted differently than other playbacks:
* It didn't include the channel name
* It didn't include the channel language
It does, however, include the playback offset as well as any escape digits.
That information was kept; however, this patch updates the formatting to more
closely match the Verbose messages displayed when a file is played back by
'control stream file', Playback, ControlPlayback, or any other file playback
operation.
........
Merged revisions 429519 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 24 Dec 2014 13:27:13 +0000 (13:27 +0000)]
res_pjsip_keepalive: Add runtime configurable keepalive module for connection-oriented transports.
Note that this is backport from trunk of r425825.
This change adds a module which is configurable using the keep_alive_interval setting in the
global section that will send a CRLF keep alive to all active connection-oriented transports at
the provided interval. This is useful because it can help keep connections open through NATs.
This functionality also exists within PJSIP but can not be controlled at runtime and requires
recompiling it.
Review: https://reviewboard.asterisk.org/r/4084/
ASTERISK-24644 #close
........
Merged revisions 430084 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 24 Dec 2014 13:26:21 +0000 (13:26 +0000)]
res_pjsip: Add 'user_eq_phone' option to add a 'user=phone' parameter when applicable.
Note that this is a backport of r425804 from trunk.
This change adds a configuration option which adds a 'user=phone' parameter if the user
portion of the request URI or the From URI is determined to be a number.
Review: https://reviewboard.asterisk.org/r/4073/
ASTERISK-24643 #close
........
Merged revisions 430083 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Mon, 22 Dec 2014 21:22:16 +0000 (21:22 +0000)]
DTMF atxfer: Setup recall channels as if the transferee initiated the call.
After the initial DTMF atxfer call attempt to the transfer target fails to
answer during a blonde transfer, the recall callback channels do not get
setup with information from the initial transferrer channel. As a result,
the recall callback to the transferrer does not have callid, channel
variables, datastores, accountcode, peeraccount, COLP, and CLID setup. A
similar situation happens with the recall callback to the transfer target
but it is less visible. The recall callback to the transfer target does
not have callid, channel variables, datastores, accountcode, peeraccount,
and COLP setup.
* Added missing information to the recall callback channels before
initiating the call. callid, channel variables, datastores, accountcode,
peeraccount, COLP, and CLID
* Set callid of the transferrer channel on the DTMF atxfer controller
thread attended_transfer_monitor_thread().
* Added missing channel unlocks and props unref to off nominal paths in
attended_transfer_properties_alloc().
ASTERISK-23841 #close
Reported by: Richard Mudgett
Richard Mudgett [Mon, 22 Dec 2014 20:50:17 +0000 (20:50 +0000)]
queue_log: Post QUEUESTART entry when Asterisk fully boots.
The QUEUESTART log entry has historically acted like a fully booted event
for the queue_log file. When the QUEUESTART entry was posted to the log
was broken by the change made by ASTERISK-15863.
* Made post the QUEUESTART queue_log entry when Asterisk fully boots.
This restores the intent of that log entry and happens after realtime has
had a chance to load.
Prevent possible race condition on dual redirect of channels in the same bridge.
The AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT flag was created to prevent bridges from
prematurely acting on orphaned channels in bridges. The problem with the AMI
redirect action was that it was setting this flag on channels based on the presence
of a PBX, not whether the channel was in a bridge. Whether a channel has a PBX
is irrelevant, so the condition has been altered to check if the channel is in a
bridge.
ari: Add support for specifying an originator channel when originating.
If an originator channel is specified when originating a channel the linked ID
of it will be applied to the newly originated outgoing channel. This allows
an association to be made between the two so it is known that the originator
has dialed the originated channel.
ARI/AMI: Include language in standard channel snapshot output
The channel "language" was already part of a channel snapshot, however is was
not sent out over AMI or ARI. This patch makes it so the channel "language" is
included in the appropriate AMI or ARI events.
ASTERISK-24553 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4245/
........
Merged revisions 429204 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429206 from http://svn.asterisk.org/svn/asterisk/branches/13
res_pjsip_session: Fix issue where a declined media stream in a re-INVITE would fail SDP negotiation.
In the past the SDP negotiation within res_pjsip_session was made more tolerant of
certain situations. The only case where SDP negotiation will fail is when a major
error occurs during negotiation. Receiving an already declined media stream is
not considered a major error.
When producing the local SDP the logic took this into account so on the initial INVITE
the declined media stream did not cause an SDP negotiation failure. Unfortunately
the logic for handling media streams with a handler did not mirror this logic and
considered an already declined media stream an error and thus failed the SDP
negotiation.
This change makes the logic between both situations match so only under major
errors will the SDP negotiation fail.
media: Fix crash when determining sample count of a frame during shutdown.
When shutting down Asterisk the codecs are cleaned up. As a result anything
attempting to get a codec based on ID or details will find that no codec
exists. This currently occurs when determining the sample count of a frame.
This code did not take this situation into account.
This change fixes this by getting the codec directly from the format and
eliminates the lookup. This is both faster and also provides a guarantee
that the codec will exist and will be valid.
Prevent potential infinite outbound authentication loops in registration.
Prior to this patch, Asterisk would always respond to 401 responses to
registration attempts by trying to provide a registration with authentication
credentials. Even if subsequent attempts were rejected with 401 responses,
Asterisk would continue this behavior. If authentication credentials were
incorrect, this could continue forever.
With this patch, we keep track of whether we have attempted authentication
on an outbound registration attempt. If we already have, we don not try
again until the next attempt. This prevents the infinite loop scenario.
res_pjsip_outbound_publish: stack overflow when using non-default sorcery wizard
When using a non-default sorcery wizard (in this instance realtime) for outbound
publishes Asterisk will crash after a stack overflow occurs due to the code
infinitely recursing. The fix entails removing the outbound publish state
dependency from the outbound publish sorcery object and instead keeping an in
memory container that can be used to lookup the state when needed.
ASTERISK-24514 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4178/
........
Merged revisions 429175 from http://svn.asterisk.org/svn/asterisk/branches/13
This allows use of the 'inactive' stream direction identifier to be
used for hold where 'sendonly' is normally used. Some Seimens phones
use 'inactive' and this change allows music on hold to operate
properly.
Review: https://reviewboard.asterisk.org/r/4252/
Reported by: Steve Pitts
........
Merged revisions 429432 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429433 from http://svn.asterisk.org/svn/asterisk/branches/13
res_pjsip_session: Delay sending BYE if a re-INVITE transaction is in progress.
Given the scenario where a PJSIP channel is in a native RTP bridge with direct
media and the channel is then hung up the code will currently re-INVITE the channel
back to Asterisk and send a BYE at the same time. Many SIP implementations dislike
this greatly.
This change makes it so that if a re-INVITE transaction is in progress the BYE
is queued to occur after the completion of the transaction (be it through normal
means or a timeout).
chan_pjsip: Race between channel answer and bridge setup when using direct media
When direct media is enabled and a pjsip channel is answered a race would occur
between the handling of the answer and bridge setup. Sometimes the media
negotiation would take place after the native bridge was setup. This resulted
in a NULL media address, which in turn resulted in Asterisk using its address
as the remote media address when sending a reinvite. This patch makes the
chan_pjsip answer handler synchronous thus alleviating the race condition (the
bridge won't start setting things up until after it returns).
ASTERISK-24563 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4257/
........
Merged revisions 429477 from http://svn.asterisk.org/svn/asterisk/branches/13
Direct Media calls within private network sometimes get one way audio
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
projects / thirdparty / asterisk.git / log
