Age | Commit message (Collapse) | Author |
|
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.
ASTERISK-24552 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4243/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change staggers initiation of outbound qualify (OPTIONS) attempts
to reduce instantaneous server load and prevent network congestion.
Review: https://reviewboard.asterisk.org/r/4246/
ASTERISK-24342 #close
Reported by: Richard Mudgett
........
Merged revisions 429127 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429128 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The AMI event is called NewConnectedLine and the ARI event is called
ChannelConnectedLine.
ASTERISK-24554 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/4231
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429064 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429062 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
of a transfer.
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
While troubleshooting other things I realized there were no pjsip cli
commands for identify. This patch adds them. It also also fixes a
reference leak when a 'show endpoint' displayed identifies and properly
sets the return code if load_module can't allocate a cli formatter structure.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4212/
........
Merged revisions 428725 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428731 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The biggest problem this patch fixes is that ACLs weren't previously being
loaded when the res_pjsip_acl module was loaded. Yikes. In addition, the
ACL options contact_permit and contact_acl were effectively interpreted as
contact_deny and this patch fixes that as well.
AST-1418 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4120/
ASTERISK-24531 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4171/
........
Merged revisions 428333 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
res_pjsip_refer.
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Accessing members of struct ast_str outside of the string manipulation API
routines is invalid since struct ast_str is supposed to be treated as
opaque.
Review: https://reviewboard.asterisk.org/r/4194/
........
Merged revisions 428244 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428245 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Optimistic SRTP is the ability to enable SRTP but not have it be
a fatal requirement. If SRTP can be used it will be, if not it won't be.
This gives you a better chance of using it without having your sessions
fail when it can't be.
Encrypt all the things!
Review: https://reviewboard.asterisk.org/r/3992/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There is no guarantee that when we get a Refer-To that it will be NULL terminated.
As the URI parsing function requires it to be we now NULL terminate it.
Additionally parsing the Refer-To as a 'To' header is needless and it can
simply be done as a URI. This also fixes a problem where certain Refer-To headers
would not be parsed as a 'To' header causing the REFER to fail.
ASTERISK-24508 #close
Reported by: Beppo Mazzucato
Review: https://reviewboard.asterisk.org/r/4187/
........
Merged revisions 428195 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 428168 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
and normal expiration period.
This change enforces the requirements in PJSIP for session timer configuration. The minimum
expiration period must be 90 seconds or higher and the normal expiration period can not
be lower than the minimum expiration period. If either of these were done the code would
assert at session setup time.
ASTERISK-24336 #close
Reported by: Leon Rowland
........
Merged revisions 427978 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is the Asterisk 13 version of the patch. The main difference is in the pubsub
code since it was completely refactored between Asterisk 12 and 13.
Review: https://reviewboard.asterisk.org/r/4175
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When using a non-default sorcery wizard (in this instance realtime) for
outbound registrations and after adding in an appropriate call to
ast_sorcery_apply_config() (since it is missing) Asterisk will crash after
a stack overflow occurs due to the code infinitely recursing. The fix entails
removing the outbound registration state dependency from the outbound
registration sorcery object and instead keeping an in memory container that
can be used to lookup the state when needed.
ASTERISK-24514
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4164/
........
Merged revisions 427814 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change corrects message ordering in cases where a channel-related
message can be received after a Stasis/ARI application has received the
StasisEnd message. The StasisEnd message was being passed to
applications directly without waiting for the channel topic to empty.
As a result of this fix, other bugs were also identified and fixed:
* StasisStart messages were also being sent directly to apps and are
now routed through the stasis message bus properly
* Masquerade monitor datastores were being removed at the incorrect
time in some cases and were causing StasisEnd messages to not be sent
* General refactoring where necessary for the above
* Unsubscription on StasisEnd timing changes to prevent additional
messages from following the StasisEnd when they shouldn't
A channel sanitization function pointer was added to reduce processing
and AO2 lookups.
Review: https://reviewboard.asterisk.org/r/4163/
ASTERISK-24501 #close
Reported by: Matt Jordan
........
Merged revisions 427788 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When handling incoming messages we determine if it is associated with
a dialog. If so we use that to determine what serializer and endpoint
to use for the message. Previously this would pass the endpoint to the
endpoint lookup module to actually place the endpoint completely on the
message. For in-dialog responses, however, this did not occur as
dialog processing took over and the endpoint lookup did not occur.
This change just places the endpoint in the expected spot immediately
instead of relying on the endpoint lookup module. In-dialog responses
thus have the expected endpoint.
AST-1459 #close
Review: https://reviewboard.asterisk.org/r/4146/
........
Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427491 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add missing unreference in hepv3_send_packet.
ASTERISK-24491 #close
Reported by: Zane Conkle
Tested by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4150/
........
Merged revisions 427400 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Testing has shown repeatedly that PJSIP's default behavior of switching
automatically to TCP for large messages can cause issues. The most common
issues are that devices that we are communicating with do not handle the
switch to TCP gracefully, thus causing situations such as broken calls or
broken subscriptions. Now, in order to have this behavior happen, you must
opt into it. The sample file has been updated to warn that enabling the
TCP switch behavior may cause issues for you, so use at your own risk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
DNS is misbehaving.
This change adds a bit of logging so if the local DNS is misbehaving it is easier
to track down what is going on and where Asterisk may be hanging.
ASTERISK-24438 #close
Reported by: Melissa Shepherd
Review: https://reviewboard.asterisk.org/r/4148/
........
Merged revisions 427300 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In websocket_add_protocol_internal is used to add the "echo"
protocol, but ast_websocket_remove_protocol is used to remove
it. This causes an extra call to ast_module_unref.
ASTERISK-24480 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4140/
........
Merged revisions 427200 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a packet exceeds the MTU, pjproject will switch from UDP to TCP. In
some circumstances (on some networks), this can cause some issues with
messages not getting sent to the correct destination - and can also cause
connections to get dropped due to quirks in pjproject deciding to
terminate TCP connections with no messages.
While fixing the routing/messaging issues is important, having a
configuration option in Asterisk that tells pjproject to not switch over
to TCP would be useful. That way, if some glitch is discovered on some
other network/site, we can at least disable the behavior until a fix is
put into place.
AFS-197 #close
Review: https://reviewboard.asterisk.org/r/4137/
........
Merged revisions 427129 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When the res_stasis module is unloaded, it will dispose of the apps_registry
container. This is a problem if an ARI operation is in flight that attempts
to use the registry, as the shutdown occurs in a separate thread. This patch
adds some sanity checks to the various routines that access the registry which
cause the operations to fail if the apps_registry does not exist.
Crash caught by the Asterisk Test Suite.
........
Merged revisions 426995 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A question arose as to whether a .pem file
could be provided in place of the .crt and
.key files in a PJSIP TLS configuration. I
tested this and discovered that although a
cert will be read from the pem file, a key
will not, and thus the priv_key_file entry
is still required. This update to the fine
documentation clarifies the option usage.
AST-1448 #close
Review: https://reviewboard.asterisk.org/r/4129/
Reported by: John Bigelow
........
Merged revisions 426928 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426930 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This updates the status of the outbound registration
to reflect when it has been unregistered. Since the
registration is unregistered but is not stopped, the
registration schedule remains active as before. The
patch also updates the documentation of both the AMI
and CLI commands.
ASTERISK-24411 #close
Review: https://reviewboard.asterisk.org/r/4119/
Reported by: John Bigelow
patches:
unregister-patch1.txt uploaded by John Bigelow (License 5091)
........
Merged revisions 426923 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Currently, it is possible for some subscriptions to get into a NULL state. When
this occurs and the PJSIPShowSubscriptionsInbound ami action is issued and a
device is subscribed for extension state then the associated subscription state
object can't be located. The code then attempts to dereference a NULL object.
Added a NULL check to avoid the problem.
Reported by: John Bigelow
........
Merged revisions 426779 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When removing the qualify_frequency from an AoR or a contact the statistics
shown when issuing "pjsip show aors" from the CLI are incorrect. This patch
deletes the contact's status object from sorcery, disassociating it from the
contact, if the qualify_freqency is removed from configuration.
ASTERISK-24462 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4116/
........
Merged revisions 426755 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When frames are translated by a fax gateway they need to be freed. The
existing call to ast_frfree was unreachable. This change reorganizes
fax_gateway_framehook to ensure that ast_frfree is called when needed.
ASTERISK-24457 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4115/
........
Merged revisions 426527 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 426528 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When Moises committed the fixes for WSS (which was a great patch), wdoekes had
a few style nits that were on the review that got missed. This patch resolves
what I *think* were all of the ones that were still on the review.
Thanks to both moy for the patch, and wdoekes for the reviews.
Review: https://reviewboard.asterisk.org/r/3248/
........
Merged revisions 426209 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 426210 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In res_phoneprov, unloading the module first destroys the http_routes
container, followed by the users. However, users may have a route in
the http_routes container; the validity of this container is not checked
in the users destructor. Hence, we hit an assert as the container has already
been set to NULL.
This patch does two things:
(1) It adds a sanity check in the user destructor (because why not)
(2) It switches the order of destruction, so that users are disposed of prior
to the HTTP routes they may hold a reference to.
Note that this crash was caught by the Test Suite (go go testing!)
........
Merged revisions 426174 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In libsrtp 1.5.0, crypto_get_random is no longer resolved simply by including
srtp.h. Now, one must include crypto_kernel.h as well. As it turns out, this
header file has been provided by the library since 2006, so this is a
relatively benign change.
ASTERISK-24436 #close
Reported by: Patrick Laimbock
........
Merged revisions 426140 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 426141 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 426142 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
will default to the OpenSSL SSLv23_method. This method allows for all
encryption methods, including SSLv2/SSLv3. A MITM can exploit this by
forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.
Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.
Review: https://reviewboard.asterisk.org/r/4096/
ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
AST-2014-011-11.diff uploaded by mjordan (License 6283)
........
Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch for r425922 introduced a bug, wherein sending an INVITE request
with no SDP would cause Asterisk to not send an SDP Offer in the 200
OK. The current structure of res_pjsip_sdp_rtp is a bit hard to deal with
to fix this, as create_outgoing_sdp has no knowledge of whether or not it is
creating an SDP as a new Offer or an Answer. This is something of an oversight
in the callback definition, as the caller of it does have this information.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The usage of the local override_prefs variable in create_outgoing_sdp_stream
was previously to track an override format preference set by PJSIP_MEDIA_OFFER.
Now, however, that function simply sets the joint capabilities structure,
session->req_caps. During the media format rework, the override_prefs was
instead used to check if there were any formats in session->req_caps.
However, this usage isn't useful in create_outgoing_sdp_stream.
session->req_caps contains the negotiated formats for *all* streams, not just
the current one being created. Thus, so long as any stream of any type has
provided a format, override_prefs will be non-zero. Hence, its usage in
checking whether or not we should look at the formats on the endpoint or
the joint capabilities is generally useless.
There's only two things useful to check:
(1) Does the endpoint have a format for the media type?
(2) Did we negotiate a format for the media type?
If either of those is a 'no', then we must kill the media stream.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When an inbound SDP offer is received, Asterisk currently makes a few
incorrection assumptions:
(1) If the offer contains more than a single audio/video stream, Asterisk will
reject the entire stream with a 488. This is an overly strict response;
generally, Asterisk should accept the media streams that it can accept and
decline the others.
(2) If the offer contains a declined media stream, Asterisk will attempt to
process it anyway. This can result in attempting to match format
capabilities on a declined media stream, leading to a 488. Asterisk should
simply ignore declined media streams.
(3) Asterisk will currently attempt to handle offers with AVPF with
use_avpf=No/AVP with use_avpf=Yes. This mismatch results in invalid SDP
answers being sent in response. If there is a mismatch between the media
type being offered and the configuration, Asterisk must reject the offer
with a 488.
This patch does the following:
* Asterisk will accept SDP offers with at least one media stream that it can
use. Some WARNING messages have been dropped to NOTICEs as a result.
* Asterisk will not accept an offer with a media type that doesn't match its
configuration.
* Asterisk will ignore declined media streams properly.
#SIPit31
Review: https://reviewboard.asterisk.org/r/4063/
ASTERISK-24122 #close
Reported by: James Van Vleet
ASTERISK-24381 #close
Reported by: Matt Jordan
........
Merged revisions 425868 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub
have loaded properly before attempting to load any modules that depend
on them since the module loader system is not currently capable of
resolving module dependencies on its own.
ASTERISK-24312 #close
Reported by: Dafi Ni
Review: https://reviewboard.asterisk.org/r/4062/
........
Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In the case where the ICE negotiation had not yet started current state would
get wiped when it shouldn't.
This also removes channel binding as in practice this does not work well with
other implementations.
........
Merged revisions 425644 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425645 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Assertions were caused by attempting to play music on hold to a channel with
no formats. Parking unit test channels were given formats and a technology so
that they would be able to pretend to read/write frames.
ASTERISK-24413 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4075/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Based on feedback from Richard, I created an accessor for
res_phoneprov/ast_phoneprov_std_variable_lookup and added
load priority to AST_MODULE_INFO.
Tested-by: George Joseph
Tested-by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4076/
........
Merged revisions 425480 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425481 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Fax gateway session objects can be re-used, causing the
same gateway session to be added to faxregistry.container
more than once. This change causes fax_session_new to
remove the reserved session from the container before
it's id is changed, ensuring it's possible for the
session to be freed.
ASTERISK-24392 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4049/
........
Merged revisions 425457 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425458 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Remove reference to module providing reserved session after
adding a reference to the final module. This re-reference
is done to ensure that module references are correct even
if the final session selects a different module than the
reserved session.
ASTERISK-18923 #close
Reported by: Grigoriy Puzankin
Review: https://reviewboard.asterisk.org/r/4048/
........
Merged revisions 425405 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 425407 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425411 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
implementations use 'udp'.
........
Merged revisions 425360 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425361 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Allow res_calendar_ews to work not only with libneon-0.29 but also
with 0.30.
ASTERISK-24325 #close
Reported by: Tzafrir Cohen
Review: https://reviewboard.asterisk.org/r/4068/
........
Merged revisions 425286 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 425287 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425288 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|