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

[Daniel-Constantin Mierla]

Hello,

good to know -- useful information to have in mind.

Cheers,
Daniel


On 08/03/2017 09:49, Grant Bagdasarian wrote:
>
> 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 at lists.sip-router.org] *On
> Behalf Of *Daniel-Constantin Mierla
> *Sent:* dinsdag 7 maart 2017 23:06
> *To:* Kamailio (SER) - Users Mailing List <sr-users at lists.sip-router.org>
> *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>

-- 
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/20170309/c2174886/attachment.html>