[OpenSIPS-Users] 180 seconds RTP timeout

[Adrian Georgescu]

Deciding that a session has timed out based on a single stream leg being stopped is not a clever thing to do as one party may simply stop streaming for legitimate reasons like voice audio detection or muting the input for listening in into a conference depending on codec behavior. As mediaproxy does not know the behavior of the employed codec, it should not interpret this information arbitrarily. 

You should always combine mediaproxy timeout detection with dialog pining in signaling plane to cover all reasonable timeout situations.

Adrian

 
On Nov 12, 2012, at 1:56 PM, Eduardo Lejarreta wrote:

> Good morning.
>  
> I’ve been testing this again (Mediaproxy)
>  
> Playing with IPTABLES has not been a good idea because a rule to deny traffic doesn’t fire  “/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream” rule so I was mistaken Saul (http://lists.opensips.org/pipermail/users/2012-May/021657.html)
>  
> I’ve been realized about this with cat /proc/net/nf_conntrack |grep udp|grep 500 (if this helps someone)
>  
> Mediaproxy only realizes about this rule when the 4 UDP streams (2 for each leg) are timed out.
>  
> We think that once 1 of the 4 streams has no traffic for 180 seconds mediaproxy should fire the “dlg_terminate_dlg” call.
>  
> Could this be achieved in future versions? Is there any reason to do like actually?
>  
> Finally, for CentOS machines with netfilter support if you want to tune ip_conntrack_udp_timeout_stream variable we have to do on /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream.
>  
> Thanks and regards.
> --
> Eduardo Lejarreta.
>  
> De: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] En nombre de Eduardo Lejarreta
> Enviado el: viernes, 09 de noviembre de 2012 14:00
> Para: users at lists.opensips.org
> Asunto: [OpenSIPS-Users] 180 seconds RTP timeout
>  
> Good morning
>  
> In reference to http://lists.opensips.org/pipermail/users/2012-May/021623.html
>  
> Kernel + Iptables + netfilter + conntrack … versions up to date and supported. Over CentOS.
>  
> We’ve tried this scenario, no RTP flow between both legs.  -> Once the call is established.
>  
> iptables -A FORWARD -s <gw-ip>/32 -p udp -j REJECT --reject-with icmp-host-prohibited
> iptables -A FORWARD -d <gw-ip>/32 -p udp -j REJECT --reject-with icmp-host-prohibited
> iptables -A FORWARD -s <UA-ip>/32 -p udp -j REJECT --reject-with icmp-host-prohibited
> iptables -A FORWARD -d <UA-ip>/32 -p udp -j REJECT --reject-with icmp-host-prohibited
>  
> (Yes I know that this closes SIP dialog also but for investigating purposes is enough. Ngrep and tail over the log running in paralell)
>  
> Other timers like on_hold_timeout and stream_timeout are working fine.
>  
> We suspect that the problem is in mediacontrol.py and maybe other libraries where the path for the 180 second is:
>  
> /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
>  
> When the real var. is:
>  
> /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
>  
> I’ve tried to rebuild mediacontrol.py with the correct path but it’s still failing. Any idea?
>  
> Thanks.
> --
> Eduardo Lejarreta
>  
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121112/2252d050/attachment-0001.htm>