Fix for ice

[ashar02]

Fix for domain name incase of server side ice candidate. Resolved domain name to ip address.

[zevarito]

Hi @ashar02, code looks good, wonder why this needs to be executed all the time instead of being optional somehow. Can you explain me high level the case/s when this needs to be applied to get more context?

[ashar02]

It runs on answer sdp's ice candidates. Normally we set ip address in licode_config.js. But different deployments use domain name as well. When domain name comes in ice candidate then licode's web (javascript) works perfectly but in iOS it fails. So I resolve the domain name with ip and pass it further to work in this environment. Good thing about domain name to ip resolve is that if you pass ip address to this method then it returns same ip address immediately but if you pass domain then it returns its associated ip address. So I do not need it to check whether its ip or domain because at the end in any case it returns me ip address.

[zevarito]

When domain name comes in ice candidate then licode's web (javascript) works perfectly but in iOS it fails

You mean always fail?
Is it when libjingle parses ICE candidates with domain name or is it a Licode's failure?
If by specification ICE candidate parsers should support both ip and domain, I'd say is better to keep this functionality as optional to help as workaround no matter which endpoint is causing the trouble, but try to be tied to both specifications, webrtc and licode.

[ashar02]

Yes in case of domain name it always fails.
Its libjingle issue. Optional mean put this code in conditional compilation and whoever needs this should enable it by flag. Right?

[zevarito]

well actually I was thinking some global setting on the lib or extra parameter on methods, but now you mention the conditional flag it would make sense, perhaps is good to attach libjingle issue to changelog to be aware about the change. El mar., 30 de abr. de 2019 a la(s) 02:52, ashar_clary ( [email protected]) escribió:

…

Yes in case of domain name it always fails. Its libjingle issue. Optional mean put this code in conditional compilation and whoever needs this should enable it by flag. Right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#87 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKA2WUNZOERZXIFHZLEYTPS7NBTANCNFSM4HJC7FUA> .

-- Alvaro

[ashar02]

Please review.

[zevarito]

@ashar02 That's cool, just added really small comments on code style. Perhaps is good to document somewhere about RESOLVE_DOMAIN_INTO_IP, dunno if just troubleshoot wiki page or if you found a good place on API documentation, I think that's it. Let me know when I can merge. Thank you.

[ashar02]

• Ice is failing because in Licode configuration you set domain instead of IP. Current version of PodRTC (m65) does not support domain name in ice candidate. To work around this limitation, go into the file ECClient.m and uncomment the line #define RESOLVE_DOMAIN_INTO_IP. It will replace the domain name with its associated IP address.

[zevarito]

@ashar02 I've not release new PodRTC version in ages, please point me which version of webrtc would be nice to build.

[ashar02]

@zevarito so far I got the chance to compile and use m72. I was facing the problem in rtsp streams and this ice candidate issue in m65. These both are fixed in m72. Also, do not forgot to enable VP9 when you compile the framework. And I think bitcode is also supported in this branch.