Sorry, I mean no sleep, i mean async( sleep($var(wait_time)), after_sleep ); Regards, Ivan.
вт, 18 окт. 2022 г. в 14:42, Bogdan-Andrei Iancu <bog...@opensips.org>: > 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 <bog...@opensips.org>: > >> 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 <bog...@opensips.org>: >> >>> 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 <ryzhik.i...@gmail.com>: >>> >>>> 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 <ryzhik.i...@gmail.com>: >>>> >>>>> 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 <bog...@opensips.org >>>>> >: >>>>> >>>>>> 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 <bog...@opensips.org >>>>>> >: >>>>>> >>>>>>> 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 >>>>>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >> >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users