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

[Bogdan-Andrei Iancu]

Hi,

Indeed, a funny un-consistency that has to be fixed. For now you can do 
$(T_id{re.subst,/\./:/g}) instead of simple $T_id

Regards,

Bogdan-Andrei Iancu

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

On 23.10.2024 02:24, M S wrote:
> Hi Bogdan,
> I used T_id and it responds 
> with: "error":{"code":400,"message":"Invalid trans_id"}
> Also the documentation says trans_id should be in hash:label format 
> but $T_id is like 38151c86.ed7b
> Please advise.
>
> Thank you
>
> On Mon, Oct 21, 2024 at 2:23 PM Bogdan-Andrei Iancu 
> <bogdan at opensips.org> wrote:
>
>     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/20241025/e5943cc7/attachment.html>