When overlap dialing is enabled, the lack of inband audio available
information in the SETUP_ACKNOWLEDGE events causes an interoperability
problem with SIP. sig_pri doesn't know if there is dialtone present when
a SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an
AST_CONTROL_PROGRESS frame. The SIP channel driver then sends out a 183
Session Progress and blocks the desired 180 Ringing message when the
ALERTING message comes in.
* Made the configure script detect if the installed version of libpri
supports the SETUP_ACKNOWLEDGE enhancements.
* Using the new API, made generate an AST_CONTROL_PROGRESS frame on an
incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio
is present instead of assuming that dialtone is present.
* Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio
available indication only if dialtone is expected. The change also makes
the fallback behaviour of sending the PROGRESS message better by sending
it only if dialtone is expected.
* Changed receiving a PROCEEDING message to not generate an
AST_CONTROL_PROGRESS frame if the progress indication ie indicates
non-end-to-end-ISDN. This helps interoperability with SIP.
* Changed sending a PROCEEDING message in response to an
AST_CONTROL_PROCEEDING frame to not indicate inband audio available. It
was silly to do so anyway because the channel driver doesn't know if
inband audio is even available. This helps interoperability with SIP.
This patch and a corresponding change in libpri work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.
AST-1338 #close
Reported by: Tyler Stewart
Review: https://reviewboard.asterisk.org/r/3521/
........
Merged revisions 413714 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 413765 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413771 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413681 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413650 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413454 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413372 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/12@413282 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413226 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413210 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413173 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413142 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413140 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413121 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413119 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413102 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413073 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@413009 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412992 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412976 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This changes fixes a crash that occurs when stasis determines if it
should send a message out to an application or not. The code
incorrectly assumed that a bridge snapshot would always be present
when in reality for failure cases it may not be.
ASTERISK-23573 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds the TCP_NODELAY option to accepted connections on the HTTP
server built into Asterisk. This option disables the Nagle algorithm
which controls queueing of outbound data and in some cases can cause
delays on receipt of response by the client due to how the Nagle
algorithm interacts with TCP delayed ACK. This option is already set on
all non-HTTP AMI connections and this change would cover standard HTTP
requests, manager HTTP connections, and ARI HTTP requests and
websockets in Asterisk 12+ along with any future use of the HTTP
server.
Review: https://reviewboard.asterisk.org/r/3466/
........
Merged revisions 412745 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412748 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r411189, some behavior was changed which made sendrpid behavior
act in a more trusting manner by sending full user data for peers
set with private caller presence in P-Asserted-Identity headers.
Since this changed long time expected behaviors, we decided to pull
that patch when that was pointed out by the community. Instead, this
patch provides a trust_id_outbound setting which will expose the data
per RFC-3325 if set to 'yes' and simply not send the PAI/RPID headers
at all if set to 'no'. By default trust_id_outbound will be set to
'legacy' which will preserve the behavior prior to these patches.
Extra special thanks to Walter Doekes for providing advice and
feedback.
(closes issue AST-1301)
(closes issue ASTERISK-19465)
Reported by: Krzysztof Chmielewski
Review: https://reviewboard.asterisk.org/r/3447/
........
Merged revisions 412744 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412746 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds documentation for the "all" channel option for the
ConfbridgeKick AMI action and adjusts AMI responses accordingly.
(issue ASTERISK-23282)
Reported by: Dorian Logan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the ability to kick all attendees from a conference was added, a
rework removed the comment about that feature from the CLI
documentation. This adds that documentation and adds "all" to the
participant tab completion list for the confbridge kick command.
(closes issue ASTERISK-23282)
Reported by: Dorian Logan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ASTERISK-23265/ASTERISK-23320 was fixed, it inadvertently led to realtime
features breaking. This was due to features loading prior to realtime. This
patch fixes this by loading features after loading dynamic modules.
ASTERISK-23487 #close
Reported by: Denis
Tested by: Denis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two issues in app_sms:
(1) Firstly, the 'flags' field on the stack in sms_exec() is uninitialised,
causing it to use the wrong protocol in some cases. This patch correctly
initializes the flags fields.
(2) Secondly, when disconnect supervision is not working or
inbanddisconnect=yes is set in chan_dahdi.conf, app_sms was failing to
terminate the call after it sent the REL(ease) message and the peer stopped
talking to it. This patch fixes the code to handle the 'bad stop bit'
message more gracefully in that case, and hang up the call.
Review: https://reviewboard.asterisk.org/r/1392/
ASTERISK-18331 #close
Reported by: David Woodhouse
patches:
asterisk-fix-sms.patch uploaded by David Woodhouse (License 5754)
........
Merged revisions 412655 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412656 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412657 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously multiple play actions against a bridge at one time would cause
the sounds to play simultaneously on the bridge. Now if a sound is already
playing, the play action will queue playback to occur after the completion
of other sounds currently on the queue.
(closes issue ASTERISK-22677)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In sounds/Makefile
1 Adds and moves some lines necessary for the en_GB core set. I'm just following how the other sets are defined here.
2 removes the ES extra sounds related lines as we don't have ES extra sound sets.
In sounds/sounds.xml
3 Adds member definitons for EN_AU, EN_GB, IT for core sound sets, and EN_GB in extra sound sets
ASTERISK-23550 #close
Review: https://reviewboard.asterisk.org/r/3464/
........
Merged revisions 412586 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@412587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
