In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413682 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413668 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413651 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413599 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413572 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If the barge audiohook was attached prior to the spyee and its peer
actually being bridged, the audiohook would not be applied and the
connected peer would not be able to hear audio from the spy when the
spy is in barge mode.

(closes issue ASTERISK-23381)
Reported by: Robert Moss
Review: https://reviewboard.asterisk.org/r/3505/
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413557 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413488 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The CustomPresence provider callback will automatically base64 decode
stored data if the 'e' option was present when the state was set. However,
since the provider callback was bypassed on Asterisk startup, encoded
presence subtypes and messages were being sent instead. This fix makes
it so the provider callback is always used when providing presence
state updates.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413469 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fixed a ref leak in conf_handle_talker_cb() everytime the conference
bridge was found to report a channel's talker status change.  The
resulting leak caused the "CBAnn" channels and the conference bridge to
never be destroyed.

Thanks to Richard Kenner on the asterisk-user's list for locating the
problem.

Reported by: Richard Kenner
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413455 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fixed ref leak in the CLI "confbridge kick" command when the channel to be
kicked was not in the conference.
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413453 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Patches:
	res_config_odbc-take2.patch by John Hardin (License #6512)
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413399 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Embedded carriage return line feed combinations may appear in presence subtypes
and messages since they may be derived from user input in an instant messenger
client. As such, they need to be properly escaped so that XML parsers do not
vomit when the messages are received.
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413381 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There was an underlying issue in a realtime backend where database updates
would fail. Since we were not checking for failure, we would end up in a
strange state where the old database entry was still present but Asterisk
thought that it had been updated. Now when an entry fails to update, we
print a warning and delete the old contact from sorcery so there is no
mismatch between foreground and backend state.

Patches:
	res_pjsip_registrar.patch by John Hardin (License #6512)
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413359 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Patches:
	res_config_odbc.patch by John Hardin (License #6512)
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413307 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
Correct variable traversal logic in res_config_odbc's update_odbc function.

Closes issue ASTERISK-23675
Reported by Leando Dardini
Patches:
	asterisk-23675-odbc-linkedlist-traversal_12.diff uploaded by Michael L. Young (license #5026)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413283 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Patches:
    odbc-crash.patch by John Hardin (License #6512)
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413263 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The realtime API specifies that the store callback is supposed to return the number
of rows affected. res_config_pgsql was instead returning an Oid cast as an int, which
during any nominal execution would be cast to 0. Returning 0 when more than 0 rows were
inserted causes problems to the function's callers.

To give an idea of how strange code can be, this is the necessary code change to fix
a device state issue reported against chan_pjsip in Asterisk 12+. The issue was that
the registrar would attempt to insert contacts into the database. Because of the 0
return from res_config_pgsql, the registrar would think that the contact was not successfully
inserted, even though it actually was. As such, even though the contact was query-able
and it was possible to call the endpoint, Asterisk would "think" the endpoint was unregistered,
meaning it would report the device state as UNAVAILABLE instead of NOT_INUSE.

The necessary fix applies to all versions of Asterisk, so even though the bug reported
only applies to Asterisk 12+, the code correction is being inserted into 1.8+.

Closes issue ASTERISK-23707
Reported by Mark Michelson
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413227 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Per rfc3892, the Referred-By header in a REFER must be copied into the
referenced request (IE.  The outgoing INVITE to the transfer target).

* Automatically put the Referred-By header in the outgoing INVITE message
if the SIPREFERREDBYHDR channel variable is defined with a value.

* Made chan_sip.c:get_refer_info() set SIPREFERREDBYHDR for inheritance so
chan_pjsip has a better chance to interoperate.

* Fixed refer_blind_callback() and refer_incoming_refer_request() to not
modify the data in the pointer returned by pjsip_msg_find_hdr_by_name().
It seems wrong to modify that data since the calling routine doesn't own
the buffer.

ASTERISK-23501 #close
Reported by: John Bigelow

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413211 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes ASTERISK-23397)
Reported by: Denis
Review: https://reviewboard.asterisk.org/r/3446/
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413197 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When writing presence state, if 'e' is specified, then the presence state will
be stored in the astdb encoded. However, consumers of presence state events or those
that query for the presence state will be given decoded information. If base64 encoding
is desired for consumers, then the information can be base64-encoded manually and the
'e' option can be omitted.

closes issue ASTERISK-23671
Reported by Mark Michelson

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



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413183 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The PBX core already takes care of ensuring that repeated state changes
are not communicated to exten state consumers. Because the check in res_pjsip_exten_state
was incomplete, it was causing valid presence state changes not to be sent out. For instance,
if the presence state did not change but the message or subtype did, then no presence-related
NOTIFY request would be sent out.

closes issue ASTERISK-23672
Reported by Mark Michelson
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413174 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Previously this code would only accept the OpenSSL identifier instead
of the documented name.

ASTERISK-23498 #close
ASTERISK-23498 #comment Reported by: Anthony Messina

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413160 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Fixed early exit in sip_msg_send() not destroying the message iterator.

* Made ast_msg_var_iterator_next() and ast_msg_var_iterator_destroy()
tolerant of a NULL iter parameter in case ast_msg_var_iterator_init()
fails.

* Made ast_msg_var_iterator_destroy() clean up any current message data
ref.

* Made struct ast_msg_var_iterator, ast_msg_var_iterator_init(),
ast_msg_var_iterator_next(), ast_msg_var_unref_current(), and
ast_msg_var_iterator_destroy() use iter instead of i.

* Eliminated RAII_VAR usage in res_pjsip_messaging.c:vars_to_headers().
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413144 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If a task was in-flight which required the channel or bridge lock
it was possible for the synchronous task retrieving the call-id
to deadlock as it holds those locks.

After discussing with Mark Michelson the synchronous task was
removed and the call-id accessed directly. This should be safe as
each object involved is guaranteed to exist and the call-id will
never change.
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413141 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This resolves a race condition where data could be written to a NULL
FILE pointer causing a crash as a websocket connection was in the
process of shutting down by adding locking to websocket session writes
and by deferring session teardown until session destruction.

(closes issue ASTERISK-23605)
Review: https://reviewboard.asterisk.org/r/3481/
Reported by: Matt Jordan
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413125 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change fixes operations which did not account for the fact that they may
be executed on channels which have not been answered. These operations will
now indicate progress when invoked.

ASTERISK-23560 #close
ASTERISk-23560 #comment Reported by: Jan Svoboda

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413122 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change fixes a bug where if an SDP with media address and sendonly was
received twice the underlying call would go off hold, instead of remaining on hold.
This occured because the code did not properly take into account that the SDP
may contain both a valid media address and the sendonly attribute.

The code now examines the sendonly attribute and media address first, so if the
SDP is received again no change will occur.

ASTERISK-23558 #comment Reported by: John Bigelow

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413120 65c4cc65-6c06-0410-ace0-fbb531ad65f3

AST-1363

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413118 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The original commit for spinlock was missing "destroy" implementations.
Most of them are no-ops but phtread_spin and pthread_mutex do need their
locks destroyed.
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413103 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This changes implement the "get_pvt_uniqueid" which is used to return the
technology specific unique identifier. In the case of SIP this is the Call-ID
of the dialog.

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413089 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When bridge locking was added for bridge snapshot creation, some
locations where bridge locking was added were not guaranteed to
actually have a bridge and locking NULL AO2 objects tends to cause
segfaults. This ensures that NULL bridges aren't locked.
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413074 65c4cc65-6c06-0410-ace0-fbb531ad65f3

These events are controlled by two new modules, res_manager_devicestate
and res_manager_presencestate.

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



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413060 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Introducing changes proposed to chan_unistim driver:
1) Added the unistim.conf variable dtmf_duration which can select the DTMF playback duration from 0ms to 150ms (0 is off and is the new default)
2) Enabled the transmission of month names, which are sent with the date and changed the dateformat variable to accept the values 0-3 as per the UNISTIM standard (2 & 3 match the previous 1 & 2 formats).
3) Enabled the "Mute" packet so muting microphone works as expected and microphone muted for all calls while LED light on
4) Changed Duree to Timer on i2004 display

