Timeout Session Signalling ( -n ) not Working

[hamidrhashmi]

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 timeout information after five seconds on netcat listening port 9000 instead i receive an error on logs

ERR:rtpp_command_ul_handle:123@abc: invalid socket name tcp:127.0.0.1:9000

[hamid-elaosta]

I too have this issue. It seems that rtpproxy notify does not work unless using a unix socket. Of course, this is not an option of the signalling server and rtpproxy are on different machines.

[razvancrainea]

@hamidrhashmi can you try sending the socket without tcp:, like 127.0.0.1:9000?

[sobomax]

Hamid, which version are you using? Seems to be doing the right thing in the latest master version:

[sobomax@van01 ~/projects/rtpproxy]$ ./src/rtpproxy_debug -f -s udp: 127.0.0.1:22222 -l 192.168.23.43 -m 10000 -M 10040 -n tcp:127.0.0.1:9000 -T 5 -d DBUG -b target_pfreq = 200.000000 23 Nov 12:49:54.906/GLOBAL/rtpproxy[87469]: rtpproxy started, pid 87469 23 Nov 12:49:54.907/GLOBAL/rtpproxy[87469]: can't open pidfile for writing: Permission denied 23 Nov 12:50:25.100/GLOBAL/rtpproxy[87469]: received command "1543006225 U 123@abc 10.0.0.2 5000 some_to_tag from_tag tcp:127.0.0.1:9000 foobar1\n" 23 Nov 12:50:25.100/GLOBAL/rtpproxy[87469]: new IPv4/IPv4 session 123@abc, tag some_to_tag requested, type strong 23 Nov 12:50:25.100/123@abc/rtpproxy[87469]: new session on IPv4 port 10000 created, tag some_to_tag 23 Nov 12:50:25.100/123@abc/rtpproxy[87469]: setting timeout handler 23 Nov 12:50:25.101/123@abc/rtpproxy[87469]: pre-filling caller's RTP address with 10.0.0.2:5000 23 Nov 12:50:25.101/123@abc/rtpproxy[87469]: pre-filling caller's RTCP address with 10.0.0.2:5001 23 Nov 12:50:25.101/GLOBAL/rtpproxy[87469]: sending reply "10000 192.168.23.43\n" 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: session timeout 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped, 0 ignored 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped, 0 ignored 23 Nov 12:50:30.995/GLOBAL/rtpproxy[87469]: connecting timeout socket 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: session on ports 10000/0 is cleaned up 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: RTP stream from callee: SSRC=NONE, ssrc_changes=0, psent=0, precvd=0, plost=0, pdups=0 23 Nov 12:50:30.995/123@abc/rtpproxy[87469]: RTP stream from caller: SSRC=NONE, ssrc_changes=0, psent=0, precvd=0, plost=0, pdups=0 23 Nov 12:50:30.995/GLOBAL/rtpproxy[87469]: can't connect to timeout socket: Connection refused 23 Nov 12:50:30.995/GLOBAL/rtpproxy[87469]: unable to send timeout notification

-Max

On Fri, Nov 23, 2018 at 12:03 AM Răzvan Crainea [email protected] wrote:

@hamidrhashmi https://github.com/hamidrhashmi can you try sending the socket without tcp:, like 127.0.0.1:9000?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sippy/rtpproxy/issues/77#issuecomment-441174761, or mute the thread https://github.com/notifications/unsubscribe-auth/AANWJshOGxREzqRpDHTZoOWce0k7J045ks5ux6vigaJpZM4VT-WV .

[hamid-elaosta]

The issue I'm seeing seems to be that if the SIP server (Opensips) sends it's bound socket address (which is not the same address rtpproxy will use, rtpproxy throws an error when a cal begins "invalid socket name" along with the name that Opensips sent it.

I run Opensips in Docker container so its rtp proxy notify socket bind address is not useful to rtpproxy, it should ignore that and use the one I provide with -n flag, which is another address, routed to the SIP server bind address.

[sobomax]

@hamid-elaosta the problem there is that we support and actually actively use multiple notification sockets (i.e. multiple OpenSIPS talking to the same RTPProxy instance) so there might be more than one -n supplied. If we would implement it the way you suggested, that would create great ambiguity and mess.

It is also a security feature:

1. You cannot get RTPProxy to notify an arbitrary address of your picking, the world has seen lot of traffic multiplication attacks "thanks" to ntpd and such. ;

2. you cannot send RTPProxy a arbitrary address and expect it to notify somebody. You either know who it should notify and give it proper address, matching one that has been pre-configured, or the request is going to be denied.

What might work for you, however, is that you can possibly investigate using special placeholder %%CC_SELF%% in the -n argument supported since 2.0. And in the notification request itself. So that, if you set -n '%%CC_SELF%%:12345' command line parameter, and make OpenSIPS issue 'tcp:%%CC_SELF:12345' in the RTPPC session request that would cause notification request to be delivered back to the IP where RTPProxy command originated from (from a prospective of the RTPProxy), at TCP port 12345.