[OpenSIPS-Users] 180 seconds RTP timeout

Tue Nov 13 09:16:12 CET 2012

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.
>>
>>
>> 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
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> 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: lejarreta.e at sarenet.es
e-mail: lejarreta.e at seeyouonnet.com