Skip to content
Snippets Groups Projects
Select Git revision
  • dev_fxs_no_wb
  • asterisk_rdkb
  • fix_transport_fallback_at_dns_failure
  • 14600-wenpeng
  • fix_fallback
  • 14666_fxs_no_wideband_codec
  • fix_srv_records
  • wenpeng-test-250121
  • wenpeng-registration-test
  • fix_deadlock_in_bridge_peer_functions
  • devel default protected
  • securesip_pjproject_part1
  • PJ_Example_Review
  • fix_re_register_authorization_header
  • fix_internal_calls_auth
  • fix_internal_calls
  • Secure_SIPtelephony_part1
  • SIPtelephony_DECT_syslog
  • syslog_develop_phase1
  • merge-asterisk-20.8.1
  • 22.0.0-pre1
  • 21.4.2
  • 20.9.2
  • 18.24.2
  • certified-20.7-cert2
  • certified-18.9-cert11
  • 21.4.1
  • 20.9.1
  • 18.24.1
  • 21.4.0
  • 20.9.0
  • 18.24.0
  • certified-20.7-cert1
  • certified-18.9-cert10
  • 21.4.0-rc1
  • 20.9.0-rc1
  • 18.24.0-rc1
  • 21.3.1
  • 20.8.1
  • 18.23.1
40 results
Search by author
  • Any Author
  • Adam Porteous Adam Porteous adam.porteous
  • Alex Hopkins Alex Hopkins 59hopper
  • Amin Ben Romdhane Amin Ben Romdhane amin.benromdhane
  • Andreas Gnau Andreas Gnau AGnau
  • Andrej Kucharik Andrej Kucharik andrej.kucharik
  • Andrii Pypa Andrii Pypa andrii.pypa
  • Anjan Chanda Anjan Chanda anjancx
  • Balalakshmi Arunachalam Rajendran Balalakshmi Arunachalam Rajendran arbala
  • Benjamin Larsson Benjamin Larsson benjamin
  • Charles Foster Charles Foster charles.foster_bt.com
  • Dariusz Iwanoczko Dariusz Iwanoczko dariusz.iwanoczko
  • Divya Chandrasekaran Divya Chandrasekaran divya.c
  • Dominic Lake Dominic Lake dominic.lake
  • Elena Vengerova Elena Vengerova helen
  • Erik Karlsson Erik Karlsson erik.karlsson
  • Filip Matusiak Filip Matusiak filmat
  • Filip Strelec Filip Strelec filip.strelec
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
20 authors
  1. Mar 10, 2015
    • Matthew Jordan's avatar
      app_voicemail: Fix crash with IMAP backends when greetings aren't present · ab6e2c93
      Matthew Jordan authored 
      When an IMAP backend is in use and greetings are set to be used, but aren't
present for a user in their IMAP folder, Asterisk will crash. This occurs
due to the mailstream being set to the 'greetings' folder and being left
in that particular state, regardless of the success/failure of the attempt
to access the folder the mailstream points to. Later access of the mailstream
assumes that it points to the 'INBOX' (or some other folder), resulting in
either a crash (if the greetings folder didn't exist and the mailstream is
invalid) or an inability to read messages from the 'INBOX' folder.

This patch restores the mailstream to its correct state after accessing the
greetings. This fixes the crash, and sets the mailstream to the state that
VoiceMailMain expects.

Note that while ASTERISK-23390 also contained a patch for this issue, the
patch on ASTERISK-24786 is the one being merged here.

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

ASTERISK-23390 #close
Reported by: Ben Smithurst

ASTERISK-24786 #close
Reported by: Graham Barnett
Tested by: Graham Barnett
patches:
  app_voicemail.c.patch.SIGSEGV3rev2 uploaded by Graham Barnett (License 6685)
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ab6e2c93
  3. Mar 05, 2015
  5. Feb 26, 2015
  7. Feb 21, 2015
    • Matthew Jordan's avatar
      apps/app_voicemail: Demote an ERROR message to a WARNING message · b3c1ad5d
      Matthew Jordan authored 
      When using IMAP voicemail with FreePBX, you will often get ERROR messages
complaining about not being able to find a mailbox. This is due to how FreePBX
handles voicemail mailboxes. Unfortunately, app_voicemail has to consider this
a configuration error, as in any other system it would be indicative of
someone misconfiguring their system.

Regardless, a misconfiguration is a WARNING, and not an ERROR. This patch
demotes the message so that system administrators can hopefully reduce some
of the noise in their log files.

Note that in the original patch this was made into a NOTICE, but that's a
too forgiving.

ASTERISK-24790 #close
Reported by: Graham Barnett
patches:
  app_voicemail.c.patch_noise uploaded by Graham Barnett (License 6685)
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432100 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b3c1ad5d
  9. Feb 20, 2015
  11. Feb 15, 2015
  13. Feb 11, 2015
    • Richard Mudgett's avatar
      HTTP: Stop accepting requests on final system shutdown. · e2d3215b
      Richard Mudgett authored 
      There are three CLI commands to stop and restart Asterisk each.

1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.

2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system.  New channels are prevented while the
shutdown request is pending.

3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system.  New calls are not prevented while the
shutdown request is pending.

ARI has made stopping/restarting Asterisk more problematic.  While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls.  To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.

* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.

* Made refuse new HTTP requests when the system has reached the final
system shutdown phase.  Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.

* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry.  This is similar to how other
modules prevent crashes on rapid system shutdown.

* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down().  You should not have to include channel.h just to
access these system functions.

