Hi Robert, Thanks for your idea, the only issue is that it involves polling the server and I don't want to go that path. actually with my solution the results were quite good and precise, the reason is that a 200 OK is always an established call and an E_ACC_CDR is always an end to a successful call and never to another status of a call, and on both places we have access to all dialog variables and/or acc_extra variables.
Again, Thanks for your idea. On Tue, Sep 19, 2017 at 3:26 PM, Mundkowsky, Robert <[email protected]> wrote: > Using E_DLG_STATE_CHANGED to keep a count of active dialogs seems > reasonable. If you want the callerID, you would use the “hash_id of > dialog” and the “b= hash_entry of dialog” to look up the dialog in the > table and get more info like the callerid. You use the dlg_list command to > look up data in the table. I don’t know if you could do this in the > openSIPS config file alone, you likely have to have a script that is called > to query the table, parse the data you want, …. > > > > Looks like the key is of the form: > > > > <hash_id>:< hash_entry> like “1527:459551172” below > > > > Example of details from dlg_list: > > > > rmundkowsky: ~$ /export/Apps/opensips/sbin/opensipsctl fifo dlg_list > > database engine 'MYSQL' loaded > > Control engine 'FIFO' loaded > > entering fifo_cmd dlg_list > > dialog:: hash=1527:459551172 dialog_id=6558874612164 > > state:: 3 > > user_flags:: 0 > > timestart:: 1505826879 > > datestart:: 2017-09-19 09:14:39 > > timeout:: 1505848479 > > dateout:: 2017-09-19 15:14:39 > > callid:: [email protected]:5060 > > from_uri:: sip:[email protected] > > to_uri:: sip:[email protected]:5060 > > caller_tag:: as7e7bed90 > > caller_contact:: sip:ZZZ@ XX.XX.XX.XX:5060 > > callee_cseq:: 0 > > caller_route_set:: > > caller_bind_addr:: udp:XX.XX.XX.XX:5060 > > caller_sdp:: > > CALLEES:: > > callee:: > > callee_tag:: 255851520 > > callee_contact:: sip:YYY@ > XX.XX.XX.XX:5090;transport=udp > > caller_cseq:: 102 > > callee_route_set:: > > callee_bind_addr:: udp: XX.XX.XX.XX:5060 > > callee_sdp:: > > FIFO command was: > > :dlg_list:osips_rply_e7e14d04 > > > > Robert > > > > *From:* Users [mailto:[email protected]] *On Behalf Of *Khalil > Khamlichi > *Sent:* Tuesday, September 19, 2017 8:54 AM > *To:* OpenSIPS users mailling list <[email protected]> > *Subject:* Re: [OpenSIPS-Users] trying to understand the > E_DLG_STATE_CHANGED > > > > Hi Răzvan, > > > > Thanks for your answer. > > > > I ended up using onreply_route and checking if ($rs == "200") to increment > connect_calls and then event_route[E_ACC_CDR] to decrement > connected_calls. > > > > multiple local tests are giving expected behavior, will need to test on > production to confirm though. > > > > Thanks a lot for your help. > > > > On Mon, Sep 18, 2017 at 9:47 AM, Răzvan Crainea <[email protected]> > wrote: > > Hi, Khalil! > > To be honest, I think this event was initially made to be used with the MI > dlg_end_dlg command, which only terminates a dialog. However, you could run > 'opensipsctl fifo dlg_list' and match the hash_id and hash_entry against > the returned values, and then identify the callid. > > If you would also like to receive the callid in the event, please open a > feature request[1]. > > [1] https://github.com/OpenSIPS/opensips/issues > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOpenSIPS%2Fopensips%2Fissues&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=FECgaKsHHG0bJ27vaswQ3Kv8mIs%2B%2FEIWA0BhlexCT5w%3D&reserved=0> > > Best regards, > > Răzvan Crainea > > OpenSIPS Developer > > www.opensips-solutions.com > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.opensips-solutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=FfiJVQW07fhERDG5EmsgIAKTnzaXJ5B4Hiq%2BK69mtXk%3D&reserved=0> > > On 09/15/2017 10:46 PM, Khalil Khamlichi wrote: > > Hi everyone, > > > > I am trying to understand dialog module eventing system. > > > > I have added this route : > > > > > > event_route[E_DLG_STATE_CHANGED] { > > > > fetch_event_params("$avp(a);$avp(b);$avp(c);$avp(d);$avp(e);$avp(f)"); > > > > cache_raw_query("redis:0", "PUBLISH serv1 fetch_event_params=$avp(a),$ > avp(b),$avp(c),$avp(d),$avp(e),$avp(f)", "$avp(res)"); > > > > } > > > > > > so for each event I can watch an entry > > > > 1505503997.413642 [0 127.0.0.1:39734 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A39734&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=FoTX7qqZpovv0ja%2FlUUhMA7FvyZZOe%2BGTfL3ctrTf4c%3D&reserved=0>] > "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>" > > 1505503997.524535 [0 127.0.0.1:39762 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A39762&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=vUKqSbhQPhk1%2BL0RxMbzh9vXBVGVXh0EVc0B2Y3UnQA%3D&reserved=0>] > "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>" > > 1505504018.809746 [0 127.0.0.1:39840 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A39840&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=eIDCVWWXFKxhVM7omnhPa%2B4ndAMIMz40F5vei%2F3GwVw%3D&reserved=0>] > "PUBLISH" "serv1" "fetch_event_params=3917,339471624,4,5,<null>,<null>" > > > > > > I understand that > > > > a = hash_id of dialog > > b= hash_entry of dialog > > c = old_state > > d = new_state > > e & f = do not exist and here just to prove that they do not exist. > > > > but I don't understand how to use the information of a & b to track > dialogs ? if there a function that when fed those parameters gives us > callid for example ? > > > > Thanks in advance. > > > > Kkh > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.opensips.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fusers&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=Rp8lS4VMOZ%2BT1mYLh6TLJg1o5zQ3QMIHpr2IZCs0GSo%3D&reserved=0> > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.opensips.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fusers&data=02%7C01%7Crmundkowsky%40ets.org%7Cf9c8eab9cdfd4fae4aa608d4ff5dedd6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636414226270892544&sdata=Rp8lS4VMOZ%2BT1mYLh6TLJg1o5zQ3QMIHpr2IZCs0GSo%3D&reserved=0> > > > > ------------------------------ > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > Thank you for your compliance. > ------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
