When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If res_phoneprov failed to fully load (due to not being configured), the
providers container will be NULL. If a module attempts to register a phone
provisioning provider, it should check for the presence of the container.
If there is no providers container, it should return an error.
This patch makes the ast_phoneprov_provider_register function do that...
otherwise this would be a silly commit message.
........
Merged revisions 425220 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425221 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the 'force_rport' option is enabled the behavior should be the same
as if the remote side placed rport into the message themselves. Therefore
any responses we send should include the source port of the request in the
rport of the Via header.
#SIPit31
ASTERISK-24387 #close
Reported by: Matt Jordan
........
Merged revisions 425131 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
endpoint->inbound_auths was changed to a vector in 13 and I
committed the 12 patch instead of the 13 patch.
Tested-by: George Joseph
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When starting ice if there is not at least one remote ice candidate with an RTP
component asterisk will crash. This is due to an assertion in pjnath as it
expects at least one candidate with an RTP component. Added a check to make
sure at least one candidate contains an RTP component and at least one candidate
has an RTCP component.
ASTERISK-24383 #close
Review: https://reviewboard.asterisk.org/r/4039/
........
Merged revisions 425030 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes res_phoneprov more modular so other modules (like pjsip)
can provide configuration information instead of res_phoneprov relying solely
on users.conf and sip.conf. To accomplish this a new ast_phoneprov public API
is now exposed which allows config providers to register themselves, set
defaults (server profile, etc) and add user extensions.
* ast_phoneprov_provider_register registers the provider and provides callbacks
for loading default settings and loading users.
* ast_phoneprov_provider_unregister clears the defaults and users.
* ast_phoneprov_add_extension should be called once for each user/extension
by the provider's load_users callback to add them.
* ast_phoneprov_delete_extension deletes one extension.
* ast_phoneprov_delete_extensions deletes all extensions for the provider.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/3970/
........
Merged revisions 424963 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The underlying library, pjnath, that res_rtp_asterisk uses for ICE
support does not have support for ICE-TCP. As candidates are
passed through directly to it this can cause error messages to occur
when it receives something unexpected (such as a TCP candidate).
This change merely ignores all non-UDP candidates so they never
reach pjnath.
ASTERISK-24326 #close
Reported by: Joshua Colp
........
Merged revisions 424852 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 424853 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 13+, any given message type is not guaranteed to exist even
if Asterisk comes up correctly since creation of the message type could
be declined. The indexer should not prevent Asterisk from starting
under these conditions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When message type creation is declined via stasis.conf, certain
operations log errors assuming that the declined type is being used
before initialization or after destruction. These error messages get
quite spammy for oft used message types and should not be logged in the
first place since the message type is validly NULL.
Reported by: Matt DiMeo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Formats within a capabilities structure are addressed starting at 0, not 1.
Assuming 1 causes it to exceed an array.
ASTERISK-24389 #close
Reported by: Kevin Harwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424752 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the auth_reject_permanent parameter was not initialized on
the registration client state, leading to the parameter being disabled
regardless of the value specified in pjsip.conf.
This patch initialized the setting on the registration client state to the
provided configuration value.
ASTERISK-24398 #close
........
Merged revisions 424730 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If SendMessage encounters an error (such as incorrect input provided to the
action), it will currently return -1. Actions should only return -1 if the
connection to the AMI client should be closed. In this case, SendMessage
causing the client to disconnect is inappropriate.
This patch causes the action to return 0, which simply causes the action to
fail.
Review: https://reviewboard.asterisk.org/r/4024
ASTERISK-24354 #close
Reported by: Peter Katzmann
patches:
sendMessage.patch uploaded by Peter Katzmann (License 5968)
........
Merged revisions 424690 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 424691 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the Bridge application to bridge a channel that is executing an
applicaiton such as Wait results in a lingering Surrogate channel in the
CLI "core show channels" output even though it has already hungup.
* Fix bridge_exec() to not hold onto the current_dest_chan ref once it has
been put into the bridge.
* Eliminated bridge_exec()'s use of RAII_VAR().
ASTERISK-24224 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4041/
........
Merged revisions 424668 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An OPTIONS request that is sent to Asterisk but not to a specific endpoint is
currently sent a 404 in response. This is because, not surprisingly, an empty
extension is never going to be found in the dialplan.
This patch makes it so that we only attempt to look up the endpoint in the
dialplan if it is specified in the OPTIONS request URI.
#SIPit31
ASTERISK-24370 #close
Reported by: Matt Jordan
........
Merged revisions 424624 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling PJSIP_MEDIA_OFFER on a non-PJSIP channel is hazardous to your health.
It will treat the channels as a PJSIP channel, eventually hitting an ao2 error,
FRACKing on assertion error, and quite likely crashing.
This patch adds checks to the read/write callbacks that ensure that the channel
technology is of type 'PJSIP' before attempting to operate on the channel.
#SIPit31
ASTERISK-24382 #close
Reported by: Matt Jordan
........
Merged revisions 424621 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a message that exceeds the PJ_MAX_PKT_SIZE is sent over a reliable
transport, it is possible (although it shouldn't occur) for pjproject to pass
up an rdata object with a NULL msg in the msg_info. Needless to say, things
that attempt to dereference this are in for a rough ride.
In particular, this caused crashes in three different locations, all of which
are 'low level' enough to intercept an rdata object early in processing:
(1) res_pjsip_logger
(2) res_hep_pjsip
(3) res_pjsip/distributor
Anything that can intercept an rdata object before res_pjsip/distributor should
be defensive when looking at the received packet.
#SIPit31
ASTERISK-24369 #close
Reported by: Matt Jordan
........
Merged revisions 424618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A subscription that has been persisted can - for various reasons - fail to be
re-created on startup. This patch resolves a number of crashes that occurred
when a subscription cannot be re-created on several off-nominal paths.
#SIPit31
ASTERISK-24368 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding a mixmonitor to a channel causes the bridge to change technologies
from native to simple_bridge so the call can be recorded. However, when
the mixmonitor is stopped the bridge does not switch back to the native
technology.
* Added unbridge requests to reevaluate the bridge when a channel
audiohook is removed.
* Moved the unbridge request into ast_audiohook_attach() ensure that the
bridge reevaluates whenever an audiohook is attached. This simplified the
mixmonitor and chan_spy start code as well.
* Added defensive code to stop_mixmonitor_full() in case additional
arguments are ever added to the StopMixMonitor application.
* Made ast_framehook_detach() not do an unbridge request if the framehook
does not exist.
* Made ast_framehook_list_fixup() do an unbridge request if there are any
framehooks. Also simplified the loop.
ASTERISK-24195 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4046/
........
Merged revisions 424506 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects some issues introduced in the responses to the
CoreShowChannels AMI command as well as adding documentation for the
responses. The command in Asterisk 12 was missing the following fields:
Duration, Application, ApplicationData, and BridgedChannel and
BridgedUniqueID (replaced with BridgeId).
ASTERISK-24262 #close
Reported by: Mitch Claborn
Review: https://reviewboard.asterisk.org/r/4040/
........
Merged revisions 424423 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the architecture of how media streams are handled each individual
handler adds connection details (IP address) for it. The first media stream
is then used as the top level SDP connection line. In practice each
line ends up being the same so to reduce the SDP size stream-level connection
information is also added to the SDP if it differs from the top level SDP
connection line.
........
Merged revisions 424414 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Improvements to the res_pjsip transport cipher option.
* Made the cipher option accept a comma separated list of OpenSSL cipher
names. Users of realtime will be glad if they have more than one name to
list.
* Added the CLI command 'pjsip list ciphers' so a user can know what
OpenSSL names are available for the cipher option.
* Updated the cipher option online XML documentation to specify what is
expected for the value.
* Updated pjsip.conf.sample to not indicate that ALL is acceptable since
ALL does not imply a preference order for the ciphers and PJSIP does not
simply pass the string to OpenSSL for interpretation.
ASTERISK-24199 #close
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/4018/
........
Merged revisions 424393 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424394 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During the latest update to DTLS-SRTP support the ability to configure
the hash used for fingerprints was added. This gave us two supported ones:
SHA-1 and SHA-256. The default was accordingly updated to SHA-256.
Unfortunately this configuration ability was not exposed within res_pjsip.
This change adds a dtls_fingerprint option that controls it.
#SIPit31
........
Merged revisions 424290 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424291 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This updates the code behind PJSIP configuration options with custom
handlers to deal with the assigned default values properly where it
makes sense and adjusting the default value where it doesn't. Before
applying this patch, there were several cases where the default value
for an option would prevent that config section from loading properly.
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4019/
........
Merged revisions 424263 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
