[Spce-user] RTPEngine ICE Candidates Exchange

[Peter Villeneuve]

Hi guys,

This is a topic that also interests me.

I have setup latest spce on a debian machine and am using the linphone
android client for testing.

I see in the rtpengine options that 4 are available:

1) always with plain SDP
2) always with rtpproxy as additional ICE candidate
3) always with rtpproxy as only ICE candidate
4) never


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.

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.
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.
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?

Cheers,
Peter


On Wed, Dec 16, 2015 at 1:48 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 12/16/2015 08:44 AM, afshin afzali wrote:
>
>> Richard,
>>
>> Do you mean by sending re-invite (including the new ICE candidate) I
>> will be able to do so? What rtpengine will do ? Does it cause sending a
>> re-invite in case of new ICE ?
>>
>
> 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`).
>
>
> Cheers
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20151216/9b14fc4f/attachment-0001.html>