[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