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

[Bogdan-Andrei Iancu]

Yes, correct!

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 21.10.2024 15:22, M S wrote:
> Thank you for your response, I will definitely check that. quick 
> question, is transaction id in there same as $T_id?
>
> On Mon, Oct 21, 2024 at 2:04 PM Bogdan-Andrei Iancu 
> <bogdan at opensips.org> wrote:
>
>     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/8dead956/attachment-0001.html>