Idle time for each of existing sessions

[fffilimonov]

Can you explain me this? "the proxy tracks idle time for each of existing sessions (i.e. the time within which there were no packets relayed), and automatically cleans up a sessions whose idle times exceed the value specified at compile time (60 seconds by default)."

Is it SESSION_TIMEOUT?

At man page: -T max_ttl Limit the maximum TTL (Time To Live) of outgoing IP packets to the value of max_ttl.

At main.c SESSION_TIMEOUT used as default value for max_ttl : cf->stable->max_ttl = SESSION_TIMEOUT;

And then: case 'T': cf->stable->max_ttl = atoi(optarg);

There is no set TTL of outgoing IP packets using max_ttl. 1) Is it a mistake at man page?

There is no tracking idle time for streams. I checked it with SIPP. 2) Is it a mistake at README?

[sobomax]

I think it's mistake on the manpage. This "TTL" is idle timeout for a session, not TTL of individual packet(s). We will update it accordingly.

-Max

On Tue, Nov 10, 2015 at 6:05 AM, Vadim notifications@github.com wrote:

Can you explain me this? "the proxy tracks idle time for each of existing sessions (i.e. the time within which there were no packets relayed), and automatically cleans up a sessions whose idle times exceed the value specified at compile time (60 seconds by default)."

Is it SESSION_TIMEOUT?

At man page: -T max_ttl Limit the maximum TTL (Time To Live) of outgoing IP packets to the value of max_ttl.

At main.c SESSION_TIMEOUT used as default value for max_ttl : cf->stable->max_ttl = SESSION_TIMEOUT;

And then: case 'T': cf->stable->max_ttl = atoi(optarg);

There is no set TTL of outgoing IP packets using max_ttl. 1) Is it a mistake at man page?

There is no tracking idle time for streams. I checked it with SIPP. 2) Is it a mistake at README?

— Reply to this email directly or view it on GitHub https://github.com/sippy/rtpproxy/issues/36.

Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft

[fffilimonov]

So, according to this changes in manpage, you need to update readme.

[fffilimonov]

And these feature doesn't work. I' tried call without media with default 60 seconds. Do you need dumps or logs? rtpproxy -V 2.0.beta.20150106

[hamidrhashmi]

I am also facing this issue with rtpproxy -v2.0.0 and opensips2.1.1. RTPproxy remove the session after -T seconds but did not notify on notify socket ( -n tcp:127.0.0.1:22229 ).

[jevonearth]

Hi @fffilimonov @hamidrhashmi

I have an update for the man pages on the way. But here's some snippets to get you guys going sooner.

   -T max_ttl
       Specify the RTP inactivity timer. Defaults to 60 seconds.

       If the rtpproxy does not receive any RTP packets for more than max_ttl it will then delete the session.

   -n timeout_socket
       This parameter specifies a permitted notification sockets. The socket should be created by
       another application, preferably before starting rtpproxy.

       Timeout notifications must be enabled by the SIP controller when setting up the session. The SIP
       Controller must specify the timeout_socket, and a notify_tag, which is expected to be an arbitrary string
       that can be used by the SIP controller to identify which session a received time out notification relates
       to.

       If a SIP Controller specifies a notification socket for a session, and that socket is not specified using
       the -n flag, the rtpproxy will not send a notification, and will not produce an error. It will ignore the
       notification request.

       Format of timeout_socket is <type>:<socket>. Following types are supported:

       ·   unix:Connect to UNIX domain socket for sending timeout notifications. In this mode B2BUA and rtpproxy
           must be running on the same host.

           Example: -n unix:/var/run/rtpproxy_timeout.sock

       ·   tcp:Connect to a remote host using TCP/IP for sending timeout notifications. Format of the socket
           parameter in this case is <host>:<port>.

           Example: -n tcp:10.20.30:12345

       There is no default value, notifications are not sent and not permitted unless a value is specified
       explicitly.

To test this out, you can do use the netcat utility, and run the following commands;

Start rtpptoroxy as follows. The -T 5 flag makes it timeout in 5 seconds, useful for testing, not good for the real world. Note that you will want to set -u to your own username

# rtpproxy -ujev -n tcp:127.0.0.1:9000 -T 5

In a different window, start a netcat process listening on tcp port 9000

nc -l 127.0.0.1 9000

