[OpenSIPS-Users] early dialog termination
mayamatakeshi
mayamatakeshi at gmail.com
Sat Oct 22 09:53:24 UTC 2022
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 <bogdan at 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
> 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 <bogdan at 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 <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
>>>
>>> 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 <bogdan at 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.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>:
>>>>>
>>>>>> 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
>>>>>> >:
>>>>>>
>>>>>>> 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 <
>>>>>>> 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
>>>>>>>> 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 at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20221022/8e4573a9/attachment-0001.html>
More information about the Users
mailing list