On 2018-08-07 20:39, Alex Balashov wrote:
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.
In and of itself that should be no problem, provided that the SIP proxy actually sees the correct source address for `SIP-source-address` (and not some local address for example).
In my experience, the most common reasons for inadvertently causing a media loop are:
1) An error in the signalling script that causes rtpengine_offer (or answer) to be called twice for the same SDP, with something like msg_apply_changes in between. That would give you: original SDP -> offer -> rewritten SDP, and rewritten SDP -> offer -> rewritten again. If you're branching, you need to make sure that rtpengine gets to see the original SDP as input in all branches.
2) Two SIP proxies back to back, both engaging the same instance of rtpengine. This can also be the same SIP proxy if the invite/SDP is looped back into it.
I suggest you enable debug logging in rtpengine and inspect the actual SDP bodies that it gets to see.
Cheers