Hi Lucian,
somehow I forgot to follow up on this. But we need to get
sorted out soon, before we release, so it works as expected
with the new version. See more comments inline.
On 17/09/14 18:09, Lucian
Balaceanu wrote:
Hi Daniel,
Please forgive me for my delay in responding to your mail.
Please find attached a second version of the
onsend_route_reply patch (which again has some problems). As
per your previous indications I did the following:
Issue1
From performances point of view, there can be
added a config parameter to enable running of onsend_route
for replies:
onsend_route_reply = 0|1
Following http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters
I have tried to add onsend_route_reply parameter. The code
compiles, but when trying to start kamailio with this
parameter inside, the parsing fails with syntax errors
signaling:
0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse
error in config file kamailio-basic.cfg.4.1, from line
107, column 1 to line 108, column 0: syntax error
0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse
error in config file kamailio-basic.cfg.4.1, from line
107, column 1 to line 108, column 0:
ERROR: bad config file (2 errors)
The issue is:
+<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
+ yy_number_str=yytext; return NUMBER; }
It should be:
+<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
+ yy_number_str=yytext; return ONSEND_RT_REPLY; }
Issue2
#define onsend_enabled(rtype)
(onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0)
That is to say you see it best to take the chek for
onsend_rt.list[DEFAULT_RT] from inside run_onsend() function
and call this onsend_enabled(...) before the run_onsend()?
This is to detect whether the onsend_route should be executed
for SIP replies. The condition being:
- if is a sip reply and onsend_route is set and the
onsend_route_reply parameter is 1
Issue3
On the other hand, is onsend_route also
executed for local requests? I had in mind it is only for
received requests that are forwarded ... Iirc, on
onsend_route, the sip message is the one received, the
outgoing content being accessible via $snd(buf).
I agree with you with taking out the locally generated
requests and only left the run_onsend call in
do_forward_reply function (inside forward.c).
Could you point me to the reply relaying function that is
called for state-full processing?
Stateful processing for replies is mainly done in t_reply.c
from tm module. At some point there should be a send buffer
function call.
Cheers,
Daniel
Thank you and sorry again for my late answer,
Lucian
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda