When merging from 12 to 13 there were conflicts,
I mistakenly had the loop run ast_closestream(others[0])
when it should be ast_closestream(others[x]).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427181 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
When r426594 was made, it did not take into account a unit test that verified
that the function properly populated the unsupported buffer. The function
would previously memset the buffer if it detected it had any contents; since
this function can now be called iteratively on successive headers, the unit
tests would now fail. This patch updates the unit tests to reset the buffer
themselves between successive calls, and updates the documentation of the
function to note that this is now required.
........
Merged revisions 426858 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 426860 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 426863 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426865 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
The feature_automonitor() and feature_automixmonitor() functions were not
locking the channel around ast_get_chan_features_general_config().
Accessing the channel datastore list without the channel locked is a good
way to corrupt the list or follow the pointer chain into oblivion.
........
Merged revisions 426531 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is imparted to a bridge, the invocation of the function may
provide an ast_bridge_features struct. Upon passing this to ast_bridge_impart,
the caller must assume that ownership has passed to the function, as in all
paths the function destroys the struct prior to returning (as its purpose is
to configure the behavior of the channel while in the bridge). On one off
nominal path - where the channel already has a PBX thread - the struct was not
being destroyed.
This patch fixes that glitch.
ASTERISK-24437 #close
Reported by: Scott Griepentrog
........
Merged revisions 426431 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Because opus transcoding support cannot be included in the standard Asterisk
distribution, a few codec_opus implementations have popped up. To make it
easier for people to drop in opus support in their own installations, this
patch adds configure checks for libopus.
Review: https://reviewboard.asterisk.org/r/4106/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426234 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
This fixes a Segmentation fault introduced in r419044 "media formats: re-architect
handling of media for performance improvements".
The problem is that codec_dahdi was using core_src_codec and core_dst_codec in the
ast_translator structure when these fields were never set. Now instead of trying to map
the new core codec descriptions to the way DAHDI defines different codecs, we will store
the DAHDI specific formats in 'struct translator' directly so we can refer to them without
mapping.
This also allows us to remove the "global_format_map" structure, since we can now query
the list of translators directly to make sure we do not ever register a DAHDI based
translator for a specific path more than once and eliminate the need to keep the list and
the map in sync.
ASTERISK-24435 #close
Reported by: Marian Koniuszko
Review: https://reviewboard.asterisk.org/r/4105/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the AMI Status action read and write translation path strings from
growing for each channel in the status event list by reseting the ast
string given to ast_translate_path_to_str() to fill in the given
translation path.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426079 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
gcc on the ARM platform defaults 'char' to 'unsigned char' whereas Intel and
SPARC default to 'signed char'. This is only an issue in the rare cases where
negative values are assigned to a 'char' but this this patch insures
compatibility by detecting platforms that default to 'unsigned' and adding an
'-fsigned-char' flag to _ASTCFLAGS.
If compiling for ARM (native or cross-compile) be sure to run ./bootstrap.sh
and ./configure to regenerate the build files. You shouldn't have to do this
for Intel or SPARC.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4091/
........
Merged revisions 425964 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425965 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
The outboundproxy setting is currently ignored when sending OPTIONS requests
as a result of the qualify setting. This means that if an Asterisk server is
unable to send the packet directly to a peer, it is unable to qualify any
non-inbound registered peer (e.g. a peer SIP Trunk).
This patch grabs the outboundproxy information for a peer when a qualify
attempt is being constructed and, if it finds the information, uses it
when sending the OPTIONS request.
Review: https://reviewboard.asterisk.org/r/3948
ASTERISK-24063 #close
Reported by: Damian Ivereigh
patches:
outboundproxy-dai.patch uploaded by Damian Ivereigh (License 6632)
........
Merged revisions 425818 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 425819 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 425820 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a native RTP bridge that is remotely bridging its participants switches
to a softmix bridge, it may not properly re-INVITE the media for one or both
participants back to Asterisk. This is due to the current bridge_native_rtp
code only re-INVITEs if it believes the channel will survive the bridge
operation. Currently, that code is failing, as it expects the channels to
have a soft hangup flag set on it indicating that a redirect has occurred
or that the channel is going to leave the bridge. (The code did not take into
account a smart bridge operation).
This patch also renames a few things to be more reflective of the underlying
types.
Review: https://reviewboard.asterisk.org/r/3997/
ASTERISK-24327 #close
........
Merged revisions 425760 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CEL pickup test previously looked for a disposition of ANSWER between the
original caller/peer when the call is picked up. This is actually incorrect:
the disposition should, at the very least, not be ANSWER as the call was
never ANSWERed. The disposition is now CANCEL; this patch updates the test
accordingly.
........
Merged revisions 425757 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refactoring CDRs to use the configuration framework, a 'whoops' was
introduced where the CDR batch size was used when rescheduling a batch,
as opposed to the time duration. This patch corrects that obvious mistake.
ASTERISK-24426 #close
Reported by: Shane Blaser
........
Merged revisions 425735 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