ASTERISK-24752 #close
Reported by: Matthew Jordan

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e2d3215b
  15. Jan 30, 2015
    • Richard Mudgett's avatar
      app_agent_pool: Fix initial module load agent device state reporting. · 23bb5f6a
      Richard Mudgett authored 
      When the app_agent_pool module initially loads there is a race condition
between the thread loading agents.conf and the device state internal
processing thread.  If the device state internal processing thread handles
the agent creation state updates before the thread that loaded agents.conf
registers the device state provider callback then the cached agent state
is "Invalid".  When a consumer module like app_queue asks for the agent state
it gets the cached "Invalid" state instead of the real state from the provider.

* Moved loading the agents.conf configuration to the last thing setup by
app_agent_pool in load_module().  Now the device state provider callback
is registered before the config is loaded so the agent creation state
updates are guaranteed to get the initial device state.

* Removed some now redundant config cleanup on error in load_config().

* Added lock protection when accessing the device state in
agent_pvt_devstate_get() and eliminated the RAII_VAR() usage.

ASTERISK-24737 #close
Reported by: Steve Pitts

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      23bb5f6a
  17. Jan 27, 2015
  19. Jan 23, 2015
  21. Jan 22, 2015
  23. Jan 21, 2015
    • Matthew Jordan's avatar
      apps/app_dial: Don't publish DialEnd twice on unexpected GoSub/Macro values · 4740ef50
      Matthew Jordan authored 
      The Dial application has some interesting options with the mid-call Macro (M)
and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific
values, the Dial application will take some action upon the channels involved
in the dial operation (such as hanging up a particular party, etc.) The Dial
application ensures that a Stasis message is published in the event that
MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so
that there is a corresponding DialEnd event published in AMI/ARI for the
DialBegin event that preceeded it.

A bug exists where that same DialEnd event will be published on Stasis even if
the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial
application cares about. This causes two DialEnd events to be published - one
with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all
sorts of wrong.

This patch fixes the bug by ensuring that we only publish a DialEnd message to
Stasis if the Dial application's mid-call Macro/GoSub returns something that
Dial cares about.

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

ASTERISK-24682 #close
Reported by: Matt Jordan
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4740ef50
  25. Jan 20, 2015
  27. Jan 13, 2015
  29. Jan 12, 2015
  31. Jan 09, 2015
    • Richard Mudgett's avatar
      AMI: Remove no longer used parameter from astman_send_listack(). · ef34a05f
      Richard Mudgett authored 
      Follow-up issue to -r430435 from reviewboard review.

ASTERISK-24049
Review: https://reviewboard.asterisk.org/r/4315/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ef34a05f
    • Richard Mudgett's avatar
      AMI: Make AMI actions that generate event lists consistent. · 52a7cdb1
      Richard Mudgett authored 
      * Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList

* Incremented the AMI version to 2.7.0.

* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start".  The corresponding complete event always used "Complete".

* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.

* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots().  Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.

* Fixed minor protocol error in action_getconfig() when no requested
categories are found.  Each line needs to be formatted as "Header: text".

* Fixed off-nominal memory leak in manager_build_parked_call_string().

* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().

ASTERISK-24049 #close
Reported by: Jonathan Rose

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      52a7cdb1
  33. Dec 22, 2014
  35. Dec 17, 2014
  37. Dec 06, 2014
  39. Dec 03, 2014
    • Matthew Jordan's avatar
      apps/app_voicemail: Fix crash with IMAP when streams are opened simultaneously · 6d4ef7dd
      Matthew Jordan authored 
      The UW IMAP library is instrinsically not thread-safe, and relies upon higher
level applications to guarantee thread safety. For the most part, this is
provided by the vms object, which provides locking for individual streams.
Unfortunately, this is not sufficient for calls to mail_open which create the
IMAP stream. mail_open can, on some systems, call into a UW IMAP specific
function for determining the address of a system based on a hostname,
ip_nametoaddr.

In the ip6_unix implementation of this function, static variables are used
to hold parsing buffers. This can cause a crash if multiple threads attempt
to convert a hostname to an address at the same time. Locking on a single
mail stream is not sufficient to prevent simultaneous access to these static
variables.

In the IMAP library, this function can be called from the mail_open and
imap_status functions. As the imap_status function is not used by
app_voicemail, locking on access to mail_open is sufficient to prevent
any mangling of the buffers.

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

ASTERISK-24516 #close
Reported by: David Duncan Ross Palmer
Tested by: David Duncan Ross Palmer
patches:
  ASTERISK-24516.diff uploaded by David Duncan Ross Palmer (License 6660)
........

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6d4ef7dd
  41. Dec 01, 2014
  43. Nov 20, 2014
  45. Nov 17, 2014
  47. Nov 14, 2014
    • Mark Michelson's avatar
      Fix race condition that could result in ARI transfer messages not being sent. · 2d9471ab
      Mark Michelson authored 
      From reviewboard:

"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?

The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."

The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2d9471ab
    • Joshua Colp's avatar
      app_confbridge: Play "leader has left" sound even when musiconhold is enabled. · 737b8117
      Joshua Colp authored 
      Currently if the leader of a conference bridge leaves any participant
that has musiconhold enabled will not hear the "leader has left" sound.
This is because musiconhold is started and THEN the sound is played.

This change makes it so that the sound is played and THEN musiconhold
is started. This provides a better experience for users as they may not
have known previously why they went back to musiconhold.

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

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      737b8117
  49. Nov 09, 2014
  51. Nov 06, 2014
  53. Nov 03, 2014
  55. Nov 02, 2014
  57. Oct 30, 2014