otalk / iOS-demo

MIT License
46 stars 26 forks source link

getting RTCICEConnectionFailed on most cases #2

Closed theDude30 closed 9 years ago

theDude30 commented 10 years ago

Hi, I've manage to make the application work on my signaling server(based on signalMaster) and configured the TURN/STUN server(based on restund), sometimes i can get 2 way A/V but in most cases i get ICEConnectionStateChanged with status = RTCICEConnectionFailed. Any idea?

fippo commented 10 years ago

using wireshark is the only way to debug this usually. Do you get ice candidates with type = relay? Otherwise your TURN server is not configured correctly which is the most common problem.

theDude30 commented 10 years ago

The ice candidate is relay, from web to web the turn server works, from iOS native to web browser i get connection failed on 80% of the relay cases. is there any information i should look for?

On Tue, Sep 30, 2014 at 4:00 PM, Philipp Hancke notifications@github.com wrote:

using wireshark is the only way then usually. Do you get ice candidates with type = relay? Otherwise your TURN server is not configured correctly which is the most common problem.

— Reply to this email directly or view it on GitHub https://github.com/otalk/iOS-demo/issues/2#issuecomment-57309627.

fippo commented 10 years ago

does it work between web and ios? If not: can you get a copy of webrtc-internals?

If it doesn't: wireshark is the only way.

theDude30 commented 10 years ago

it doesn't work between web and ios when i was testing on separated networks(3G and WiFi). below are links for the webrtc-internals and the iOS logs(i've added some logs about the ICE candidates). http://54.92.215.168/fromIOS.txt http://54.92.215.168/copy_webrtc_internals.txt Can you instruct me on what should i be looking in wireshark?

fippo commented 10 years ago

Your relay candidates have a private 10.x address which is unlikely to work.

For wiresharking set the display filter to stun to see all the stun messages exchanged. I'm not aware of any good description on debugging this kind of issues though :-/

theDude30 commented 10 years ago

After some wireshark digging, i found that i was getting 401 Unauthorized responses from the turn server. I've noticed that in the "Allocate UDP user..." packet, there is a USERNAME that is not in the correct a combination of username:password - it was username only. Also, i've checked that when i initialize the RTCICEServer it gets all the right parameters correctly(url,username,password).

From the browser side: The chrome connects correctly to the turn server and i saw that in the allocation packet the USERNAME attribute in the correct format (username:password).

Can you please advise?

hjon commented 10 years ago

It sounds like you have the client set up correctly. Unfortunately, without knowing about your whole setup, the best we can advise is to ensure the right username/password is being provided.

theDude30 commented 10 years ago

I've tried to remove auth module and by looking at wireshark it looks ok, but still i'm getting connection error.any advise is appreciated.

Below is some details on the structure i'm running: Signaling server - I'm using Signalmaster server.js, with the following turn/stun: var configTurnServers=[ {"url":"turn::80","secret":"","expiry":86400}, {"url":"turn:","secret":"","expiry":86400} ]; configTurnServers.forEach(function (server) { var hmac = crypto.createHmac('sha1', server.secret); var username = Math.floor(new Date().getTime() / 1000) + (server.expiry || 86400) + ""; hmac.update(username); credentials.push({ username: username, credential: hmac.digest('base64'), url: server.url }); }); client.emit('stunservers', stunServers); client.emit('turnservers',credentials); });

TURN/STUN - i've setup restund server with the following configuration: daemon yes debug yes realm domain_name syncinterval 600 udp_listen private_ip:3478 udp_sockbuf_size 524288 tcp_listen private_ip:80

module_path /usr/local/lib/restund/modules module stat.so module binding.so module auth.so module turn.so module syslog.so module status.so

auth_nonce_expiry 3600 auth_shared_expiry 86400

auth_shared auth_password

turn_max_allocations 512 turn_max_lifetime 600 turn_relay_addr private_ip syslog_facility 24

status_udp_addr private_ip status_udp_port 5222 status_http_addr private_ip status_http_port 8000

fippo commented 10 years ago

any reason you're not using the standard signalmaster code for this?

Can you copy the credentials you get in the browser (and a pcap of the traffic) to the client use make it use the same credentials (and get a pcap, too)? I still suspect there is something wrong with the way the username and or password is passed.

hjon commented 9 years ago

If there is further information, please re-open, but I'm closing for lack of activity.

mohamedguembri commented 9 years ago

I have the same problem, it doesn't work between web and iOS when i was testing on separated networks(3G and WiFi). Any solution please? thnks

hjon commented 9 years ago

@mohamedguembri There's a good chance you'll need a TURN server because it's not uncommon for there to be restrictions on cellular networks that prevent the peer-to-peer connection.

Are you just using this demo app and http://simplewebrtc.com/demo.html? We don't have a TURN server for the demo, so you'd need to run one yourself (or find one to use, though I don't know of any offhand and they don't tend to be open for anyone to use) and inform the clients. There are two ways you can do this:

  1. Hardcode a TURN server in the client app. There's not currently a public API in TLKSimpleWebRTC for this, but you can see how it's done here: https://github.com/otalk/TLKSimpleWebRTC/blob/master/Classes/TLKSocketIOSignaling.m#L379
  2. Run your own copy of signalmaster and let it tell the clients about the TURN server. I don't personally know a lot about that, but this should help start you in the right direction: https://github.com/andyet/signalmaster/issues/22