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 <bog...@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
    <bog...@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
        <mayamatake...@gmail.com> wrote:



            On Sun, Oct 20, 2024 at 11:38 PM M S
            <medea...@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@lists.opensips.org
            http://lists.opensips.org/cgi-bin/mailman/listinfo/users


        _______________________________________________
        Users mailing list
        Users@lists.opensips.org
        http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to