Summary:ASTERISK-15482: RTP Timeout is flawed
Reporter:Private Name (falves11)Labels:
Date Opened:2010-01-20 17:50:02.000-0600Date Closed:2011-06-07 14:00:42
Versions:Frequency of
Description:The sip.conf configuration rtptimeout=XX only considers one way, not both. Suppose the caller is silent for more than XX seconds, on mute, while his mother issues a long speech. The call drops. This function must consider audio both ways, and only if there is silence in both channels, drop the call.

In my particular case, if I call to a voicemail where the greeting is longer than XX seconds, and I simply keep my microphone silent, the call will drop exactly at XX seconds, invalidating the whole thing.

Comments:By: Igor Zamocky (dzajro) 2010-01-21 01:05:58.000-0600

Sorry for maybe stupid question, but how will you detect the opposite side is dead and call should be disconnected?

If there is now RTP coming from opposite side, we can assume some signalling packets (BYE) has been lost and call should be terminated. With Your update all functionality became meaningless.

For your scenario, let's consider to use:

Asterisk sip rtpkeepalive = Number : Number of seconds, when a RTP Keepalive packet will be sent if no other RTP traffic on that connection. Default 0 (no RTP Keepalive). (New in v1.2.x).

and/or bigger rtptimeout.

By: Private Name (falves11) 2010-01-21 06:35:00.000-0600

rtpkeepalive actually breaks the compatibility with many switches. I cannot use it. The calls actually fail in the first few seconds when talking to many flavos of border controllers and softswitches.

The consequences of rtptimeout=XX are such that if I stop talking and just listen, like in a conference where many people are in "mute", then the call drops. This is irrational.

By: Joshua C. Colp (jcolp) 2010-01-21 07:28:44.000-0600

If the change is made as you suggest then rtptimeout does indeed become completely useless even further. It would only work if *both* sides died which rarely happens. In the real world usually only one side dies. Additionally while we don't completely die in VAD/Silence Suppression environments rtptimeout is obviously incompatible with it, and it sounds like you are using it. The only thing that would most likely come close to working with what you are trying to achieve is session timers.

By: Private Name (falves11) 2010-01-21 07:37:40.000-0600

Could you supply a session-times configuration for sip.conf? This is what I do: I get a SIP call and place an outbound call also via SIP. I need to send packets to the caller and to the callee to prevent that either is dead, otherwise the  billing is useleess, basically. I was using rtptimeout but as you can see, under some pretty normal conditions, it is quite useless. I use 1.4. I wonder if it is possible indeed to achieve what I need to achieve with 1.4.

By: Joshua C. Colp (jcolp) 2010-01-21 07:54:53.000-0600

Asterisk 1.4 does not support session timers. As for your comment about rtptimeout not working under pretty normal conditions - these aren't pretty normal conditions. There's a reason you are the first person to bring this up and that is because most setups do not use VAD or silence suppression and continue to send packets even while muted. In those more normal conditions rtptimeout would operate perfectly fine as intended.

By: Private Name (falves11) 2010-01-21 08:03:10.000-0600

I do not use VAD or silence suppression. But I confirmed last night that at the beginning of call, if I set the rtptimeout to 30 seconds, and the answering machine salutation is longer than 30 seconds, while the microphone is mute, the calls drops exactly at 31 seconds. If I extend the rtptimeout o 60 seconds, it drops at 61 seconds and so forth. This does not happen if the microphone is open and there is some background noise.
So what is going on here? the RTP should be flowing even with the microphone muted.

By: Joshua C. Colp (jcolp) 2010-01-21 08:06:53.000-0600

Yes. There should still be a constant stream, it should just contain silence.

By: Private Name (falves11) 2010-01-21 08:17:10.000-0600

I am going to try again with 1.6. Can you advise on what my sip.conf should contain for sip-times to work the way I need it? Also,what is the most stable 1.6 flavor?

By: Leif Madsen (lmadsen) 2010-01-21 10:51:21.000-0600

At this point we're just dealing with a support issue as there is no bug here. Please take this to the asterisk-users mailing list, or some other appropriate forum.