8 Mar
2017
8 Mar
'17
9:05 a.m.
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