Really? Interesting, I had no idea. I thought the rtpproxy control protocol was binary and did not lend itself easily to interaction in this manner. Thanks for the tip.
-- Alex
-- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/Peter Lemenkov lemenkov@gmail.com wrote:2012/9/13 Alex Balashov abalashov@evaristesys.com:
You can't get it from rtpproxy. You'd really have to use something like the dialog or htable modules to keep call state and get that from Kamailio.
On the contrary it's possible (using raw UDP reads/writes):
work ~: echo "h1u203u03 I\n" | nc -w 1 -u 127.0.0.1 22222 sessions created: 0 active sessions: 0 active streams: 0 work ~:
Where
* h1u203u03 is randomly chosen token, * 127.0.0.1 is the rtpproxy's control IP, * 22222 is the rtpproxy's control port, * "-u" means that we're using UDP * -w 1 is the timeout in seconds to wait before closing nc.
I can't imagine that someone will use nc in performance testing but I think it looks like a good start.
Ok, I'm tagging dialogs with dlg_manage(), but even if the call ends, it still keeps info about this dialog in list "kamctl fifo dlg_list". Should I somehow close the dialog when the BYE transaction is ended ?
Peter: Thanks for the tip! Really interesting. But I do not understand, why also this list contains the calls that were ended by sipp... Should I search for some mistake in my kamaillio config ?
On Thu, Sep 13, 2012 at 3:57 PM, Alex Balashov abalashov@evaristesys.com wrote:
Really? Interesting, I had no idea. I thought the rtpproxy control protocol was binary and did not lend itself easily to interaction in this manner. Thanks for the tip.
-- Alex
-- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/
Peter Lemenkov lemenkov@gmail.com wrote: 2012/9/13 Alex Balashov abalashov@evaristesys.com:
You can't get it from rtpproxy. You'd really have to use something like the dialog or htable modules to keep call state and get that from Kamailio.
On the contrary it's possible (using raw UDP reads/writes):
work ~: echo "h1u203u03 I\n" | nc -w 1 -u 127.0.0.1 22222 sessions created: 0 active sessions: 0 active streams: 0 work ~:
Where
- h1u203u03 is randomly chosen token,
- 127.0.0.1 is the rtpproxy's control IP,
- 22222 is the rtpproxy's control port,
- "-u" means that we're using UDP
- -w 1 is the timeout in seconds to wait before closing nc.
I can't imagine that someone will use nc in performance testing but I think it looks like a good start.
-- With best regards, Peter Lemenkov.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2012/9/13 Mino Haluz mino.haluz@gmail.com:
Peter: Thanks for the tip! Really interesting. But I do not understand, why also this list contains the calls that were ended by sipp... Should I search for some mistake in my kamaillio config ?
Perhaps you don't close them with unforce_rtp_proxy:
if(method=="BYE" || method=="CANCEL"){ unforce_rtp_proxy(); }
I'm using rtpproxy_manage, so I assume unforce_rtp is not needed.
On Thu, Sep 13, 2012 at 4:10 PM, Peter Lemenkov lemenkov@gmail.com wrote:
2012/9/13 Mino Haluz mino.haluz@gmail.com:
Peter: Thanks for the tip! Really interesting. But I do not understand, why also this list contains the calls that were ended by sipp... Should I search for some mistake in my kamaillio config ?
Perhaps you don't close them with unforce_rtp_proxy:
if(method=="BYE" || method=="CANCEL"){ unforce_rtp_proxy(); }
-- With best regards, Peter Lemenkov.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2012/9/13 Alex Balashov abalashov@evaristesys.com:
Really? Interesting, I had no idea. I thought the rtpproxy control protocol was binary and did not lend itself easily to interaction in this manner.
Yep, this command protocol allows us to do tricks like this which is quite helpful for debugging. Unfortunately this particular command ( 'I' and its counterpart 'Ib' ) seems to be broken - it doesn't prepend received random cookie at the beginning of the answer.
Just FYI - I collected some examples of control commands here (just grep for ser_proto:decode):
* https://raw.github.com/lemenkov/erlrtpproxy/master/test/ser_proto_test.erl
and here (which could be even more interesting since it contains an example of a real session - create session, lookup, destroy, get stats, etc):
* https://raw.github.com/lemenkov/erlrtpproxy/master/test/ser_test.erl
Thanks for the tip.
Anytime :)
-
Alex Balashov -
Mino Haluz -
Peter Lemenkov