[test-results] [Bamboo] Asterisk > Asterisk Full Build > #1035 has FAILED. Change made by Matt Jordan <mjordan at digium.com>.

[Bamboo]

-----------------------------------------------------------------------
Asterisk > Asterisk Full Build > #1035 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKBUILD-1780.
1/2 jobs failed, no tests found.

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

---------------------
Currently Responsible
---------------------

foobar  (Automatically assigned)



--------------
Failing Jobs
--------------
  - CentOS 6 32-Bit Basic Build (Basic Build): No tests found.



--------------
Code Changes
--------------
George Joseph (ab6382cafd3ff13dce7916b1770b1bd61fe38f01):

>res_pjsip: Refactor endpt_send_request to include transaction timeout
>This is the first follow-on to https://reviewboard.asterisk.org/r/4572/ and the
>discussion at
>http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
>
>Since we currently have no control over pjproject transaction timeout, this
>patch pulls the pjsip_endpt_send_request function out of pjproject and into
>res_pjsip/endpt_send_transaction in order to implement that capability.
>
>Now when the transaction is initiated, we also schedule our own pj_timer with
>our own desired timeout.
>
>If the transaction completes before either timeout, pjproject cancels its timer,
>and calls our tsx callback where we cancel our timer and run the app callback.
>
>If the pjproject timer times out first, pjproject calls our tsx callback where
>we cancel our timer and run the app callback.
>
>If our timer times out first, we terminate the transaction which causes
>pjproject to cancel its timer and call our tsx callback where we run the app
>callback.
>
>Regardless of the scenario, pjproject is calling the tsx callback inside the
>group_lock and there are checks in the callback to make sure it doesn't run
>twice.
>
>As part of this patch ast_sip_send_out_of_dialog_request was created to replace
>its similarly named private function.  It takes a new timeout argument in
>milliseconds (<= 0 to disable the timeout).
>
>ASTERISK-24863 #close
>Reported-by: George Joseph <george.joseph at fairview5.com>
>Tested-by: George Joseph <george.joseph at fairview5.com>
>
>Change-Id: I0778dc730d9689c5147a444a04aee3c1026bf747

Matt Jordan <mjordan at digium.com> (bb347fa594e195c79cbda45cb55fde3e72f90f9c):

>Merge topic 'ASTERISK-24863'
>* changes:
>  res_pjsip: Add global option to limit the maximum time for initial qualifies
>  pjsip_options: Add qualify_timeout processing and eventing
>  res_pjsip: Refactor endpt_send_request to include transaction timeout

George Joseph (51886c68dc13edf127e64218528b077a5f6de967):

>pjsip_options: Add qualify_timeout processing and eventing
>This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
>discussion at
>http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
>
>The basic issues are that changes in contact status don't cause events to be
>emitted for the associated endpoint.  Only dynamic contact add/delete actions
>update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
>which is a long time.
>
>This patch makes use of the new transaction timeout feature in r4585 and
>provides the following capabilities...
>
>1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
>user to specify the maximum time in milliseconds to wait for a response to an
>OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
>marked unavailable.
>
>2.  Contact status changes are now propagated up to the endpoint as follows...
>When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
>all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
>existing endpoint events are generated appropriately.
>
>ASTERISK-24863 #close
>
>Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
>Tested-by: Dmitriy Serov
>Tested-by: George Joseph <george.joseph at fairview5.com>



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