19 Feb
2010
19 Feb
'10
7:24 p.m.
Hi Andrei:
Thanks for the quick response.
So:
onreply_route[1]
{
if (my_function_check("")) {
release_call_onreply("");
Drop;
}
}
The pseudo codes is like:
t=tmb.t_gett();
send_request(method_ACK);
send_request(method_BYE);
reason_code = 488
tmb.t_reply(t->uas.request,reason_code,reason_text);
(Not sure if t_reply can be called here or not.)
The ACK/Bye is sent to U2, 488 is sent to U1,
But the issue is it seems the original 200 OK is forwarded to U1 as
well.
How to avoid it?
You need either to DROP the reply (add drop in the script after your
function), or use the generic onreply_route ( [0] or unnamed).
Anyway you would need to modify t_reply, or it won't work from the
onreply_route (at least not in sr 3.*).
I guess what you mean is : even with drop, this function seems need to
be modified ( since the reply is 200 OK.)
In the tm/t_reply.c->reply_received:
run_top_route(onreply_rt.rlist[t->on_reply], p_msg,
&ctx);
if ((ctx.run_flags&DROP_R_F) && (msg_status<200)) {
if (unlikely(replies_locked)) {
replies_locked = 0;
UNLOCK_REPLIES( t );
}
goto done;
}
What is the good reason for checking msg_status<200 there?
Kind regards
Min Wang
>
> Or should the Data lumps function be used here to modify the 200
reply
msg instead of
using t_reply here?
No, you won't be able to change the reply code that way.
Andrei