10 Sep
2014
10 Sep
'14
11:50 a.m.
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(a)gmail.com <mailto: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:
--
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
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(a)lists.sip-router.org <mailto: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://twitter.com/#%21/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(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev