[SR-Users] rtpengine sending rtp to wrong endpoint after reinvite

[Daniel-Constantin Mierla]

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 -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170307/e5a3f2e7/attachment.html>