[test-results] [Bamboo] Asterisk > Asterisk Full Build > #1036 was SUCCESSFUL. Change made by 5 authors.

Bamboo noreply at bamboo.asterisk.org
Mon Apr 20 12:43:14 CDT 2015


-----------------------------------------------------------------------
Asterisk > Asterisk Full Build > #1036 was successful.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKBUILD-1785.
All 2 jobs passed

https://bamboo.asterisk.org/bamboo/browse/AST-ATRUNKFULLBUILD-1036/




--------------
Code Changes
--------------
Corey Farrell (c1d44ff0430dda6241effc775a84c9434e2fc1ba):

>Fix issue with AST_THREADSTORAGE_RAW when DEBUG_THREADLOCALS is enabled.
>When DEBUG_THREADLOCALS is enabled it causes the threadlocal cleanup to be
>called as a function.  This causes a compile error with raw threadstorage as
>it uses NULL for cleanup.  This fix uses a macro that provides NULL when
>DEBUG_THREADLOCALS is disabled, and replaces the call to "c_cleanup(data);"
>with "{};" when DEBUG_THREADLOCALS is enabled.
>
>ASTERISK-24975 #close
>Reported by: Ashley Sanders
>
>Change-Id: I3ef7428ee402816d9fcefa1b3b95830c00d5c402

Mark Michelson (aae45acbda1f6100cd9de816855166a32b991ce0):

>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

Joshua Colp (1d5854f5f44dda4bcedc6ea9d21abdc1c92ce3e0):

>Merge "Fix issue with AST_THREADSTORAGE_RAW when DEBUG_THREADLOCALS is enabled."



--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20150420/c9241bd0/attachment-0001.html>


More information about the Test-results mailing list