[SR-Users] RTPEngine UDP receive queue issue
Richard Fuchs
rfuchs at sipwise.com
Wed Aug 8 15:08:25 CEST 2018
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
More information about the sr-users
mailing list