[OpenSIPS-Users] early dialog termination

Bogdan-Andrei Iancu bogdan at opensips.org
Mon Oct 24 15:52:26 UTC 2022


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,
> Takeshi
>
> On Thu, Oct 20, 2022 at 4:04 PM Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto: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  <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
>>     <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>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>     _______________________________________________
>     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>
>
>
> _______________________________________________
> 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/20221024/8c889336/attachment-0001.html>


More information about the Users mailing list