(closes issue ASTERISK-23592)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413048 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413036 65c4cc65-6c06-0410-ace0-fbb531ad65f3

On congested networks, it is possible for the DTLS handshake messages to get
lost. This patch adds a timer to res_rtp_asterisk that will periodically
check to see if the handshake has succeeded. If not, it will retransmit the
DTLS handshake.

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

ASTERISK-23649 #close
Reported by: Nitesh Bansal
patches:
  dtls_retransmission.patch uploaded by Nitesh Bansal (License 6418)
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413012 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The string lengths on certain columns created through alembic for PJSIP were
too short. For instance, columns containing URIs are currently set to 40
characters, but this can be too small and result in truncated values.  Added
an alembic migration script that increases the size of these columns and a
few others to 255.

ASTERISK-23639 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3475/
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412993 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There are cases in Asterisk where it might be desirable to lock
a short critical code section but not incur the context switch
and yield penalty of a mutex or rwlock.  The primary spinlock
implementations execute exclusively in userspace and therefore
don't incur those penalties.  Spinlocks are NOT meant to be a
general replacement for mutexes.  They should be used only for
protecting short blocks of critical code such as simple compares
and assignments.  Operations that may block, hold a lock, or
cause the thread to give up it's timeslice should NEVER be
attempted in a spinlock.

The first use case for spinlocks is in astobj2 - internal_ao2_ref.
Currently the manipulation of the reference counter is done with
an ast_atomic_fetchadd_int which works fine.  When weak reference
containers are introduced however, there's an additional comparison
and assignment that'll need to be done while the lock is held.
A mutex would be way too expensive here, hence the spinlock.
Given that lock contention in this situation would be infrequent,
the overhead of the spinlock is only a few more machine instructions
than the current ast_atomic_fetchadd_int call.

ASTERISK-23553 #close
Review: https://reviewboard.asterisk.org/r/3405/
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412977 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Backport -r411687 and fix the fix because content_length is the length of
out plus the length of the file controlled by fd.

When a response has an out content length of 0, fwrite would be called to
write a buffer with no data in it.  This resulted in the following classic
error message:

  [Apr  3 11:49:17] ERROR[26421] http.c: fwrite() failed: Success

This patch makes it so that we only attempt to write the content of out if
the out string is non-zero.
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412925 65c4cc65-6c06-0410-ace0-fbb531ad65f3

For some odd reason, loading app_mixmonitor was fine, but res_monitor was not.
This patch fixes a set of issues related to func_periodic_hook exporting the
beep functions that gets res_monitor working again.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412910 65c4cc65-6c06-0410-ace0-fbb531ad65f3