Hi Daniel, Thank you for the answer. I’ve also asked the same question on the rtpengine github page and they suggested to try the asymmetric flag and that fixed the issue. Another fix has been suggested, but I haven’t tried it yet. For anyone else interested in the same issue: https://github.com/sipwise/rtpengine/issues/330 Regards, Grant Bagdasarian CM *From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Daniel-Constantin Mierla *Sent:* dinsdag 7 maart 2017 23:06 *To:* Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.sip-router.org&gt; *Subject:* Re: [SR-Users] rtpengine sending rtp to wrong endpoint after reinvite Hello, On 07/03/2017 13:10, Grant Bagdasarian wrote: Hi, One of our customers is using a SEMS box to place two outbound calls using our sip trunk. Once the first call is connected a second call is placed and when the second call answers their server sends a re-invite to switch audio ports so the rtp traffic doesn’t flow through their server anymore but is routed inside our platform. Basically, they just switch SDP’s of both calls. It seems like a random issue, and is not really reproducible, except for placing multiple calls and sometimes both parties can hear each other, other times they can’t, because rtpengine fails (I think) to update the endpoint and keeps sending rtp back to their server for one of the call legs. We tried to reproduce the case using a freeswitch box and it worked every time. After the reinvite, the rtp remained within our platform. The signaling in both cases still goes through the freeswitch or sems for call control. Does anyone have experience with this case? Or seen the issue before where rtpengine keeps sending rtp to the original endpoint? Have your checked to see if the sip messages are received/processed in the expected order? In some very rare situations, it happened that the re-invite was sent very fast by callee after just sending the 200ok, so that the re-invite arrived to the proxy/rtprelay before the 200ok, so at the end the sdp from 200ok was taken as the last relevant one for the peer. I put there rtprelay, because I faced this issue where I had rtpproxy, but maybe the issue is exposed by the rtpengine as well. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com <http://www.kamailioworld.com>