Module: sip-router Branch: master Commit: b38d9c93207a219bbcbc4ad40886b983a391c90b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b38d9c93...
Author: Hugh Waite hugh.waite@crocodile-rcs.com Committer: Hugh Waite hugh.waite@crocodile-rcs.com Date: Fri Apr 5 14:07:18 2013 +0100
modules/tm: Added branch_failure event route to tm documentation
---
modules/tm/README | 1425 ++++++++++++++++++++------------------- modules/tm/doc/event_routes.xml | 34 + modules/tm/doc/tm.xml | 1 + 3 files changed, 762 insertions(+), 698 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=b38d...
5 apr 2013 kl. 15:13 skrev Hugh Waite hugh.waite@crocodile-rcs.com:
modules/tm: Added branch_failure event route to tm documentation
Thank you for adding this route!
Formatting issue: I don't like the event route doc to come after the module API. We usually have the API docs as the last item.
Architecture/documentation issues:
- Is it really an event route - or does it work as the other T_ON_FAILURE?
- Would it be better to enable a route with t_on_branch_failure(ROUTE_NAME) ?
- What's the architectural difference between an event_route and the other routes triggered by TM?
- Can I do everything I can do in FAILURE_ROUTE in this event route?
- How do I retarget and retransmit a request? The transaction i still open so I can't use t_relay like in failure route, or?
Many questions... :-)
/O
Hi Olle,
On 05/04/2013 14:53, Olle E. Johansson wrote:
modules/tm: Added branch_failure event route to tm documentation
Thank you for adding this route!
You're welcome!
Formatting issue: I don't like the event route doc to come after the module API. We usually have the API docs as the last item.
That is easily fixed.
Architecture/documentation issues:
Is it really an event route - or does it work as the other T_ON_FAILURE?
Would it be better to enable a route with t_on_branch_failure(ROUTE_NAME) ?
What's the architectural difference between an event_route and the other routes triggered by TM?
This branch-failure route has been implemented as an event route after discussion with Daniel. (See http://lists.kamailio.org/pipermail/sr-dev/2013-March/019191.html). As a result, you cannot specify multiple named routes and enable them with a t_on_branch_failure() function. There can only be one route and it is enabled when it is defined.
- Can I do everything I can do in FAILURE_ROUTE in this event route?
No. This event_route uses a new route type (a new BRANCH_FAILURE_ROUTE flag internally) which means functions and PVs are limited to ones that have this flag set. So far, I have enabled the functions that are required to enable outbound flow retries. Since this route is run in a very similar way to the failure_route, it is likely that most functions that work in a FAILURE_ROUTE will also work in a BRANCH_FAILURE_ROUTE just by enabling the flag, but it is a matter of whether they are appropriate for this route.
- How do I retarget and retransmit a request? The transaction i still open so I can't use t_relay like in failure route, or?
I wrote this with the intention of enabling outbound flow retries. This is done by running t_next_contact_flow() and t_relay(), just like you would in a failure_route. This creates a new branch and prevents the failure_route from being run for this response.
Many questions... :-)
Peter and I will be coming up with an kamailio.cfg that enables outbound which will provide a working example, but if you can suggest further details for the README that will help users understand, I will add them.
Regards, Hugh
Hello,
On 4/5/13 5:34 PM, Hugh Waite wrote:
Hi Olle,
On 05/04/2013 14:53, Olle E. Johansson wrote:
modules/tm: Added branch_failure event route to tm documentation
Thank you for adding this route!
You're welcome!
Formatting issue: I don't like the event route doc to come after the module API. We usually have the API docs as the last item.
That is easily fixed.
Architecture/documentation issues:
- Is it really an event route - or does it work as the other
T_ON_FAILURE?
- Would it be better to enable a route with
t_on_branch_failure(ROUTE_NAME) ?
- What's the architectural difference between an event_route and the
other routes triggered by TM?
This branch-failure route has been implemented as an event route after discussion with Daniel. (See http://lists.kamailio.org/pipermail/sr-dev/2013-March/019191.html). As a result, you cannot specify multiple named routes and enable them with a t_on_branch_failure() function. There can only be one route and it is enabled when it is defined.
if I understood right, you can't specify the event_route[tm:branch_failure] per transaction. This is not a limitation of the event_route, you can do it. Just that so far it was used only when enabled.
You can code to do something like:
t_on_branch_failure("myroute");
which should execute following event route in case of branch failure.
event_route[tm:branch_failure:myroute] { ... }
My idea was to avoid adding other event-like routes (even branch_route or failure_route are like this, but we keep them since they were defined like this long time ago), because it is extending the config file language unnecessary.
But you can still develop similar mechanisms as t_on_something() even with event_route. Note that the naming of event routes is not syntactically forced to be modname:xyz, it is just a recommendation that will help relating easier the event route with the module executing it.
Hope now is more clear, or maybe I misunderstood what you added.
Cheers, Daniel
Hi, On 06/04/2013 11:44, Daniel-Constantin Mierla wrote:
This branch-failure route has been implemented as an event route after discussion with Daniel. (See http://lists.kamailio.org/pipermail/sr-dev/2013-March/019191.html).
As a result, you cannot specify multiple named routes and enable them with a t_on_branch_failure() function. There can only be one route and it is enabled when it is defined.
if I understood right, you can't specify the event_route[tm:branch_failure] per transaction. This is not a limitation of the event_route, you can do it. Just that so far it was used only when enabled.
You can code to do something like:
t_on_branch_failure("myroute");
which should execute following event route in case of branch failure.
event_route[tm:branch_failure:myroute] { ... }
Hope now is more clear, or maybe I misunderstood what you added.
I did not realise this was possible as I was learning from other code examples. This was part of my first attempt, so I will try to add this back in soon.
Hugh
On 4/6/13 8:44 PM, Hugh Waite wrote:
Hi, On 06/04/2013 11:44, Daniel-Constantin Mierla wrote:
This branch-failure route has been implemented as an event route after discussion with Daniel. (See http://lists.kamailio.org/pipermail/sr-dev/2013-March/019191.html).
As a result, you cannot specify multiple named routes and enable them with a t_on_branch_failure() function. There can only be one route and it is enabled when it is defined.
if I understood right, you can't specify the event_route[tm:branch_failure] per transaction. This is not a limitation of the event_route, you can do it. Just that so far it was used only when enabled.
You can code to do something like:
t_on_branch_failure("myroute");
which should execute following event route in case of branch failure.
event_route[tm:branch_failure:myroute] { ... }
Hope now is more clear, or maybe I misunderstood what you added.
I did not realise this was possible as I was learning from other code examples. This was part of my first attempt, so I will try to add this back in soon.
OK, at the end you can decide how to specify the event_route to be executed:
t_on_branch_failure("myroute");
or
t_on_branch_failure("tm:branch_failure:myroute");
The first will require to build the full event_route name inside the function to prefix the parameter with "tm:branch_failure:". Otherwise you will lookup the event_route inside the t_on_branch_failure(...) and store only its index in tm branch structure.
Cheers, Daniel