8 Aug
2018
8 Aug
'18
9:08 a.m.
On 2018-08-07 20:39, Alex Balashov wrote:
Richard,
On Tue, Aug 07, 2018 at 09:18:06AM -0400, Richard Fuchs wrote:
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
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.