[sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?

[Lucian Balaceanu]

Hello Daniel,

I must admit I only saw your mail last Friday. Until the 10th of October 
I was also on vacation. I know that you actually committed some of the 
changes together with your comments on the 12th this month.

I don't know if we can consider the topic of the patch closed. As far as 
I understand, the state-full replies have not been addressed, right? 
(There should be a change in the t_reply.c) I followed the code to the 
relay_reply but I did not yet come to find the send function. Should I 
pursue further?

Thank you,
Lucian Balaceanu

> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141027/9174488c/attachment.html>