[test-results] [Bamboo] Asterisk - Team Branches > Pimp My SIP > #129 has FAILED. Change made by Mark Michelson.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - Team Branches > Pimp My SIP > #129 failed.
-----------------------------------------------------------------------
Code has been updated by Mark Michelson.
2/2 jobs failed, no tests found.

http://bamboo.asterisk.org/browse/ASTTEAM-PIMPMYSIP-129/


--------------
Failing Jobs
--------------
  - Asterisk 1.8 CentOS 6 32-Bit (CentOS 6): No tests found.
  - Asterisk 1.8 CentOS 6 64-Bit (CentOS 6): No tests found.



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

>Merge pool_shark2 branch.
>
>Copied from the reviewboard description:
>
>* The ast_sip_work structure and some of its methods have been removed in
>favor of the generic task serializer.
>
>* A PJSIP module, the message distributor, has been added. This module has a
>high priority and gets called into after the PJSIP transport layer but before
>the PJSIP transaction layer. The distributor is used as a means of moving an
>incoming message from a PJSIP thread into a SIP servant thread. Then from the
>SIP servant thread, the message bubbles up through the PJSIP transaction layer,
>PJSIP dialog layer, and any relevant PJSIP modules that Asterisk has registered.
>This means that any PJSIP module that registers itself at the transaction layer
>or higher will have all of its incoming SIP messages already in a SIP servant
>thread when called back. Unless they need to serialize operations, they do not
>need to do any special processing to ensure the incoming message is handled in a
>specific thread. A good example of this is what the SIP OPTIONS handler does in
>this set of changes.
>
>* Two new PJSIP modules have been added above the dialog layer. The endpoint
>module and the authenticator module are responsible for doing endpoint lookups
>and authentication for incoming requests. The placement of these modules means
>that they are only ever called into for out-of-dialog requests. This means that
>on an initial INVITE, or on a REGISTER, or on an OPTIONS request, or any other
>out-of-dialog request, the application-layer modules do not need to worry about
>endpoint lookup or authentication since that is done already for them. If they
>need the endpoint, they can call ast_pjsip_rdata_get_endpoint(). For dialog-
>forming application modules, they will want to save off the endpoint that the
>endpoint module finds since the endpoint will not be looked up again on in-
>dialog requests, meaning they will not be able to call
>ast_pjsip_rdata_get_endpoint().
>
>* Modules that were passing incoming messages off to servants no longer need to
>do this, so they have been changed not to. So the session module and options
>module now handle incoming requests in-line rather than pushing them to a
>servant thread.
>
>* Since it no longer makes sense to pre-allocate a serializer before an
>ast_sip_session, the functions for allocating SIP sessions has been changed not
>to take a serializer any more. Instead, the allocation routine creates its own.
>In addition, the behavior of endpoint references has changed from how it
>previously was. Now allocating a session results in the endpoint reference count
>increasing by one rather than having the session inherit the reference passed
>into it. This makes endpoint reference handling much cleaner, especially in the
>session module.
>
>* To assist programmers who want to write PJSIP modules in Asterisk, there is a
>helper method called ast_sip_thread_is_servant() that has been added. It can be
>used to discern if the thread you currently are in is a SIP servant thread. This
>means it is not as necessary to dig into the PJSIP internals to know what type
>of thread you are in when called back. Instead, you can be safe and use this
>function. This function is currently unused though, since there hasn't been a
>need for it yet. This is because all uses of SIP servants where it may be
>questionable what type of thread we are in need to serialize the task anyway.
>
>* Documentation of the SIP threadpool has been updated.
>
>Review: https://reviewboard.asterisk.org/r/2355
>



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