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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.