[OpenSIPS-Users] Create and send a 180 reply messsage

Bogdan-Andrei Iancu bogdan at opensips.org
Mon Oct 21 12:03:58 UTC 2024


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 
> <mayamatakeshi at gmail.com> wrote:
>
>
>
>     On Sun, Oct 20, 2024 at 11:38 PM M S <medeanwz at gmail.com> 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
>     Users at lists.opensips.org
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20241021/f2891769/attachment.html>


More information about the Users mailing list