Now, use the netcat command to set up a dummy session via the UDP socket;

echo "U 123@abc 10.0.0.2 5000 some_to_tag from_tag tcp:127.0.0.1:9000 foobar1" | nc -U /var/run/rtpproxy.sock
35622

5 seconds after you issue the U command to the socket, you should see the string foobar1 on the console where you have netcat listening on port 9000.

I hope this helps. Please let me know if you get it working, so I can close out this ticket.

[fffilimonov]

Hello! I tried:

# nc -l 127.0.0.1 9000
# netstat -anp |grep 9000
tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      27931/nc            
# rtpproxy -F -n tcp:127.0.0.1:9000 -T 5

after rtpproxy starts:

# netstat -anp |grep 9000
tcp        0      0 127.0.0.1:9000              0.0.0.0:*                   LISTEN      27931/nc            

Then I created session:

# echo "U 123@abc 10.0.0.2 5000 some_to_tag from_tag tcp:127.0.0.1:9000 foobar1" | nc -U /var/run/rtpproxy.sock
57954

At listening nc was noting after 5 sec (and more) nc -l 127.0.0.1 9000 And there was no connection at port 9000

[jevonearth]

Hi @fffilimonov

I copied your steps verbatim, and it works for me.

Can you tell me what version of rtpproxy you are using; rtpproxy -V and what OS/distribution you are running?

Thanks,

[hamidrhashmi]

Hi Jev

I have tried the provided step on my dev environment but no success.

Nov 18 07:12:41 localhost rtpproxy[29387]: INFO:rtpp_command_ul_handle:GLOBAL: new session 123@abc, tag some_to_tag requested, type strong
Nov 18 07:12:41 localhost rtpproxy[29387]: INFO:rtpp_command_ul_handle:123@abc: new session on a port 10000 created, tag some_to_tag
Nov 18 07:12:41 localhost rtpproxy[29387]: ERR:rtpp_command_ul_handle:123@abc: invalid socket name tcp:127.0.0.1:9000
Nov 18 07:12:41 localhost rtpproxy[29387]: INFO:rtpp_command_ul_handle:123@abc: pre-filling caller's address with 10.0.0.2:5000
Nov 18 07:12:46 localhost rtpproxy[29387]: INFO:process_rtp:123@abc: session timeout
Nov 18 07:12:46 localhost rtpproxy[29387]: INFO:remove_session:123@abc: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped
Nov 18 07:12:46 localhost rtpproxy[29387]: INFO:remove_session:123@abc: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped
Nov 18 07:12:46 localhost rtpproxy[29387]: INFO:remove_session:123@abc: session on ports 10000/0 is cleaned up

I first started listening on tcp port 9000

nc -l 127.0.0.1 9000

I have started rtpproxy like

/usr/local/bin/rtpproxy -p /var/run/rtpproxy.pid -u root -F -s udp:127.0.0.1:22222 -l 192.168.26.181 -m 10000 -M 10040 -n tcp:127.0.0.1:9000 -T 5 -d DBUG local0 -b

executed the following command

echo "$(date +%s) U 123@abc 10.0.0.2 5000 some_to_tag from_tag tcp:127.0.0.1:9000 foobar1" | nc -u 127.0.0.1 22222

didnt receieved any string on netcat listening port 9000.

System details are

[root@dev-aws-ec2 ~]# lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.7 (Santiago)
Release:    6.7
Codename:   Santiago

RTPproxy Version is

[root@dev-aws-ec2 ~]# rtpproxy -V
2.0.beta.20150106

[fffilimonov]

Hello! At hamidrhashmi log there is:

Nov 18 07:12:41 localhost rtpproxy[29387]: ERR:rtpp_command_ul_handle:123@abc: invalid socket name tcp:127.0.0.1:9000

I tried to start with debug:

rtpproxy -F -n tcp:127.0.0.1:9000 -T 5 -d DBUG:LOG_LOCAL5

And got only one message:

Nov 18 06:06:05 178-238-43-87 rtpproxy[7642]: INFO:main:GLOBAL: rtpproxy started, pid 7642

I'm using:

lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.7 (Final)
Release:    6.7
Codename:   Final
rtpproxy -V
2.0.beta.20150106

I can try to build from sources and check again if needed

[hamidrhashmi]

Yes @fffilimonov, I can see. But what Can I do. I have no directions to move further.