Hi Takeshi, Thanks for the note here, I will check the PR.
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/22/22 12:53 PM, mayamatakeshi wrote:
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 <https://github.com/OpenSIPS/opensips/pull/2937>Regards, TakeshiOn Thu, Oct 20, 2022 at 4:04 PM Bogdan-Andrei Iancu <bog...@opensips.org <mailto:bog...@opensips.org>> 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 <https://www.opensips-solutions.com> OpenSIPS Bootcamp 5-16 Dec 2022, online https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/ <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 <bog...@opensips.org <mailto: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 <https://www.opensips-solutions.com> OpenSIPS Bootcamp 5-16 Dec 2022, online https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/ <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 <mailto: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 <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 <https://www.opensips-solutions.com> OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ <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 <mailto:bog...@opensips.org>>: Perfect !!! Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com <https://www.opensips-solutions.com> OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ <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 <mailto: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 <mailto: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 <mailto: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 <https://www.opensips-solutions.com> OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ <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 <mailto: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 <https://www.opensips-solutions.com> OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ <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 list Users@lists.opensips.org <mailto:Users@lists.opensips.org> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>_______________________________________________ Users mailing list Users@lists.opensips.org <mailto:Users@lists.opensips.org> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <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