A potential problem that can arise is the following:

* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.

If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.

Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.

The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:

* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.

This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:

* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.

The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.

Address review feedback on gerrit.

* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
  max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c

ASTERISK-24958 #close

Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e

........
  r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
  
  Add support-level indications to many more source files.
  
  Since we now have tools that scan through the source tree looking for files
  with specific support levels, we need to ensure that every file that is
  a component of a 'core' or 'extended' module (or the main Asterisk binary)
  is explicitly marked with its support level. This patch adds support-level
  indications to many more source files in tree, but avoids adding them to
  third-party libraries that are included in the tree and to source files
  that don't end up involved in Asterisk itself.
........
  r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
  
  Add a script to enable finding source files without support-levels defined.
........

Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10


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

After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.

Original patch by mikma, updated for trunk and revised by me.

(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel

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


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
  
  Fix feature inheritance with builtin features
  
  When using builtin features like parking and transfers, the AST_FEATURE_* flags
  would not be set correctly for all instances when either performing a builtin
  attended transfer, or parking a call and getting the timeout callback.  Also,
  there was no way on a per-call basis to specify what features someone should
  have on picking up a parked call (since that doesn't involve the Dial() command).
  There was a global option for setting whether or not all users who pickup a
  parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
  AUTOMON, or PARKCALL.
  
  This patch:
  1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
  dialplan or with setvar in channels that support it.  This variable can be set
  to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
  equivalent dial options), to set what features should be activated on this
  channel.  The patch moves the setting of the features datastores into the
  bridging code instead of app_dial to help facilitate this.
  
  2) adds global options parkedcallparking, parkedcallhangup, and
  parkedcallrecording to be similar to the parkedcalltransfers option for
  globally setting features.
  
  3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
  extension since tracking everything through multiple masquerades, etc. is
  difficult and error-prone
  
  4) attempts to fix all cases of return calls from parking and completed builtin
  transfers not having the correct permissions
  (closes issue #14274)
  Reported by: aragon
  Patches: 
        fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
  Tested by: aragon, otherwiseguy
  
  Review http://reviewboard.digium.com/r/138/
........


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

Asterisk, when parking can drop rights a caller when a parking timeout occurs.  Also, when doing built-in attended transfers, sometimes incorrectly passes rights from the transferrer to the transferee.  This patch tries to fixes the parking issue and lays some groundwork for later fixing the transfer issue.

(closes issue #11520)
Reported by: pliew
Tested by: otherwiseguy


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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r92363 | file | 2007-12-11 15:51:40 -0400 (Tue, 11 Dec 2007) | 6 lines

Fix potential memory leak with the dialed interfaces list if another memory allocation fails.
(closes issue #11507)
Reported by: eliel
Patches:
      global_datastores.c.patch uploaded by eliel (license 64)

........


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

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

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines

A big one...

This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.

This change also introduces some side effects to the code which I shall enumerate here:

1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
   which handles the call forward case after the channel has been requested but before it has
   been called. This was removed because call-forwarding still works fine without it, it makes the
   code less error-prone should it need changing, and it made this set of changes much less painful
   to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
   which is attached to the channel may be created and attached in either app_dial or app_queue, so they
   need a common place to find the datastore info. This approach was taken in case similar datastores are
   needed in the future, there will be a common place to add them.

........


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