topworldcoder

> hi, From the debug logs and wireshark logs, observed that relayed transport address is being allocated to both the peers by TURN server. And both are sharing the candidate...

> hi @topworldcoder, > > I am trying the environment similar to the 2nd one that you have mentioned in "libpeer is built and run on a linux machine independent...

@zelzmz Did you pull the latest code from libpeer? I have a good experence of it. libpeer ignores handling some attributes type from turn as below: 1. Unknown Attribute Type:...

@zelzmz You can visit Coturn's log to find the exact reason, which may be found in '/var/log'. The code=701 displayed by the Trickle ICE web page is not a fatal...

Hi, This is not a failure. WebRTC prefers UDP by default (with encrypted media streams via SRTP) because UDP's low latency and real-time performance are better suited for audio and...

Did you configure STUN/TURN in libpeer's web html demo? Two different wifi networks may prevent libpeer and the web from connecting directly (probably causing the result "Cannot resolve mDNS address"),...

Hi, I think this involves private signaling negotiation. For reference, you could modify the MQTT implementation in libpeer to enable libpeer to initiate the offer.

Hi @pradhyumnap1999 I'm a reader and beneficiary of libpeer, not the author. I'm currently occupied with other commitments, but if time permits, I'll consider putting your suggestions into practice. Of...

TURN's username and password are used in function agent_create_stun_addr. The function is to obtain the relay address through the TURN server and create the corresponding ICE candidate.

Hi, I’m not encountering the same issue in my environment, but there appears to be some conflicting logic that could be causing the problem. I’ll investigate further and update you.