As far as I know, nope. However, the much slower and bloated (in my opinion) mediaproxy does exactly this and even more in terms of "billing safeties". On Thu, 2008-01-10 at 16:11 +0100, Helmut Kuper wrote: 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

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 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>

Jerome, In my opinion it depends on the policy of the VoIP provider rather than on technical issues. Proper implementation of RFC 4028 of all involved UACs might render RTP analysis useless, if it's in line with the policy of the the VoIP provider to have some minutes of tolerance in their CDRs in case of missing BYEs (the tolerance can be controlled by the provider via the defined headers). If that is still unacceptable by a provider, there maybe should be some SIP/RTP-aware billing engines in place though. Andreas Jerome Martin wrote:

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 Martin napsal(a): My provider (about 50.000 customers, few milion minutes per month) detects RTP streams and terminate calls after 10 seconds without RTP. VAD is disabled, of course :-) Its solution is based on propritary telco SIP to SS7 gateway... BTW: The same thing I do with Asterisks behind my OpenSER (10 secs RTP timeout), but I'm very interested in SIP pinging. Could you point me to some hint/working example how to do it with SIP proxy (like OpenSER)? Thanks in advance, kokoska.rokoska

Andreas, On Fri, 2008-01-11 at 15:41 +0100, Andreas Granig wrote: Right. That's the solution I like the most. Well, you only need 1 SIP endpoint in the chain supporting SST for this to work, but obviously if this one breaks, well, you loose it all :-) I know :-) Well, seems in the end we have the same approch :) What was strange to me (and still is), is the fact that some people are using RTP detection with a few seconds threshold. This is insane in my environment, and really I don't see an environment where it would not be a huge penalty, for the reasons I've given before in this thread : - you cannot use VAD - you're stuck with RTP proxying - users cannot cut the mike on their phone (with business subscribers, this is a clear no-go) - it's not generic at all, aka, it does not work for SIP sessions that are not phone calls (IM sessions, using something else than RTP, or just oneway RTP like message diffusion etc...) So I'm saying it again: using RTP detection is an UGLY HACK (when used alone). On the other hand, RTP detection + ping when you detect the stream went down, so you can check if the stream went down but the user is still in control, is a good idea. So RTP detection is interesting when used AS A PART OF A MORE COMPLEX SCHEME, but NOT standing alone. What do you think ? 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