[Serdev] my radius scheme for call transfer and other things

[Jan Janak]

Just for the archives of the list, here is a short description of how
failure_route and reply_route blocks work:

Two additional route sections can be created in the configuration file:
failure_route and reply_route. The two blocks are executed in different
stages during the transaction processing and also process different SIP
messages.

1) failure_route

When a failure_route block is set using t_on_failure, it is called after
the transaction processing logic calculates the final reply that will be
sent upstream, for example:

                                          /------branch1----< timeout
caller <-----(*)--- transaction_logic ---+-------branch2----< 486
                                          \------branch3----< 488

The point where failure_route block is called is marked by (*). That
means failure_route block is called when the final reply calculated by
the transaction logic is negative -- just before sending it upstream.

Actions called from within the failure_route block do not work with the
reply, but with the original request (!). Because at the time of
executing failure_route block the original request is stored in the
shared memory of the transaction context only, it is necessary to create
so called "faked" message in private memory (many actions require the
data structures to be in private memory).

The code of the final negative reply can be checked with t_check_status
function. Replies that were used to calculate the final reply can not be
accessed from failure_route block.

failure_route blocks can be used to perform additional actions on the
original request -- forwarding to voicemail, for example.

2) reply_route

reply_route block is called for each reply that is received by the
transaction module:

                                       /--(*)---branch1----< timeout
caller <-------- transaction_logic ---+---(*)---branch2----< 486
	                               \--(*)---branch3----< 488

(again, (*) mark the places where reply_route blocks are executed).

At the time of calling reply_route block the reply is still in the
private memory so there is no need to create faked messages.

Actions called from reply_route blocks work on replies themselves.

It is possible to check for the status code of replies using this
construct:

if (status=~"2[0-9][0-9]")

----

Given the above, I think that you could execute your checks of Contact
header field in replies from a reply_route block. See, for example,
nathelper/nathelper.c, function fix_nated_contact_f. That function
rewrites also Contact header fields in replies.

  hope that helps, Jan.

On 04-01 12:59, Juha Heinanen wrote:
> Jan Janak writes:
> 
>  >   You are right in the previous thread. I just checked the tm sources
>  >   and in failure_route block you work on the original request (not
>  >   reply).
> 
> that would be ok as long as i can access the reply somehow from the move
> function.
> 
>  >   Maybe onreply_route could be used for this, but I have to check the
>  >   code and mails from Jiri yet.
> 
> anything is ok with me as long as i can process
> t_check_status("301|302"), t_check_status("486"), and
> t_check_status("408").
> 
> -- juha