Hello,

the patch to registrar module looks ok, so you can push it as well.

Also the patch to tm seems to touch only a bit existing code, respectively:
- export add_uac()  function - remove its static constraints and adding the prototype to a header file
- keep branch route id in a new field to be used for executing the branch_route for new branches added later

Then it is the new function you added, but it doesn't affect the existing code.

Assuming I got the tm patch right, then it is safe to be pushed as well, with some remarks: the copyright at the top of new added files seems to be taken from other existing files, giving the right to someone else than you, also for an old year. You have to update that and also for the tm code, license for new contributions has to be bsd.

Cheers,
Daniel

On 10/09/14 10:25, Federico Cabiddu wrote:
Hi Daniel and Kamailio developers,
here are the two patches for registrar and tm modules needed by the tsilo module.

Looking forward to hearing your feedback.

Regards,

Federico

On Wed, Sep 10, 2014 at 9:22 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
Hi Federico,

thanks for this contribution! We will grant you write access to the git repository to push and maintain your new module.

I will review the patches for registrar and tm modules. For sake of everyone having a chance to look at them, can you send the patches to this mailing list?

Cheers,
Daniel


On 10/09/14 07:36, Federico Cabiddu wrote:
Hi all Kamailio developers,
I would like to propose a new module that I've written recently, the tsilo module where tsilo stands for "transaction silo" (thanks Daniel for suggesting the name). The module provides the ability to add branches to a transaction that has already been relayed and still hasn't got a final response. It achieves it by storing in an internal table a list of transactions per r-uri. 

The scenarios for which this functionality has been originally though are those in which a user's device is usually not registered on kamailio but, in case of incoming invite, can be "waken up" (and so trigger its registration) by means of mechanisms other than SIP; typically scenarios involving APN, GCM or other push mechanisms.

The module exposes 3 functions to configuration script:

- t_store(): store the current transaction 
- t_append(domain, ruri): append branches to all the transactions existing for "ruri" looking up new contacts in "domain" table
- t_append_to(tindex, tlabel, domain): append branches to transaction identified by tindex and tlabel looking up new contacts in "domain" table

The module depends on tm and registrar module on which some modifications have been done:

registrar: new api function update_to_dset to update the dset without rewriting the r-uri
tm: new api function t_append_branches and some modifications on t_fwd.* to implement it

I hope that this contribution could be useful for the community and I look forward to hearing your feedback, thoughts, suggestions.

Best regards,

Federico Cabiddu 



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany