[OpenSIPS-Users] early dialog termination

Bogdan-Andrei Iancu bogdan at opensips.org
Tue Oct 18 11:42:22 UTC 2022


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 <bogdan at opensips.org 
> <mailto:bogdan at 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
>>     <bogdan at opensips.org <mailto:bogdan at 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.ivan at gmail.com <mailto:ryzhik.ivan at 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.ivan at gmail.com <mailto:ryzhik.ivan at 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
>>>                 <bogdan at opensips.org <mailto:bogdan at 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 <bogdan at opensips.org
>>>>                     <mailto:bogdan at 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 at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>>>                         http://lists.opensips.org/cgi-bin/mailman/listinfo/users  <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20221018/bfafe381/attachment-0001.html>


More information about the Users mailing list