Skip to content
Snippets Groups Projects
Select Git revision
  • fix_fallback_from_tls
  • asterisk_rdkb
  • 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
  • asterisk_rdkb_temp
  • bug_14682_voicemail
  • 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
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
  • Gouri Natarajan Gouri Natarajan gouri.natarajan
20 authors
  1. May 03, 2015
  3. Apr 30, 2015
    • Richard Mudgett's avatar
      chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option. · 03c51cf5
      Richard Mudgett authored 
      Some telco switches occasionally ignore ISDN RESTART requests.  The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request.  If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco.  The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.

chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code.  Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards.  I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.

* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.

ASTERISK-25034 #close
Reported by: Richard Mudgett

Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
      03c51cf5
  5. Apr 28, 2015
  7. Apr 27, 2015
  9. Apr 21, 2015
  11. Apr 16, 2015
    • George Joseph's avatar
      res_pjsip: Add global option to limit the maximum time for initial qualifies · c6ed6816
      George Joseph authored 
      
Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup.  So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.

This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies.  This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.

If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random().  If not set,
qualify_timeout is used.

The default is "0" (disabled).

ASTERISK-24863 #close

Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      c6ed6816
    • George Joseph's avatar
      pjsip_options: Add qualify_timeout processing and eventing · 51886c68
      George Joseph authored 
      This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html



The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint.  Only dynamic contact add/delete actions
update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.

This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...

1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
marked unavailable.

2.  Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
existing endpoint events are generated appropriately.

ASTERISK-24863 #close

Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      51886c68
  13. Apr 15, 2015
    • Joshua Colp's avatar
      res_pjsip: Add external PJSIP resolver implementation using core DNS API. · a3cec44a
      Joshua Colp authored 
      This change adds the following:

1. A query set implementation. This is an API that allows queries to be executed in parallel and once all have completed a callback is invoked.
2. Unit tests for the query set implementation.
3. An external PJSIP resolver which uses the DNS core API to do NAPTR, SRV, AAAA, and A lookups.

For the resolver it will do NAPTR, SRV, and AAAA/A lookups in parallel. If NAPTR or SRV
are available it will then do more queries. And so on. Preference is NAPTR > SRV > AAAA/A,
with IPv6 preferred over IPv4. For transport it will prefer TLS > TCP > UDP if no explicit
transport has been provided. Configured transports on the system are taken into account to
eliminate resolved addresses which have no hope of completing.

ASTERISK-24947 #close
Reported by: Joshua Colp

Change-Id: I56cb03ce4f9d3d600776f36928e0b3e379b5d71e
      a3cec44a
  15. Apr 10, 2015
  17. Apr 09, 2015
  19. Apr 08, 2015
  21. Apr 07, 2015
    • Matthew Jordan's avatar
      ARI: Add the ability to intercept hold and raise an event · c2f50ba6
      Matthew Jordan authored 
      For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.

One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.

In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.

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

ASTERISK-24922 #close
........

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c2f50ba6
  23. Mar 24, 2015
    • Richard Mudgett's avatar
      chan_pjsip: Add "rpid_immediate" option to prevent unnecessary "180 Ringing" messages. · 4c2fc5b8
      Richard Mudgett authored 
      Incoming PJSIP call legs that have not been answered yet send unnecessary
"180 Ringing" or "183 Progress" messages every time a connected line
update happens.  If the outgoing channel is also PJSIP then the incoming
channel will always send a "180 Ringing" or "183 Progress" message when
the outgoing channel sends the INVITE.

Consequences of these unnecessary messages:

* The caller can start hearing ringback before the far end even gets the
call.

* Many phones tend to grab the first connected line information and refuse
to update the display if it changes.  The first information is not likely
to be correct if the call goes to an endpoint not under the control of the
first Asterisk box.

When connected line first went into Asterisk in v1.8, chan_sip received an
undocumented option "rpid_immediate" that defaults to disabled.  When
enabled, the option immediately passes connected line update information
to the caller in "180 Ringing" or "183 Progress" messages as described
above.

* Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
"183 Progress" messages.  The default is "no" to disable sending the
unnecessary messages.

