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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
