<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>If the dialog module is working correctly, and the SIP flows are standards-compliant, the dialog module should automatically track all subsequent state changes and remove calls from tracking after a BYE is processed.&nbsp;</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div style="font-size:75%;color:#575757">-- Alex<br><br>--<br>Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard. <br><br>Alex Balashov - Principal<br>Evariste Systems LLC<br>235 E Ponce de Leon Ave<br>Suite 106<br>Decatur, GA 30030<br>Tel: +1-678-954-0670<br>Web: http://www.evaristesys.com/</div></div> <br>Mino Haluz &lt;mino.haluz@gmail.com&gt; wrote:<br>Ok, I'm tagging dialogs with dlg_manage(), but even if the call ends,<br>it still keeps info about this dialog in list "kamctl fifo dlg_list".<br>Should I somehow close the dialog when the BYE transaction is ended ?<br><br>Peter: Thanks for the tip! Really interesting. But I do not<br>understand, why also this list contains the calls that were ended by<br>sipp... Should I search for some mistake in my kamaillio config ?<br><br>On Thu, Sep 13, 2012 at 3:57 PM, Alex Balashov<br>&lt;abalashov@evaristesys.com&gt; wrote:<br>&gt; Really? Interesting, I had no idea. I thought the rtpproxy control protocol<br>&gt; was binary and did not lend itself easily to interaction in this manner.<br>&gt; Thanks for the tip.<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; -- Alex<br>&gt;<br>&gt; --<br>&gt; Sent from my Samsung mobile, and thus lacking in the refinement one might<br>&gt; expect from a proper keyboard.<br>&gt;<br>&gt; Alex Balashov - Principal<br>&gt; Evariste Systems LLC<br>&gt; 235 E Ponce de Leon Ave<br>&gt; Suite 106<br>&gt; Decatur, GA 30030<br>&gt; Tel: +1-678-954-0670<br>&gt; Web: http://www.evaristesys.com/<br>&gt;<br>&gt; Peter Lemenkov &lt;lemenkov@gmail.com&gt; wrote:<br>&gt; 2012/9/13 Alex Balashov &lt;abalashov@evaristesys.com&gt;:<br>&gt;&gt; You can't get it from rtpproxy. You'd really have to use something like<br>&gt;&gt; the<br>&gt;&gt; dialog or htable modules to keep call state and get that from Kamailio.<br>&gt;<br>&gt; On the contrary it's possible (using raw UDP reads/writes):<br>&gt;<br>&gt; work ~: echo "h1u203u03 I\n" | nc -w 1 -u 127.0.0.1 22222<br>&gt; sessions created: 0<br>&gt; active sessions: 0<br>&gt; active streams: 0<br>&gt; work ~:<br>&gt;<br>&gt; Where<br>&gt;<br>&gt; * h1u203u03 is randomly chosen token,<br>&gt; * 127.0.0.1 is the rtpproxy's control IP,<br>&gt; * 22222 is the rtpproxy's control port,<br>&gt; * "-u" means that we're using UDP<br>&gt; * -w 1 is the timeout in seconds to wait before closing nc.<br>&gt;<br>&gt; I can't imagine that someone will use nc in performance testing but I<br>&gt; think it looks like a good start.<br>&gt;<br>&gt; --<br>&gt; With best regards, Peter Lemenkov.<br>&gt;<br>&gt; _______________________________________________<br>&gt; SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>&gt; sr-users@lists.sip-router.org<br>&gt; http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br>&gt;<br></body>