ASTERISK-24781 #close
Reported by: Richard Mudgett

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4c2fc5b8
  25. Mar 17, 2015
  27. Mar 14, 2015
  29. Mar 13, 2015
  31. Mar 09, 2015
  33. Feb 12, 2015
    • Matthew Jordan's avatar
      ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app · 29f66b04
      Matthew Jordan authored 
      This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
    only transfer channels to a SIP URI, i.e., you had to pass
    'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
    still supported, it is somewhat unintuitive - particularly in a world full
    of endpoints. As such, we now also support specifying the PJSIP endpoint to
    transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
    updating its Contact header. Alas, that resulted in the forwarding
    destination set by the dialplan application/ARI resource/whatever being
    rewritten with very incorrect information. Hence, we now don't bother
    updating an outgoing response if it is a 302. Since this took a looong time
    to find, some additional debug statements have been added to those modules
    that update the Contact headers.

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

ASTERISK-24015 #close
Reported by: Private Name

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      29f66b04
  35. Jan 20, 2015
  37. Jan 16, 2015
  39. Jan 09, 2015
    • 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
    • Kinsey Moore's avatar
      res_fax: Add T.38 negotiation timeout option · 77ee2321
      Kinsey Moore authored 
      This change makes the T.38 negotiation timeout configurable via
't38timeout' in res_fax.conf or FAXOPT(t38timeout). It was previously
hard coded to be 5000 milliseconds.

This change also handles T.38 switch failures by aborting the fax since
in the case where this can happen, both sides have agreed to switch to
T.38 and Asterisk is unable to do so.

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

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      77ee2321
  41. Jan 07, 2015
  43. Jan 06, 2015
    • George Joseph's avatar
      outbound_registration: Add 'pjsip send register' and update 'send unregister' · fb3c8e34
      George Joseph authored 
      The current behavior of 'pjsip send unregister' is to send the unregister
(REGISTER with 0 exp) but let the next scheduled register proceed normally.
I don't think that's a good idea.  If you unregister, it should stay
unregistered until you decide to start registrations again.  So this patch
just adds a cancel_registration call to the current unregister_task to
cancel the timer.

Of course, now you need  a way to start registration again so I've added
a 'pjsip send register' command that unregisters and cancels any existing
registration (the same as send unregister), then sends an immediate
registration and starts the timer back up again.

Both changes also ripple to AMI.  There's a new PJSIPRegister command.

There's no harm in calling either command repeatedly.  They don't care
about the actual state.

Tested-by: George Joseph

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      fb3c8e34
  45. Jan 05, 2015
  47. Dec 22, 2014
    • Matthew Jordan's avatar
      app_confbridge: Add the ability to pass options/command to MixMonitor · b79a4a46
      Matthew Jordan authored 
      This patch adds the ability to pass options and a command to MixMontor when
recording a conference using ConfBridge.

New options are -

* record_options: Options to MixMontor, eg: m(), W() etc.
* record_command: The command to execute when recording is over.
* record_file_timestamp: Append the start time to the file name.

These options can also be used with the CONFBRIDGE function, e.g.,
Set(CONFBRIDGE(bridge,record_command)=/path/to/command ^{MIXMONITOR_FILENAME}))

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

ASTERISK-24351 #close
Reported by: Gareth Palmer
patches:
  record_command-428838.patch uploaded by Gareth Palmer (License 5169)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b79a4a46
  49. Dec 18, 2014
  51. Dec 15, 2014
  53. Dec 11, 2014
  55. Dec 10, 2014
  57. Dec 09, 2014
  59. Dec 08, 2014
  61. Dec 02, 2014
  63. Dec 01, 2014
    • Matthew Jordan's avatar
      main/stasis: Allow subscriptions to use a threadpool for message delivery · 1106e8fd
      Matthew Jordan authored 
      Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.

For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
  a single message - the subscription is created, a message is published, the
  delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.

This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.

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

ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........

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

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1106e8fd
  65. Nov 19, 2014
  67. Nov 17, 2014
  69. Nov 15, 2014