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: [email protected] 
> [mailto:[email protected]] En nombre de Eduardo Lejarreta
> Enviado el: viernes, 09 de noviembre de 2012 14:00
> Para: [email protected]
> 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
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to