<div dir="ltr">Hi guys,<div><br></div><div>This is a topic that also interests me.</div><div><br></div><div>I have setup latest spce on a debian machine and am using the linphone android client for testing.</div><div><br></div><div>I see in the rtpengine options that 4 are available:</div><div><br></div><div>1) always with plain SDP</div><div>2) always with rtpproxy as additional ICE candidate</div><div>3) always with rtpproxy as only ICE candidate</div><div>4) never</div><div><br></div><div><br></div><div>Obviously 4 is pretty self-explanatory, but I don't understand what option 1 does. Doesn't rtpengine always rewrite/insert ICE candidates in SDP when activated? So what does option 1 do exactly that's different from 2/3? I can't find any info regarding that in the documentation.</div><div><br></div><div>Also, in my test scenario, where both android linphone clients support ICE, I thought that using option 2 would be ideal since the media would only be relayed when the two clients cannot establish a p2p connection directly.</div><div>But when I actually use option 2, and both linphone clients are in the same LAN and can communicate p2p, I see in the linphone logs that ICE reports it is using relay connections, which surprises me since they should both be reporting a p2p host connection.</div><div>Since linphone states it adheres to the ICE RFC, and so does rtpengine, I don't understand what's going on when I know for certain that both clients can easily talk to each other directly. It seems to me that rtpengine maybe inserting itself as a host candidate when in fact it is a relay one. Does this make any sense?</div><div><br></div><div>Cheers,</div><div>Peter</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 1:48 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/16/2015 08:44 AM, afshin afzali wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Richard,<br>
<br>
Do you mean by sending re-invite (including the new ICE candidate) I<br>
will be able to do so? What rtpengine will do ? Does it cause sending a<br>
re-invite in case of new ICE ?<br>
</blockquote>
<br></span>
What I mean is that if the WebRTC client sends a re-invite instead of an INFO for ICE updates, then that would work out of the box. Otherwise, if it's using INFO messages (as it should, according to the RFC), then the SIP proxy must be instructed to pass these messages down to rtpengine like it does for re-invites (using `offer` and `answer`).<div class="HOEnZb"><div class="h5"><br>
<br>
Cheers<br>
_______________________________________________<br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
<a href="https://lists.sipwise.com/listinfo/spce-user" rel="noreferrer" target="_blank">https://lists.sipwise.com/listinfo/spce-user</a><br>
</div></div></blockquote></div><br></div>