Daniel-Constantin Mierla writes:
> can you give a test to latest master branch? I pushed a patch there.
now also the test case where i set flag 16 works ok. thanks.
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
s
Apologies for this guys. This was our mistake. Thanks Daniel for resolving.
We will test the async replies in master today.
---
This mail was sent using my phone and may be brief, to the point, or
contain typos
---
On 24 Oct 2013 08:17, "Daniel-Constantin Mierla" wrote:
> Hello,
>
> can you give
Hello,
can you give a test to latest master branch? I pushed a patch there.
Cheers,
Daniel
On 10/24/13 7:39 AM, Daniel-Constantin Mierla wrote:
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
in the test where reply is not relayed, i set flag 16:
setflag(16);
then see this:
msg_pars
Hello,
On 10/23/13 8:31 PM, Juha Heinanen wrote:
in the test where reply is not relayed, i set flag 16:
setflag(16);
then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply
processing */
could this explain what is happening?
i have always thought that mess
in the test where reply is not relayed, i set flag 16:
setflag(16);
then see this:
msg_parser.h:#define FL_RPL_SUSPENDED (1<<16) /* for async reply
processing */
could this explain what is happening?
i have always thought that message flags can be freely used in the
script. is it no
Ovidiu Sas writes:
> Do a search for FL_RPL_SUSPENDED and add some DBG probes where is set.
ovidiu,
i already did. the flag is only set in t_suspend.c:
tm$ egrep RPL_SUSP *.c
t_reply.c: if (unlikely(p_msg->flags&FL_RPL_SUSPENDED)) {
t_suspend.c:msg->flags |= FL_RPL_SUSPENDED;
Do a search for FL_RPL_SUSPENDED and add some DBG probes where is set.
There were some enhancements to allow t-suspend for replies:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=16e763c32d7a2b9fc451185e028a90b3be758f65
Regards,
Ovidiu Sas
On Wed, Oct 23, 2013 at 1:54 PM, Juh
Juha Heinanen writes:
> what could cause the flag FL_RPL_SUSPENDED being set and reply being
> suspended?
by reading t_suspend.c, i got the impression that t_suspend() needs to be
called in order to suspend the transaction.
if so, i'm not calling t_suspend() or t_continue() in my config.
was th
i added some INFO calls to t_reply.c:
INFO(" testing suspended\n");
if (unlikely(p_msg->flags&FL_RPL_SUSPENDED)) {
INFO(" skip sending of reply\n");
goto skip_send_reply;
/* suspend the reply (async), no error */
}
INFO("=
Daniel-Constantin Mierla writes:
> It is a bit strange -- can you remove the 'return' (which doesn't do
> anything useful there) to see if that is the cause?
it cannot be the reason, because with exactly same config, some 180s are
relayed. in all tests, the called party is the same and the same
It is a bit strange -- can you remove the 'return' (which doesn't do
anything useful there) to see if that is the cause?
Cheers,
Daniel
On 10/23/13 4:50 PM, Juha Heinanen wrote:
i have been wondering why my proxy is not forwarding 180 ringing reply
to caller that it receives from callee. invi
i compared debug of failing 180 reply to working one and i don't see any
other difference except in working one reply gets relayed:
...
Oct 23 18:07:43 rautu /usr/sbin/sip-proxy[8738]: DEBUG: tm [t_lookup.c:1140]:
t_check_msg(): DEBUG: t_check_msg: msg id=11 global id=11 T end=0xb425e168
Oct 23 1
i have been wondering why my proxy is not forwarding 180 ringing reply
to caller that it receives from callee. invite was forwarded to callee
by t_relay(). proxy does not print any error messages to syslog. the only
thing i get is the message i have in onreply_route:
onreply_route [REPLY] {
13 matches
Mail list logo