[SR-Users] RTPEngine UDP receive queue issue

Alex Balashov abalashov at evaristesys.com
Wed Aug 8 19:21:50 CEST 2018


I don't have it in front of me, but it's definitely more than a few seconds. Anywhere from 5 to 30 minutes. 

On August 8, 2018 1:20:22 PM EDT, Richard Fuchs <rfuchs at sipwise.com> wrote:
>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.
>
>_______________________________________________
>Kamailio (SER) - Users Mailing List
>sr-users at lists.kamailio.org
>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- Alex

--
Sent via mobile, please forgive typos and brevity. 



More information about the sr-users mailing list