29 Apr
2014
29 Apr
'14
6:53 p.m.
On 04/29/14 12:35, Juha Heinanen wrote:
i made some ICE=force_relay tests between two baresip
sip uas running on
the same host. the result was that they decided to use relay candidates
even when direct connection would have been possible.
the question is why? is it a bug in baresip's ice implementation or is
it a result of the fact that rtpengine changed ip address on c line and
port on m line (which, in opinion, it should not have done), or is the
priority of relay candidates wrong (i.e., smaller value means higher
priority)?
Higher priority numbers have higher priority, with relay candidates
having the lowest type preference number, thus lowest priority. Baresip
seems to give different host candidates the same priority though. This
is invalid according to the RFC.
But according to the SDPs, baresip only supports (or at least in this
case, only advertises) ice-lite. An ice-lite host doesn't initiate any
connectivity checks. When both sides are ice-lite, no checks are
performed at all and the hosts would fall back to what's in c= and m=.
Which is exactly what you'd want.
cheers