chan_ooh323: fix rtptimeout general value checking

correct condition to check rtptimeout in [general] config section

ASTERISK-24393 #close
Reported by:  Dmitry Melekhov
Tested by:  Dmitry Melekhov
Patches:
  ASTERISK-24393.patch
........

Merged revisions 425547 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 425548 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 425589 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425590 from http://svn.asterisk.org/svn/asterisk/branches/13
parking_tests: Fix assertions and possibly crashes in res_parking unit tests

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/
........

Merged revisions 425611 from http://svn.asterisk.org/svn/asterisk/branches/13
chan_motif: Cleanup jingle_tech.capabilities only once.
........

Merged revisions 425627 from http://svn.asterisk.org/svn/asterisk/branches/13
res_rtp_asterisk: Fix a bug where ICE state would get reset when it shouldn't.

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
........

Merged revisions 425646 from http://svn.asterisk.org/svn/asterisk/branches/13
Fix loss of voice after second call drops (on a second line) in case using multiple lines on unistim phones. There is regression was introduced in r391379.

Reported by: Rustam Khankishyiev
(closes issue ASTERISK-23846)
........

Merged revisions 425667 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 425668 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425669 from http://svn.asterisk.org/svn/asterisk/branches/13
PJSIP: Enforce module load dependencies

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
........

Merged revisions 425691 from http://svn.asterisk.org/svn/asterisk/branches/13
config: Fix inf loop using ast_category_browse and ast_variable_retrieve

Fix infinite loop when calling ast_variable_retrieve inside an
ast_category_browse loop when there is more than 1 category with
the same name.

Tested-by: George Joseph

Review: https://reviewboard.asterisk.org/r/4089/
........

Merged revisions 425713 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425714 from http://svn.asterisk.org/svn/asterisk/branches/13
main/cdr: Use 'time' when rescheduling batched CDRs as opposed to 'size'

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
........

Merged revisions 425736 from http://svn.asterisk.org/svn/asterisk/branches/13
test_cel: Update pickup test to expect CANCEL instead of ANSWSER

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
........

Merged revisions 425758 from http://svn.asterisk.org/svn/asterisk/branches/13
bridge_native_rtp: Fix audio issues when moving from remote bridge to softmix

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
........

Merged revisions 425761 from http://svn.asterisk.org/svn/asterisk/branches/13
AMI: Add missing VarSet events when a channel inherits variables.

There should be AMI VarSet events when channel variables are inherited by
an outgoing channel.  Also local;2 should generate VarSet events when it
gets all of its channel variables from channel local;1.

ASTERISK-24415 #close
Reported by: Richard Mudgett
Patches:
      jira_asterisk_24415_v12.patch (license #5621) patch uploaded by Richard Mudgett

Review: https://reviewboard.asterisk.org/r/4074/
........

Merged revisions 425782 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425783 from http://svn.asterisk.org/svn/asterisk/branches/13
res_pjsip: Add 'user_eq_phone' option to add a 'user=phone' parameter when applicable.

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/
channels/chan_sip: Respect outboundproxy setting when sending qualify requests

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
........

Merged revisions 425821 from http://svn.asterisk.org/svn/asterisk/branches/13
res_pjsip_keepalive: Add runtime configurable keepalive module for connection-oriented transports.

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/
res_pjsip_session/res_pjsip_sdp_rtp: Be more tolerant of offers

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
........

Merged revisions 425879 from http://svn.asterisk.org/svn/asterisk/branches/13
Sample Configurations: make 'pjsip reload' reload all reloadable pjsip modules

AST-1432 #close
Reported by: John Bigelow
........

Merged revisions 425905 from http://svn.asterisk.org/svn/asterisk/branches/13
res/res_pjsip_sdp_rtp: Remove left over reference to override_prefs

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.
res/res_pjsip_sdp_rtp: Revert 425924

This patch for r425924 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.
build: Force -fsigned-char on platforms where the default for char is unsigned

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
........

Merged revisions 425965 from http://svn.asterisk.org/svn/asterisk/branches/13
AST-2014-011: Fix POODLE security issues

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
    ecnryption 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
........

Merged revisions 425991 from http://svn.asterisk.org/svn/asterisk/branches/13