Hi,
The onreply route is not design to perform any signaling within - its
purpose is to give you access to the incoming replies and to allow you
to eventually modify their headers. This is the reason why you cannot
send a reply from the route.
As a simple workaround, you can use the mi function `t_reply` [1] via
the mi_script module.
[1] https://opensips.org/html/docs/modules/3.4.x/tm.html#mi_t_reply
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 21.10.2024 00:35, M S wrote:
Thank you for your ideas! I considered doing the perl solution but I
wondered if there is a more "native" solution to try first. the idea
to patch t_reply seems legitimate, but you are right about whether it
may need additional changes too, and which leg the reply goes back to
in a reply route, does it go to the one who sent 200? I guess that
needs to be checked but since my system is under load I am a little
hesitant about making big changes, maybe one of Opensips people can
comment too....
On Sun, Oct 20, 2024 at 10:28 PM mayamatakeshi
<[email protected]> wrote:
On Sun, Oct 20, 2024 at 11:38 PM M S <[email protected]> wrote:
Hi list,
I am having a problem that my upstream provider disconnects
the call if my client does not send 180/183 before 200 OK.
At the time of receiving 200 OK (in reply_route) I can check
to see if previously a 180/183 was also sent or not.
My solution is: as soon as I receive a 200 OK from the client,
if 180/183 was not received before, I create a 180 ringing
message and send it to upstream, before passing on 200. Now I
realized that none of the usual methods (send_reply,
sl_send_reply, t_send_reply) work from reply_route, and I have
no idea how to use dlg_send_sequential to send a "180 ringing".
Any ideas would be appreciated.
dlg_send_sequential would not work as it is used to generate a
request.
I think opensips should allow t_reply to work from within
ONREPLY_ROUTE.
Currently it, doesn't:
opensips tm.c:
{"t_reply", (cmd_function)w_pv_t_reply, {
{CMD_PARAM_INT, fixup_reply_code, 0},
{CMD_PARAM_STR, 0, 0}, {0,0,0}},
REQUEST_ROUTE | FAILURE_ROUTE},
But kamailio which, as opensips, inherited the tm foundation from
openser allows it:
{"t_reply", w_t_reply, 2, fixup_t_reply, 0,
REQUEST_ROUTE | ONREPLY_ROUTE | FAILURE_ROUTE},
So you could try patching opensips t_reply by adding the
ONREPLY_ROUTE flag till this is allowed in opensips (I'm not sure
if it will work as extra changes in code might be needed).
Alternatively, you could call a function in a perl/lua/python
module to change the "200 OK" with "180 Ringing", remove the top
Via Header (beware that the Via headers might be coalesced into a
single one), remove the body and use a raw socket to send the packet:
(ref:
https://opensips.org/html/docs/modules/3.5.x/perl.html#func_perl_exec)
Obs: I assume the language module inherits the limitations from
the route it is being executed on, so I would not expect:
$m->sl_send_reply("180", "Trying");
to work, but you could try to see what happens.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
