asterisk

Commit Graph

Author	SHA1	Message	Date
Alexander Traud	9440f6ec58	main: Fix for Doxygen. ASTERISK-29763 Change-Id: Ib8359e3590a9109eb04a5376559d040e5e21867e	4 years ago
Kevin Harwell	bdd785d31c	various files - fix some alerts raised by lgtm code analysis This patch fixes several issues reported by the lgtm code analysis tool: https://lgtm.com/projects/g/asterisk/asterisk Not all reported issues were addressed in this patch. This patch mostly fixes confirmed reported errors, potential problematic code points, and a few other "low hanging" warnings or recommendations found in core supported modules. These include, but are not limited to the following: * innapropriate stack allocation in loops * buffer overflows * variable declaration "hiding" another variable declaration * comparisons results that are always the same * ambiguously signed bit-field members * missing header guards Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25	6 years ago
Mark Michelson	aae45acbda	Detect potential forwarding loops based on count. 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	11 years ago

Author

SHA1

Message

Date

Alexander Traud

9440f6ec58

main: Fix for Doxygen.

ASTERISK-29763

Change-Id: Ib8359e3590a9109eb04a5376559d040e5e21867e

Kevin Harwell

bdd785d31c

various files - fix some alerts raised by lgtm code analysis

This patch fixes several issues reported by the lgtm code analysis tool:

https://lgtm.com/projects/g/asterisk/asterisk

Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:

* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards

Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25

Mark Michelson

aae45acbda

Detect potential forwarding loops based on count.

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

3 Commits (f7a8ac086de697db30e376d589a6f4e17cfabef5)