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
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI/ARI are getting a few enhancements in the next release of Asterisk 13. Per
semantic versioning, that warrants a bump in the minor version number, as it
reflects a backwards compatible change. Hence, this commit.
........
Merged revisions 429091 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reviewboard description does a fine job of summarizing this, so here it is:
A reporter discovered that Asterisk would crash when attempting to retransmit
a reinvite that had previously received a 491 response. The crash occurred
because a pjsip_tx_data structure was being saved for reuse, but its reference
count was not being increased. The result was that the pjsip_tx_data was being
freed before we were actually done with it. When we attempted to re-use the
structure when re-sending the reinvite, Asterisk would crash.
The fix implemented here is not to try holding onto the pjsip_tx_data at all.
Instead, when we reschedule sending the reinvite, we create a brand new
pjsip_tx_data and send that instead. Because of this change, there is no need
for an ast_sip_session_delayed_request structure to have a pjsip_tx_data on
it any more. So any code referencing its use has been removed.
When this initial fix was introduced, I encountered a second crash when
processing a subsequent 200 OK on a rescheduled reinvite. The reason was
that when rescheduling the reinvite, we gave the wrong location for a
response callback. This has been fixed in this patch as well.
ASTERISK-24556 #close
Reported by Abhay Gupta
Review: https://reviewboard.asterisk.org/r/4233
........
Merged revisions 429089 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects several bugs that currently exist in the stasis
application code.
* After a masquerade, the resulting channels have channel topics that
do not match their uniqueids
** Masquerades now swap channel topics appropriately
* StasisStart and StasisEnd messages are leaked to observer
applications due to being published on channel topics
** StasisStart and StasisEnd publishing is now properly restricted
to controlling apps via app topics
* Race conditions exist where StasisStart and StasisEnd messages due to
a masquerade may be received out of order due to being published on
different topics
** These messages are now published directly on the app topic so this
is now a non-issue
* StasisEnds are sometimes missing when sent due to masquerades and
bridge swaps into and out of Stasis()
** This was due to StasisEnd processing adjusting message-sent flags
after Stasis() had already exited and Stasis() had been re-entered
** This was corrected by adjusting these flags prior to sending the
message while the initial Stasis() application was still shutting
down
Review: https://reviewboard.asterisk.org/r/4213/
ASTERISK-24537 #close
Reported by: Matt DiMeo
........
Merged revisions 429061 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429062 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When repeatedly starting/stopping a Monitor on a channel, the accumulated
in/out sample counts are never reset to 0. This can cause inadvertent jumps
in the recordings, as the code in the channel core will determine incorrectly
that a jump in the recorded file position should occur. Setting the sample
counts to 0 simply reflects the initial state a Monitor should be in when it
is started, as this is the initial count that would be on the channels at that
time.
ASTERISK-24573 #close
Reported by: Nuno Borges
patches:
24573.patch uploaded by Nuno Borges (License 6116)
........
Merged revisions 429031 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429032 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429033 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a race condition between the raising of test AMI events (which
drive many tests in the Asterisk Test Suite) and other AMI events. Prior to
this patch, the Stasis messages published to the test topic were not forwarded
to the AMI topic. Instead, the code in manager had a dedicated handler for test
messages that was independent of the topics forwarded to the AMI topic. This
results in no synchronization between the test messages and the rest of the
Stasis messages published out over AMI. In some test with very tight timing
constraints, this can result in out of order messages and spurious test
failures. Properly forwarding the Test Suite topic to the AMI topic ensures
that the messages are synchronized properly.
This patch does that, and moves the message handling to the Stasis definition
of the Test Suite message in test.c as well.
Review: https://reviewboard.asterisk.org/r/4221/
........
Merged revisions 428945 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428946 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the publication of attended transfer messages were pushed to another
thread, some subtle race conditions were introduced with the CEL unit tests.
This patch fixes one of them, and pushes the other to ASTERISK-22367, which
already exists to fix another bouncy CEL unit test.
In particular, this patch fixes the test_cel_attended_transfer_bridges_link
test, and defers the test_cel_attended_transfer_bridges_swap test to the
aforementioned JIRA issue.
ASTERISK-22367
........
Merged revisions 428891 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428892 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The UW IMAP library is instrinsically not thread-safe, and relies upon higher
level applications to guarantee thread safety. For the most part, this is
provided by the vms object, which provides locking for individual streams.
Unfortunately, this is not sufficient for calls to mail_open which create the
IMAP stream. mail_open can, on some systems, call into a UW IMAP specific
function for determining the address of a system based on a hostname,
ip_nametoaddr.
In the ip6_unix implementation of this function, static variables are used
to hold parsing buffers. This can cause a crash if multiple threads attempt
to convert a hostname to an address at the same time. Locking on a single
mail stream is not sufficient to prevent simultaneous access to these static
variables.
In the IMAP library, this function can be called from the mail_open and
imap_status functions. As the imap_status function is not used by
app_voicemail, locking on access to mail_open is sufficient to prevent
any mangling of the buffers.
Review: https://reviewboard.asterisk.org/r/4188/
ASTERISK-24516 #close
Reported by: David Duncan Ross Palmer
Tested by: David Duncan Ross Palmer
patches:
ASTERISK-24516.diff uploaded by David Duncan Ross Palmer (License 6660)
........
Merged revisions 428863 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428864 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428865 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes a small rearrangement to only do dialplan lookups during
loopback switches if the pattern matches. Prior to this patch, the dialplan
lookups were always performed, even when the result would be discarded.
Dialplan lookups can be very costly if remote switches - like DUNDi - are
present. In those cases extension matching is sped up considerably, making
the issue of lost digits more manageable.
As collateral damage, 6 trailing spaces were killed.
Review: https://reviewboard.asterisk.org/r/4211
ASTERISK-24577 #close
Reported by: Birger Harzenetter
patches:
ast-loopback.patch uploaded by Birger Harzenetter (License 5870)
........
Merged revisions 428787 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428788 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428789 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two methods within res_pjsip_refer for keeping track of the state of a transfer.
The first is a framehook which looks at frames passing by to determine the state. The second
subscribes to know when the channel joins a bridge. In the case when the channel joins the
bridge the framehook is *NOT* removed and this prevents the native RTP bridging technology
from getting used.
This change gets the channel and if it still exists remove the framehook.
Review: https://reviewboard.asterisk.org/r/4218/
........
Merged revisions 428760 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428761 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When shutting down Asterisk that has an active AMI connection, you get
several "failed to extend from %d to %d" messages because use of the
EVENT_FLAG_SHUTDOWN attempts to add all AMI permission strings to the
event.
* Created MAX_AUTH_PERM_STRING to use when creating stack based struct
ast_str variables used with the authority_to_str() and
user_authority_to_str() functions instead of a variety of magic numbers
that could be too small.
* Added a special check for EVENT_FLAG_SHUTDOWN to authority_to_str() so
it will not attempt to add all permission level strings.
Review: https://reviewboard.asterisk.org/r/4200/
........
Merged revisions 428570 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428571 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428572 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime
was tossing database fields that didn't have an exact match to a sorcery
registered field. This broke the ability to use regexes as field names which
manifested itself as a failure of res_pjsip_phoneprov_provider which uses
this capability. It also broke handling of fields that start with '@' in
realtime but I don't think anyone noticed.
This patch does the following...
* Modifies ast_sorcery_fields_register to pre-compile the name regex.
* Modifies ast_sorcery_is_object_field_registered to test the regex if it
exists instead of doing an exact strcmp.
* Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work
with realtime.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4185/
........
Merged revisions 428543 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428544 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r428165, two bugs were introduced:
* Prior to entering the features retry loop, the buffer that holds the
collected digits is wiped. However, this inadvertently wipes out the
first collected digit on the first pass through, which is obtained
in ast_stream_and_wait. This caused all of the features tests to fail.
* If ast_app_dtget returns a hangup (-1), the loop would retry incorrectly.
If we detect a hangup, we have to stop trying the feature.
This patch fixes both issues.
Review: https://reviewboard.asterisk.org/r/4196/
........
Merged revisions 428505 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Confbridge dialplan function permission escalation via AMI and inappropriate
class authorization on the ConfbridgeStartRecord action. The CONFBRIDGE dialplan
function when executed from an external protocol (for instance AMI), could
result in a privilege escalation. Also, the AMI action “ConfbridgeStartRecord”
could also be used to execute arbitrary system commands without first checking
for system access. The AMI “ConfbridgeStopRecord” has also been updated to
only run under a system authorization.
Asterisk now inhibits the CONFBRIDGE function from being executed from an
external interface if the live_dangerously option is set to no. Also, the
“ConfbridgeStartRecord” AMI action is now only allowed to execute under a
user with system level access.
ASTERISK-24490
Reported by: Gareth Palmer
........
Merged revisions 428332 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428334 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428339 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The implementation of INVITE with Replaces in res_pjsip_refer did not expect them to
occur in-dialog. As a result it would incorrectly attempt to hang up a channel it
thought was under its control. In reality the channel would be under the control of
another thread. When the other thread accessed the channel it would be accessing freed
memory and could crash.
This change makes res_pjsip_refer not act on an in-dialog INVITE with Replaces.
ASTERISK-24528 #close
Reported by: Joshua Colp
........
Merged revisions 428304 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428305 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the serialized architecture of chan_pjsip there exists a race condition where a CANCEL may
be received and processed before responses (such as 180 Ringing, 183 Session Progress, and 200 OK)
are sent. Since the session is in an unexpected state PJSIP will assert when this is attempted.
This change makes it so that these responses are not sent on disconnected sessions.
ASTERISK-24471 #close
Reported by: yaron nahum
........
Merged revisions 428301 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428302 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r428077 was made for ASTERISK-24522, it failed to take into account users
who are neither wait_marked nor end_marked. These users are *also* supposed to
hear the 'leader has left the conference' message. Granted, this behaviour is
a bit odd; however, that is how it used to work... and behaviour changes are
not good.
This patch ensures that if there are any 'normal' users present when the last
marked user leaves the conference, the message will still be played to them.
Note that this regression was caught by the Asterisk Test Suite's
confbridge_nominal test, which has a quirky combination of users.
........
Merged revisions 428113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428114 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428115 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
