Good morning Adrian. VAD over 180 second without any packet, uhmmm ... a strange case. Well. Maybe, I remember a boss that I had in the past who was able to keep me sleeping at the phone for a long time.
The other one, porcentually twopenny but it's something to think about, thank you. OK. Anyway, lets go 1 step ahead. Is there any clever case where mediaproxy should maintain an open dialog when a whole RTP leg is dropped? I mean: <------------- <-----X------- UA MEDIAPROXY UA -------------> ------X------> Finally, combine mediaproxy timeout with dialog tracking is difficult. Think about this: most of RTP timeouts are fired because of signaling problems, so we can not trust on signaling on those cases, and that's why we need an alternative way to signal the end of the call. You know, those cases of the real world: - SIP messages blocked (firewalls) - SIP messages transformed (ALG support) - SIP messages lost (lines dropped, power cut off, windows memory leak....) - SIp messages malicius transformed (fraud). - ..... Thanks in advance Adrian and forgive me to be malicious, I think this case is interesting. Edu Lejarreta. El Lun, 12 de Noviembre de 2012, 10:24 pm, Adrian Georgescu escribió: > 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. >> >> >> Ive been testing this again (Mediaproxy) >> >> >> Playing with IPTABLES has not been a good idea because a rule to deny >> traffic doesnt 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) >> >> >> Ive 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. >> >> Weve 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 >> >> >> Ive tried to rebuild mediacontrol.py with the correct path but its >> 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 > > -- Atentamente, un saludo. ----------------------------------------------------------------------------------------------------------------------------------- Eduardo Lejarreta Langarica IT Manager & VoIP Engineer Freelance Mobile: +34 665 737 587 e-mail: [email protected] e-mail: [email protected] _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
