University network AppRTC failure?

[Samuel Ames]

Hi, I'm studying Computing at Surrey University, UK. A web RTC implementation using Node.js is the task for my Final Year Project.

I have tested www.apprtc.appspot.com on my residential network, with my friend who uses Virgin as his ISP and the app worked fine, but as soon as either party is on the universities 'Secure' or 'Open' networks, the demo (apprtc) fails, and remains in the "connecting..." state for as long as the users are prepared to wait.

It's essential that I find a way to counter, or bypass this issue, so that I am able to demonstrate a prototype application later this month.

Any support would be very gratefully received! :)

Thanks,

Sam Ames.

[Ivan Vučica]

Are you able to ping each other?

Can you pinpoint which ports WebRTC tries to talk on? (Look at ICE candidates SDP.)

Can you exchange data on one of those UDP ports? Can you exchange data on any UDP port?

Does your friend have a public IP address, and could he temporarily expose his/her computer via a public IP address instead of NAT? (That always helps, but may open his/her computer to attacks that could be more difficult to perform behind NAT -- so be sure you know the risks. They're small, but they're there.)

If you can find a port where data can be exchanged, you might be able to force WebRTC to talk on that port. OTOH, I can't remember any well-known UDP port apart from DNS's 53. Your best friend will be Wireshark and logging of SDP data from WebRTC.

If you can find a way to exchange UDP data with your friend, you might be able to trick WebRTC into using that. Perhaps even file a better bug report than 'it doesn't work, help', which is basically what Chrome's devs can see in your post. How much is your university network locked down? How? Does Virgin block any traffic? Those are some things someone more knowledgeable than me might ask.

Put yourself in shoes of an expert: Could you help yourself with the data you wrote here, if you could access neither university's nor friend's network to figure out what goes through and what does not?

Regards,

Ivan Vučica

via phone

--
 
 
 

[Samuel Ames]

Thanks Ivan :)

I know that wasn't the most informative post in the world, but the suggestions you have provided are exactly what I was hoping for - suggestions that tell me where to look.

I was surprised to find AppRTC blocked by my University network, as Skype is not. But the network is notoriously frustrating and the webrtc RFC isn't finalised yet - webrtc is still very young, so these kind of issues can be expected.

I'll post as soon as I have had a chance to figure out the answers to your questions.

Thanks again,
Sam.

[Samuel Ames]

Just to update... I have performed another test, which was successful and will allow me to demo an implementation of webrtc at my "interrim discussion" - so I'm very pleased! :)

The callee and caller both on "UniOpen" network. This succeeded when both using capable browsers but doesn't seem to work when either party is away from the university campus, or on an alternative campus network.

I did identify the ports used, but since i successfully achieved an AppRTC conference I decided that I don't need these for the time being.

The issue that I experienced yesterday was a failure but my professor was using an alternative network, "UniSecure", I'll investigate this further, as soon as time allows.

One thing I have noted is that the networks are likely to be non-standard implementations.

Best,
Sam.

[Samuel Ames]

Ryan, that was a very useful post, thanks!

I'll arrive early to university, tomorrow, to allow additional time for some research on TURN servers that I can specify with the apprtc service, and how TURN differs from STUN etc. 

The information in your previous message will help me *hugely* in my 'interim discussion', so thanks again. :)

Best,

Sam

On Thursday, 15 November 2012 16:22:34 UTC, Ryan Brink wrote:

Samuel, 

If the peers are behind NATs that are "unfriendly" to typical hole-punching methods you may need to use a TURN server to establish communication. By default, I believe apprtc.appspot.com uses STUN by itself, so if (as is likely in the campus environment) none of your computer's local IP's, or IP's on the public side of the NAT (discovered via STUNP) work for direct communication you are likely to see the circumstance you described.

If you could post the Javascript console output that could be helpful, but my guess is you're going to need to use a TURN server in the cloud to make this work. Apprtc.appspot.com allows you to specify a turn server by using the "ts" URL parameter (for example, add "&ts=anon...@turn.server.com:3478" to the end of the URL).

Oh, and TURN support isn't in the current Chrome release (23), but you can get it in anything version 24 and up (beta or dev builds).

All the best!

Ryan

[Ryan Brink]

Samuel, 

You might want to follow this thread as well. I started it when I ran into problems getting TURN working correctly.

Ryan