<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/21/2017 04:46 AM, Denys Pozniak
wrote:<br>
</div>
<blockquote
cite="mid:CADcrYGLMgST5=vem1edJ1AtzVcSBGmWCswgajoJCC1J=YV3LRg@mail.gmail.com"
type="cite">
<div dir="ltr">Hello!
<div><br>
</div>
<div>I have next topology: ISP->Kamailio +
Rtpengine->WebRTC</div>
<div>Sometimes I receive from Browser side SDP like below with
private IPs in ICE candidates.<br>
</div>
<div>
<ul>
<li>Please explain why it happens?<br>
</li>
<li>How ICE finds a pair? I think Rtpengine obtains packet
from Browser and somehow matches with peer (as it can't
reach Browser via private IP)<br>
</li>
</ul>
</div>
</div>
</blockquote>
ICE candidate collection is done entirely on the client side, i.e.
in the browser. If your browser fails to obtain public address ICE
candidates, it's a problem with the browser script.<br>
<br>
ICE should still be able to find a working candidate pair though,
because once the opposite direction SDP is seen by the browser
(which should contain public address ICE candidates from the other
client or rtpengine), the browser will start sending checks to these
candidates and the other side will then see the NAT'd address and
use this to run checks. ICE completion would be delayed until after
the answer/200 is seen, but it should still complete.<br>
<br>
Cheers<br>
</body>
</html>