7 Aug
2018
7 Aug
'18
8:39 p.m.
Richard,
On Tue, Aug 07, 2018 at 09:18:06AM -0400, Richard Fuchs wrote:
This can happen if the output SDP (rewritten by
rtpengine) is fed back
into rtpengine as an input SDP for the same call/branch. Then
rtpengine will start looping media back to itself. There are some
safeguards in the code to prevent this from happening, but if the
underlying signalling is broken, it can still happen.
Do you think this could happen if the initial INVITE is handled this
way:
rtpengine_offer("replace-origin replace-session-connection ICE=remove AVP
SRTP");
And then two subsequent reinvites occurring back to back are handled
this way:
rtpengine_offer("replace-origin replace-session-connection ICE=remove");
With SDP answers in both cases being handled this way:
rtpengine_answer("replace-origin replace-session-connection ICE=remove
SIP-source-address");
We expected that the subsequent offers/answers would have no bearing on
the existing RTP/AVP -> RTP/SAVP arrangement.
We need to do rtpengine_offer()/answer() instead of just invoking
rtpengine_manage(), because we do a redirect query first when processing
the call (sometimes). When there is no RTPEngine invoked on the first
branch, only on branches >= 2, we find that rtpengine_manage() behaves
improperly, though passing it a branch ID might fix that. I'm not sure
that would address this issue, though.
The reinvites are coming simultaneously from both endpoints, in the
strangest instance of reinvite glare I've ever seen. It's a consistent
behaviour on this particular call flow.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/