Hi, I've been following this discussion as I have a similar use case. I have created a PR offering a new function t_reply_by_callid for the module tm to simplify this: https://github.com/OpenSIPS/opensips/pull/2937
Regards, Takeshi On Thu, Oct 20, 2022 at 4:04 PM Bogdan-Andrei Iancu <[email protected]> wrote: > Ivan, > > Actually a simpler approach will be to use t_wait_for_new_branches() > instead of that t_write function, it should do the same trick (postponing > the deletion of the transaction), but without any side effects. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 5-16 Dec 2022, online > https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/ > > On 10/19/22 10:21 AM, Ryzhik Ivan wrote: > > Sorry, I mean no sleep, i mean async( sleep($var(wait_time)), after_sleep > ); > Regards, Ivan. > > вт, 18 окт. 2022 г. в 14:42, Bogdan-Andrei Iancu <[email protected]>: > >> Hi, >> >> yes, call it before ending the REQUEST route. I'm 100% the transaction is >> not deleted before the end of the route. And try to use the unix sock >> flavor for the function, not the fifo one. >> >> DO NOT use the sleep, you will block your whole opensips. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Bootcamp 5-16 Dec 2022, online >> https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/ >> >> On 10/17/22 11:56 AM, Ryzhik Ivan wrote: >> >> Hi, did you mean that i must call t_write_req once before REQUEST_ROUTE >> is finished? In this case the transaction was removed. >> "even if you do not have to actually write anything to outer world - >> just fake it." - i must use fifo and i must read data from it, in else >> we got: >> ERROR:tm:write_to_fifo: nobody listening on [/tmp/moh.fifo] fifo for >> reading! >> ERROR:tm:t_write_req: write_to_fifo failed >> And last question is may I use sleep(20) at the end of route to keep >> transaction? or can i use modparam("tm", "wt_timer", 20)? >> Regards, Ivan >> >> пн, 17 окт. 2022 г. в 09:38, Bogdan-Andrei Iancu <[email protected]>: >> >>> Hi Ryzhik, >>> >>> Right, the transaction must be forced to stay until you are done with a >>> final reply. Unfortunately there is no clear way to do this from script >>> (this may be subject of further small improvements), but you can try taking >>> advantage of the `t_write_req` [1] for this purpose, even if you do not >>> have to actually write anything to outer world - just fake it. >>> >>> >>> [1] >>> https://opensips.org/html/docs/modules/3.2.x/tm.html#func_t_write_req >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 10/13/22 2:45 PM, Ryzhik Ivan wrote: >>> >>> Hi. >>> One more question. >>> Everything works fine except the transaction was deleted after 15 >>> sec after the initial route was finished. >>> on INVITE i last do t_reply_with_body(183, "Session progress", ...) and >>> than exit; >>> >>> on end route log : >>> >>> 2022-10-13T10:58:01.994598+00:00 DBG:tm:_reply_light: reply sent out. >>> buf=0x7f558a087d98: SIP/2.0 1..., shmem=0x7f5549797470: SIP/2.0 1 >>> 2022-10-13T10:58:01.994676+00:00 DBG:tm:_reply_light: finished >>> >>> 2022-10-13T10:58:01.995835+00:00 DBG:tm:do_t_cleanup: transaction >>> 0x7f5549793b18 already updated! Skipping update! >>> 2022-10-13T10:58:01.996020+00:00 DBG:tm:cleanup_uac_timers: RETR/FR >>> timers reset >>> 2022-10-13T10:58:01.996202+00:00 *DBG:tm:insert_timer_unsafe: [2]: >>> 0x7f5549793b98 (12)* >>> 2022-10-13T10:58:01.996317+00:00 * DBG:tm:t_unref: UNREF_UNSAFE: >>> [0x7f5549793b18] after is 0* >>> 2022-10-13T10:58:01.996488+00:00 DBG:core:destroy_avp_list: destroying >>> list (nil) >>> 2022-10-13T10:58:01.996673+00:00 DBG:core:receive_msg: cleaning up >>> >>> 2022-10-13T10:58:07.651091+00:00* DBG:tm:timer_routine: timer >>> routine:2,tl=0x7f5549793b98 next=(nil), timeout=12* >>> 2022-10-13T10:58:07.651332+00:00 DBG:tm:wait_handler: removing >>> 0x7f5549793b18 from table >>> 2022-10-13T10:58:07.651425+00:00 DBG:tm:delete_ce*ll: delete >>> transaction 0x7f5549793b18* >>> 2022-10-13T10:58:07.651513+00:00 DBG:tm:wait_handler: done >>> >>> Can you tell me how I can i fix this? Transaction marked safe for >>> deletion... >>> Regards, Ivan >>> >>> ср, 12 окт. 2022 г. в 13:11, Bogdan-Andrei Iancu <[email protected]>: >>> >>>> Perfect !!! >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 10/12/22 1:09 PM, Ryzhik Ivan wrote: >>>> >>>> I found a solution. hex strings are reversed). >>>> Thank you very much! >>>> >>>> ср, 12 окт. 2022 г. в 12:59, Ryzhik Ivan <[email protected]>: >>>> >>>>> and one more research: $T_id returns hex encoded label.hashid >>>>> but my attempts failed: >>>>> got $T_id = 6545e285.3fe4 >>>>> Send: {"jsonrpc": "2.0", "method": "t_reply", "id": 1, "params": >>>>> {"code": "487", "reason": "Terminating", "trans_id": "16356:1699078789", >>>>> "to_tag": "<null>"}} >>>>> Got: b'{"jsonrpc":"2.0","error":{"code":404,"message":"Transaction not >>>>> found"},"id":1}' >>>>> >>>>> >>>>> ср, 12 окт. 2022 г. в 11:13, Ryzhik Ivan <[email protected]>: >>>>> >>>>>> Thank you, Bogdan. >>>>>> I got stuck with tm documentation. >>>>>> 1) MI t_reply command has named parameters, ok, no problem. >>>>>> 2) trans_id - transaction identifier (has the hash_entry:label >>>>>> format) - what is this? if i use $T_id i got reply "Invalid trans_id". >>>>>> 3) Where can I get to_tag from script level on initial invite? >>>>>> ... >>>>>> t_reply_with_body(183, "Session progress", >>>>>> $(var(body){re.subst,$var(re)}) ); >>>>>> avp_db_query("insert into moh (callid, timeout, tid,totag) >>>>>> values ('$ci', $var(wait_time), '$T_id', '??????')"); >>>>>> ... >>>>>> >>>>>> Regards, Ivan. >>>>>> >>>>>> вт, 11 окт. 2022 г. в 12:35, Bogdan-Andrei Iancu <[email protected] >>>>>> >: >>>>>> >>>>>>> Hi Ivan, >>>>>>> >>>>>>> you can use timer_route, but as there is no way to send a reply for >>>>>>> a particular transaction from script level (only to the currently >>>>>>> processed >>>>>>> request), you will have to trigger the MI cmds from the timer route, >>>>>>> which >>>>>>> is a bit hackish .... >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bogdan-Andrei Iancu >>>>>>> >>>>>>> OpenSIPS Founder and Developer >>>>>>> https://www.opensips-solutions.com >>>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>>>> >>>>>>> On 10/11/22 11:47 AM, Ryzhik Ivan wrote: >>>>>>> >>>>>>> Hi, Bogdan! >>>>>>> What d' you think, can we use timer_route instead of an external >>>>>>> script? >>>>>>> Regards, Ivan. >>>>>>> >>>>>>> пн, 10 окт. 2022 г. в 17:04, Bogdan-Andrei Iancu < >>>>>>> [email protected]>: >>>>>>> >>>>>>>> Hi Ryzhik, >>>>>>>> >>>>>>>> Without a t_relay() it makes not much sense to have an dialog >>>>>>>> structure at all - the dialog module in opensips is actually design for >>>>>>>> proxied calls, not for UAC calls. >>>>>>>> >>>>>>>> IMO, you should keep it a transaction level, by sending replies >>>>>>>> back only. When getting the INVITE, put its call-id into a DB table (to >>>>>>>> keep only the "active" session) together with a lifetime / expiration >>>>>>>> time. >>>>>>>> When getting a CANCEL, update the table (set lifetime to 0), to know >>>>>>>> it is >>>>>>>> terminated. And use an simple external script that keeps scanning the >>>>>>>> DB >>>>>>>> for (1) sending 487 Terminated via MI if the record has 0 lifetime or >>>>>>>> (2) >>>>>>>> send a 408 Timeout via MI if the lifetime exceeded. >>>>>>>> In a similar way you can handle the BYE - send back 200OK for the >>>>>>>> BYE and set 0 in lifetime, to send a 487 canceled back >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Bogdan-Andrei Iancu >>>>>>>> >>>>>>>> OpenSIPS Founder and Developer >>>>>>>> https://www.opensips-solutions.com >>>>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>>>>> >>>>>>>> On 10/10/22 4:33 PM, Ryzhik Ivan wrote: >>>>>>>> >>>>>>>> Hello! >>>>>>>> My opensips version is 3.1 with tm,dialog and rtpengine modules. >>>>>>>> On incoming INVITE i'm creating an early dialog with 183 replies >>>>>>>> and i'm playing audio to caller with rtpengine, no t_relay() on this >>>>>>>> step, >>>>>>>> OS is acting as UAS endpoint. >>>>>>>> If the caller cancels the invite with a CANCEL message - all works >>>>>>>> great. >>>>>>>> But some users terminate dialog with BYE message. >>>>>>>> 1) on BYE with to-tag OS can't find dialog with match_dialog(), >>>>>>>> because to-tag presents. >>>>>>>> 2) if i use load_dialog_ctx($ci) - it is possible to handle BYE. >>>>>>>> 3) in early dialog termination with BYE we also need to send final >>>>>>>> response to the INVITE transaction. >>>>>>>> >>>>>>>> Maybe I did something wrong, but I can't handle the final response >>>>>>>> to INVITE in this case. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing >>>>>>>> [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
