14 Jan
2003
14 Jan
'03
8:19 a.m.
Jiri Kuthan wrote:
At 01:46 PM 1/13/2003, Maxim Sobolev wrote:
I'm not sure what you mean by adjusting to your particular needs. If that means
that you want to process only "some" replies belonging to some particular
transactions, you may want to do the following things:
- use TM, as you need to correlate replies with requests
- use setflag during request processing to label transactions which
shell get a specific handling
- register a callback, from which you apply the special handling to
replies belonging to requests, that were previously marked
That's how accounting module works, for example. Interesting transactions are
labeled, and if a reply arrives, it is processed by the accounting logic only
if the label was set.
This is fine, but not sufficient, since I need to do a search() on
replies as well to see if the answering side of transaction supports
symmetric signalling, even if the originating one doesn't. It is
necessary for determining if it is safe to add rport and rewrite
Contact (adding rport or rewriting contact for UA that doesn't support
symmetric signalling will break things even if that UA is on a public
IP). Therefore, one way or another I need another routing block for
processing replies conditionally. Labelling will not help much,
because transaction originator, for example, may not support symmetric
signalling, i.e. somebody calls from softphone with real IP to my
nated ata. In this case transaction will not be labelled and reply of
my ata will not be adjusted as it have to.
-Maxim
You can
do this using TM and it's callbacks. TM is transaction module and
you can register callbacks with the module. Among others, there is a callback
that will be called upon reception of the final response (200 OK in your
case). In the callback, you can modify the response and rewrite the contact.
I see, but IMO this would be not a generic solution, as I'll have to adjust
the code for my particular needs. What I am looking for is some way to
allow it to be modified by properly constructing config file. Perhaps something
like t_on_negative() could be added, i.e. t_on_positive(): the specified
routing block will be called when the transaction is completed with positive
result but before sending final reply. What do you think?