trying to understand the E_DLG_STATE_CHANGED

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

trying to understand the E_DLG_STATE_CHANGED

Khalil Khamlichi
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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"
1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"
1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand the E_DLG_STATE_CHANGED

Răzvan Crainea-2
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

Best regards,
Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com
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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"
1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"
1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand the E_DLG_STATE_CHANGED

Khalil Khamlichi
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 <[hidden email]> 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

Best regards,
Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com
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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"
1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"
1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand the E_DLG_STATE_CHANGED

robert

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:: [hidden email]:5060

        from_uri:: sip:[hidden email]

        to_uri:: sip:[hidden email]: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:[hidden email]] On Behalf Of Khalil Khamlichi
Sent: Tuesday, September 19, 2017 8:54 AM
To: OpenSIPS users mailling list <[hidden email]>
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 <[hidden email]> 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

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"

1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"

1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 



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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand the E_DLG_STATE_CHANGED

Khalil Khamlichi
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 <[hidden email]> 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:: 28456fb41ba510f57257de424e73eb[hidden email]:5060

        from_uri:: sip:[hidden email]

        to_uri:: sip:[hidden email]: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:[hidden email]] On Behalf Of Khalil Khamlichi
Sent: Tuesday, September 19, 2017 8:54 AM
To: OpenSIPS users mailling list <[hidden email]>
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 <[hidden email]> 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

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"

1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"

1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 



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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trying to understand the E_DLG_STATE_CHANGED

robert

Glad your other solution works, but just wanted to mention other approach in case people don’t want to setup and store CDR data.  Two more notes, the solution I suggested would be best if you used event listener that is a separate daemon than is subscribed to events rather than polling.  Also SIP OK (200) does not always mean a call is established. For example, can be returned after a CANCEL, but I assume you are filtering based on INVITE.

 

Robert

 

From: Users [mailto:[hidden email]] On Behalf Of Khalil Khamlichi
Sent: Tuesday, September 19, 2017 4:10 PM
To: OpenSIPS users mailling list <[hidden email]>
Subject: Re: [OpenSIPS-Users] trying to understand the E_DLG_STATE_CHANGED

 

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 <[hidden email]> 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:: [hidden email]

        from_uri:: <a href="sip:opensips@XX.XXX.XX.XX">sip:opensips@...

        to_uri:: <a href="sip:7800@XX.XX.XX.XX:5060">sip:7800@...:5060

        caller_tag:: as7e7bed90

        caller_contact:: <a href="sip:ZZZ@">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:: <a href="sip:YYY@">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:[hidden email]] On Behalf Of Khalil Khamlichi
Sent: Tuesday, September 19, 2017 8:54 AM
To: OpenSIPS users mailling list <[hidden email]>
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 <[hidden email]> 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

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

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] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,1,3,<null>,<null>"

1505503997.524535 [0 127.0.0.1:39762] "PUBLISH" "serv1" "fetch_event_params=3917,339471624,3,4,<null>,<null>"

1505504018.809746 [0 127.0.0.1:39840] "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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 

 


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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 



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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users