[test-results] [Bamboo] Asterisk Testing > Asterisk Trunk > #1525 has FAILED (38 tests failed, 1 failures were new). Change made by Matthew Jordan.

Bamboo bamboo at asterisk.org
Sun Jul 14 00:24:02 CDT 2013


-----------------------------------------------------------------------
Asterisk Testing > Asterisk Trunk > #1525 failed.
-----------------------------------------------------------------------
Code has been updated by Matthew Jordan.
1/2 jobs failed, with 38 failing tests, 1 failure was new.

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-1525/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 32-Bit (CentOS 6): 38 of 620 tests failed.



--------------
Code Changes
--------------
Matthew Jordan (394290):

>Fix FRACK message from external redirects; handle outbound channels better
>
>This patch does the following:
> * It simplifies the Dial handling in CDRs. As a rule, the caller in a dial
>   relationship is always the Party A. There was some logic present in the
>   handling of the dial message that could, conceivably, pick the caller
>   as Party A for the beginning of the dial and the peer as Party A for the
>   end of the dial. This shouldn't have happened if the code in the bridging
>   framework was doing its job; however, that was broken and it led to the
>   FRACK. As it is, this code was overly ocmplex and not needed: the caller,
>   if present, should always be Party A. Period.
> * It properly checks to see if a channel will continue on in the dialplan.
>   ast_check_hangup - much like cake at the end - is a lie. It will tell
>   you that you are hungup when you are not. Do not believe it.
>
>   I would make this function tell the truth, but I'm nervous that we've been
>   depending on it sitting on its throne of lies for far too long, and it would
>   probably break lots of things. So I'm just checking the "internal" soft
>   hangup flags, like everyone else.
>
>(closes issue ASTERISK-22060)
>Reported by: Mark Michelson
>
>(issue ASTERISK-21831)
>Reported by: Matt Jordan
>
>



--------------
Tests
--------------
New Test Failures (1)
   - AsteriskTestSuite: S/bridge/blindxfer nominal
Existing Test Failures (37)
   - AsteriskTestSuite: S/apps/queues/position priority maxlen
   - AsteriskTestSuite: S/channels/iax2/basic-call
   - AsteriskTestSuite: S/channels/ s i p/sip one legged transfer
   - AsteriskTestSuite: S/apps/queues/queue baseline
   - AsteriskTestSuite: S/apps/queues/set penalty
   - AsteriskTestSuite: S/bridge/automixmon
   - AsteriskTestSuite: S/bridge/blindxfer setup
   - AsteriskTestSuite: S/channels/ s i p/sip hold
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/callee with reinvite
   - AsteriskTestSuite: S/bridge/transfer failure
   - AsteriskTestSuite: S/bridge/parkcall
   - AsteriskTestSuite: S/manager/bridge actions
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/caller with reinvite
   - AsteriskTestSuite: S/bridge/atxfer setup
   - AsteriskTestSuite: S/channels/gulp/incoming calls without auth
   - AsteriskTestSuite: S/channels/ s i p/sip blind transfer/caller refer only
   - AsteriskTestSuite: S/channels/ s i p/acl call
   - AsteriskTestSuite: S/fax/local channel t38 queryoption
   - AsteriskTestSuite: S/feature attended transfer
   - AsteriskTestSuite: S/masquerade
   - AsteriskTestSuite: S/bridge/disconnect
   - AsteriskTestSuite: S/bridge/dial l s options
   - AsteriskTestSuite: S/bridge/automon
   - AsteriskTestSuite: S/bridge/parkcall timeout/comebacktoorigin yes

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


More information about the Test-results mailing list