[SR-Users] RTPEngine UDP receive queue issue

[Richard Fuchs]

On 2018-08-08 13:05, Alex Balashov wrote:
> On Wed, Aug 08, 2018 at 09:38:02AM -0400, Richard Fuchs wrote:
>
>> On 2018-08-08 09:25, Alex Balashov wrote:
>>> Richard,
>>>
>>> rtpproxy classic edition had an SDP attribute that could be inserted to
>>> prevent rtpproxy from operating on the SDP if another rtpproxy had
>>> already been engaged upstream. Does RTPEngine have a similar feature?
>>>
>> Yes, if you include the `loop-protect` option.
> Thanks! Are there any SDP interoperability concerns with using it?

Not any more than what you would get with rtpproxy doing the same thing :)

>
> The other aspect of this that I am puzzling over is where the packets in
> this loop are coming from. The call is long dead, the ports involved are
> not in use (per the RTPEngine call list), but I'm still getting:
>
> Aug 08 12:50:00 gw1 rtpengine[18934]: ERR: [992251125_16092378 at x.x.x.x port 60368]: Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible
>
> Are these RTP frames that were previously sent at some point during the
> call looping?

Hard to say without any further details. What does "long dead" mean 
exactly? Seconds, minutes, hours? A deleted call disappears from the 
call list immediately, but components of it (ports in particular) may 
remain open for a short period of time until all reference counts drop 
to zero. That should take only seconds at most though.