[Spce-user] RTPEngine ICE Candidates Exchange

[Peter Villeneuve]

Hi Richard,

Could you please take a look at my post above and confirm whether this is a
bug or is intended behaviour?
I'm going to recompile rtpengine changing the "host" in line 105 to "relay"
to see how the linphone clients behave in that scenario, but that's going
to take some time and I'd rather not waste any precious time if I'm barking
up the wrong tree.

Thanks,
Peter

On Thu, Jan 7, 2016 at 10:41 AM, Peter Villeneuve <petervnv1 at gmail.com>
wrote:

> Hi again,
>
> I think I've found the problem.
> It seems that indeed rtpengine is adding itself as a host candidate
> instead of as a relay candidate, which seems to confuse my UA (linphone
> android).
> I believe this behavior (bug? feature?) comes from here
> https://github.com/sipwise/rtpengine/blob/master/daemon/ice.c on line 105
>
> Can Richard confirm this is where he's setting the relay candidate as host
> and if this is the desired behaviour? In my understanding of the RFC
> rtpengine should be adding relay candidates and not host.
> Is this correct?
>
> Cheers,
> Peter
>
> On Thu, Dec 17, 2015 at 11:03 AM, Andreas Granig <agranig at sipwise.com>
> wrote:
>
>> Hi,
>>
>> On 12/16/2015 07:33 PM, Peter Villeneuve wrote:
>> > 1) always with plain SDP
>>
>> This means that rtpengine is stripping any ICE candidates and sends a
>> plain SDP without ICE. That's useful if you're dealing with endpoints
>> not supporting ICE at all.
>>
>> > 2) always with rtpproxy as additional ICE candidate
>>
>> This option would add the rtpengine as additional ICE candidate, as the
>> description implies. I believe it adds rtpengine as relay candidate
>> (something Richard would need to confirm). That means that existing ICE
>> candidates are preserved, and if the endpoints are not able to establish
>> a connection to any of the candidates provided, they can fall back to
>> relaying it via rtpengine.
>>
>> > 3) always with rtpproxy as only ICE candidate
>>
>> This option is stripping any ICE candidates offered by the endpoint and
>> replaces it by a host candidate (I believe; again up to Richard to
>> explain) pointing to rtpengine in oder to enforce media anchoring over
>> the server while still using ICE.
>>
>> > 4) never
>>
>> Well, not engage rtpengine at all.
>>
>> > 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.
>>
>> We'll extend the online help of that preference to make it more clear.
>>
>> > 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?
>>
>> With option 2 it should add itself as relay candidate, see above.
>> Waiting for Richard's feedback on that (or you could grab a SIP trace
>> and provide the SDP bodies negotiated in your case, so we can have a
>> quick look together).
>>
>> Andreas
>> _______________________________________________
>> 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/20160109/5d46f7d4/attachment-0001.html>