[test-results] [Bamboo] Asterisk Testing > Asterisk 11 Branch > #142 has FAILED (3 tests failed, 2 failures were new). Change made by 5 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk 11 Branch > #142 failed.
-----------------------------------------------------------------------
Code has been updated by Mark Michelson, Matthew Jordan, rmudgett, Kinsey Moore, file.
3/288 tests failed, 2 failures were new.

http://bamboo.asterisk.org/browse/TESTING-AST11BRANCH-142/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 64-Bit (CentOS 6): 3 of 288 tests failed.



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

>Fix incorrect billing duration reported when batch mode is enabled
>
>Similar to r369351, the billing duration can be skewed when batch mode is
>enabled.  This happened much more rarely than the duration, as it only
>occured when the call was answered (thereby indicating an actual answer
>time) and immediately hung up on (indicating a billsec of 0).  Since
>a billing time of '0' can either mean that the call immediately ended
>or that the CDR was improperly answered, we have to use additional information
>to know whether or not we can trust the CDR billsec value.  Prior to this
>patch, we looked to see if we had a valid answer time.  If we did, and
>billsec was zero, we used the current time to calculate what billsec value
>we could from the CDR being written.  If batch mode is enabled, this will
>incorrectly report a billsec value being much greater than the actual
>duration of the call.
>
>Instead of relying on the presence of an answer time to know whether or not
>we can re-calculate the billsec for the CDR, we now also use the presence
>of the CDR's end time to know if we need to re-calculate or whether we can
>trust the billsec value that we have.  This prevents erroneous jumps in the
>billsec value, while still making sure that in the worst case, some billing
>time will be calculated.
>
>(closes issue AST-1016)
>Reported by: Thomas Arimont
>Tested by: Thomas Arimont
>........
>
>Merged revisions 374843 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>........
>
>Merged revisions 374844 from http://svn.asterisk.org/svn/asterisk/branches/10
>

rmudgett (374804):

>app_queue: Made pass connected line updates from the caller to ringing queue members.
>
>Party A calls Party B
>Party B puts Party A on hold.
>Party B calls a queue.
>Ringing queue member D sees Party B identification.
>Party B transfers Party A to the queue.
>Queue member D does not get a connected line update for Party A.
>Queue member D answers the call and still sees Party B information.
>
>However, if Party A later transfers the call to Party C then queue member
>D gets a connected line update for Party C.
>
>* Made pass connected line updates from the caller to queue members while
>the queue members are ringing.
>
>(closes issue AST-1017)
>Reported by: Thomas Arimont
>
>(closes issue ABE-2886)
>Reported by: Thomas Arimont
>Tested by: rmudgett
>
>........
>
>Merged revisions 374801 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
>........
>
>Merged revisions 374802 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>........
>
>Merged revisions 374803 from http://svn.asterisk.org/svn/asterisk/branches/10
>

Kinsey Moore (374792):

>Fix segfault regression from r370681
>
>Due to usage of ast_hook_send_action, AMI action handling code should
>be able to handle a NULL mansession->session.  This would cause a crash
>on NULL dereference if action_originate was called from
>ast_hook_send_action.
>
>(closes issue ASTERISK-20544)
>



--------------
Tests
--------------
New Test Failures (2)
   - AsteriskTestSuite: S/channels/ s i p/sip attended transfer tcp
   - AsteriskTestSuite: S/apps/voicemail/check voicemail options record unavail
Existing Test Failures (1)
   - AsteriskTestSuite: S/channels/ s i p/sip outbound address

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