Helmut Kuper wrote: Grr - Do it the right way and use Asterisk - doing both RTP proxying (if its even necessary) and call accounting in Asterisk. Jeremy McNamara

Iñaki Baz Castillo wrote: I have provided consulting services for 5 or 6 major VoIP providers that run OpenSER+Asterisk and do RTP and CDRs within Asterisk. The secret is in the sauce. Jeremy McNamara

Hi ! I´m having problem to running RTPPROXY. Please, someone help me ? Logs bellow: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -> SIP Logs Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19438]: WARNING: rtpp_test: can't get version of the RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19438]: WARNING: rtpp_test: support for RTP proxy <udp:200.176.6.90:8899>has been disabled temporarily Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: ERROR: send_rtpp_command: can't send command to a RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: send_rtpp_command(): proxy <udp:200.176.6.90:8899> does not responding, disable it Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: WARNING: rtpp_test: can't get version of the RTP proxy Jan 10 15:45:14 src@sip2 /usr/sbin/openser[19408]: WARNING: rtpp_test: support for RTP proxy <udp:200.176.6.90:8899>has been disabled temporarily - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [openser.cfg] # ------------- !! Nathelper modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # Nathelper with RTPproxy modparam("nathelper", "rtpproxy_sock", "udp:xxx.xxx.xxx.xxx:8899") modparam("nathelper", "rtpproxy_disable_tout", 30) modparam("nathelper", "rtpproxy_tout", 2) modparam("nathelper", "rtpproxy_retr", 10) # ------------- [root@sip2 run]# rpm -qa | grep rtp rtpproxy-0.3-1.fc5 [root@sip2 run]# netstat -axep |grep rtpproxy unix 2 [ ACC ] STREAM LISTENING 8070094 19061/rtpproxy /var/run/rtpproxy.sock [root@sip2 run]# ls -al rtpproxy.sock srwxr-xr-x 1 root root 0 Jan 10 15:44 rtpproxy.sock [root@sip2 run]# ps -aux | grep rtp Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ root 19061 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy root 19080 0.0 0.0 2532 344 ? Ss 15:44 0:00 /usr/bin/rtpproxy -l xxx.xxx.xxx.xxx -s udp:xxx.xxx.xxx.xxx 8899 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I think I was too fast there. On Thu, 2008-01-10 at 19:19 +0100, Jerome Martin wrote: Your netstat is the primary reason to make me believe rtpproxy was not launched with proper parameters. You would not catch the udp socket rtpproxy uses with the netstat options you provided, but here it seems your running proxy is waiting for control on a unix socket. And rtpproxy cannot listen both on udp AND unixsocket. You need to choose udp or unixsocket both in openser.cfg and in rtpproxy commandline. Are you sure the ps and the netstat are from the same machine ? What does cat /proc/19080/cmdline | tr "\0" "\n" gives you ? Would you by chance have a second -s option after the first one, truncated by ps, which would be taken into account instead of the udp socket ? That would explain your netstat result. In fact, command line syntax for -s option is udp:ip:port. If you omit the ":" between ip and port, there will be no warning, and rtpproxy will listen (for the original version, dunno for fedora versions) on port 22222. But the behavior might be different on your version. Note that I cannot be 100% sure that you got that one wrong here because indead, even if you use the proper syntax, rtpproxy does not report the ":" in the commandline" -- Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin(a)longphone.fr Web : www.longphone.com <http://www.longphone.com>

On Thu, 2008-01-10 at 18:28 -0200, Jeferson Prevedello wrote: Did you really comment out both lines ? I means comment only the first moparam, not the one with the udp port :-) -- Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin(a)longphone.fr Web : www.longphone.com <http://www.longphone.com>

On Thu, 2008-01-10 at 20:10 +0100, Iñaki Baz Castillo wrote: What, you're not even arguing ? :-) You're too kind. But seriously, this is a pretty hot subject, and I've never met anyone suggesting the same as I did here, most of the time I hear the same thing about rtpproxy + CDRs reliability. I'm sure some people are challenging what I wrote right now, in their mind ! If we are lucky, we'll even get emails ! Disclaimer: the above paragraph was not meant to start a flame war on the topic between SST/pinging schools and RTP detection ones. At worst, the two techniques can really complement each other. Regards, -- Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin(a)longphone.fr Web : www.longphone.com <http://www.longphone.com>

On Fri, 2008-01-11 at 02:39 +0100, Andreas Granig wrote: Agreed, the definitive solution does not exists, and is policy and environment-dependent. What I don't get here is the "minutes of tolerance". Typically, RTP timeout is in the same order of time, for what I've seen. Do you use an RTP timeout of a few seconds only ? If so, clearly the issues I've mentionned earlier are even worse with such a short timeout. Talking about policy, I would say it is in the best interest of every provider to limit the amount of "potentially post-BYE, hard-to-bill" minutes. But even with RTP detection, this is hard to acheive. Or maybe you're thinking more of a hybrid solution ? Like RTP timeout triggering a SIP ping, which in return, if failling, triggers call termination. But this is really tough to handle, particulary the case when you don't have RTP but the UAC is still responding to SIP signaling. I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ? Regards, -- Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : jmartin(a)longphone.fr Web : www.longphone.com <http://www.longphone.com>

Jerome, Jerome Martin wrote: Let me clear this up. In some deployments billing relies on successful re-INVITEs (with an interval of some minutes) rather than on RTP timeouts (which may be detected within some seconds). This works because they are rather closed systems with UACs which support the Session Timer standard. So if a BYE is lost for some reason, the call is torn down on the next re-INVITE latest. No, sorry, since I also don't rely on RTP regarding the billing :) Andreas

Andreas Granig schrieb: Yes. If you do accounting for billing purpose, you should the accounting where the costs happen and were you have reliable CDRs. E.g. if you have you own PSTN gateway I recommend doing accounting on the gateway. The gateway always knows the SIP state and the RTP state. Further, the gateway should have RTP timeout and/or Session Timer support to detect dead sessions. If do you not have your own PSTN gateway but use some PSTN gateway provider then you either trust the gateway provider and use the CDRs of the gateway provider or put a B2BUA between your SIP proxy and your gateway provider (thus the B2BUA is somehow a gateway to the PSTN provider) and do accounting on the B2BUA. Doing accounting on the sIP proxy and RTP proxy works too if the gateway can detect dead sessions - neverthless the CDRs wont be as accurate as the CDRs from the gateway. Regarding accounting of SIP-to-SIP calls - if you do not bill them then you can use accounting on the SIP proxy for statistical reasons. if you want to bill them, the same as above applies. regards Klaus