[test-results] [Bamboo] Asterisk Testing > Asterisk 1.8 Branch > #280 was SUCCESSFUL (with 185 tests). Change made by Mark Michelson and Matthew Jordan.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk 1.8 Branch > #280 was successful.
-----------------------------------------------------------------------
Code has been updated by Mark Michelson, Matthew Jordan.
185 tests in total.

http://bamboo.asterisk.org/browse/TESTING-ASTERISK18BRANCH-280/


--------------
Code Changes
--------------
Mark Michelson (369352):

>Re-fix how local tag is generated when sending a 481 to an INVITE.
>
>Match our local tag to whatever to-tag was sent in the initial INVITE.
>Because the size of the to-tag may not fit in the buffer in the sip_pvt,
>it has been changed to a string field.
>
>(closes issue ASTERISK-19892)
>reported by Walter Doekes
>
>Review: https://reviewboard.asterisk.org/r/1977
>
>

Matthew Jordan (369351):

>Fix incorrect duration reporting in CDRs created in batch mode
>
>Certain places in core/cdr.c would, if the duration value were 0, calculate the
>duration as being the delta between the current time and the time at which the
>CDR record was started.  While this does not typically cause a problem in
>non-batch mode, this can cause an issue in batch mode where CDR records are
>gathered and written long after those calls have ended. In particular, this
>affects calls that were never answered, as those are expected to have a duration
>of 0.  Often, this would result in CDR logs with a significant number of calls
>with lengthy durations, but dispositions of "BUSY".
>
>Note that this does not affect cdr_csv, as that backend does not use
>ast_cdr_getvar and instead directly reports the duration value.  The affected
>core backends include cdr_apative_odbc and cdr_custom; other extended or
>deprecated CDR backends may potentially still directly manipulate the duration
>values.
>
>(issue ASTERISK-19860)
>Reported by: Thomas Arimont
>
>(issue AST-883)
>Reported by: Thomas Arimont
>Tested by: Matt Jordan
>
>Review: https://reviewboard.asterisk.org/r/1996/
>



--------------
Tests
--------------
Fixed Tests (1)
   - AsteriskTestSuite: S/cdr/cdr fork end time

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