[OpenSIPS-Users] early dialog termination
Bogdan-Andrei Iancu
bogdan at opensips.org
Thu Oct 20 07:01:06 UTC 2022
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
> <mailto: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 <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
>> <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/20221020/92c8453b/attachment-0001.html>
More information about the Users
mailing list