Hacker News new | past | comments | ask | show | jobs | submit login

I did a lot of testing of a few WebRTC platforms last summer for a product idea that we had.

I came to the conclusion that on mobile phones, WebRTC video is not yet usable. Even with just audio on a cellular network, call quality started deteriorating after a few minutes on every platform that I tried. Video without a WiFi signal was hopeless.

I discussed this with an WebRTC expert, and the problems are partly with WebRTC, partly with how mobile operators shape their data traffic.

Also all platform implementations that were considered the best of the breed were bought by mobile chat companies (both SnapChat and OK Hello did acquisitions on this front)

> how mobile operators shape their data traffic

What I've been wondering is if Apple gets any QoS concessions from the carriers for Facetime, because it usually works pretty well on 4G. Not sure if Facetime's quality is due to robust error correction, or because they've been able to wrangle special QCI/bearer status for Facetime data.

> mobile phones, WebRTC video is not yet usable

Once VoLTE + Video becomes common (eg, Verizon Advanced Calling), then it'll be interesting to see the impact on video-call quality, and whether V/VoLTE sessions can be established with the other end of a SIP trunk, and hence (browser) WebRTC from there.

Yeah, Facetime video seems to work well compared to others. It was a bit hard to explain to a couple of business guys, that "no, we are unlikely to get anything close to Facetime quality with WebRTC solution, but I don't know why."

You could try writing a FaceTime dara packet wrapper/unwrapper, which packs your application data into FaceTime video/audio packets, and unpacks it at the receiving end. If the carriers shape FaceTime traffic differently, it should be possible to establish whether this is the case, by emulating a FaceTime connection, as far as I can see. The content is encrypted, so I don't think they can shape traffic based on anything else than headers.

The issue is mostly due to the nature of the mobile IP, rather than inherent WebRTC variables.

However, ORTC does seek to improve with simulcast/SVC, and attributes of ORTC will merge into WebRTC as well, ultimately providing more hooks, finer-grained control and better instrumentation/visibility to the upper layers.

All that said, you can do acceptable quality WebRTC voice and video over 4G LTE today. But you do need a rock solid signal and be prepared to with a fully charged battery if you are not plugged in.

ORTC doesn't really have anything to do here, except nicer control over some configurations that you can already control with SDP munging.

Simulcast/SVC, for example, are irrelevant outside of multiway video. And you can already do simulcast with WebRTC.

ORTC is just an API.

The WebRTC protocol itself is defined in RTCWEB at the IETF and based on the existing RTP and RTCP transports, and SCTP transport layer. I don't think you'll be able to do better.

I get rather fine Skype video over 3G and 4G.

At Tuenti, a cell phone operator in Spain, we have been using webRTC very successfully for audio. In fact, we built android/iOS/web apps to make regular phone calls (to mobile or landline) using webRTC, either from WiFi or 3G/4G networks.

Interesting. Can you tell more about your stack? What did you use for signaling? Did you implement STUN and TURN to by-pass NATs and firewalls?

STUN and TURN, signaling over our XMPP infrastructure, a more or less recent version of webRTC trunk. We published a post some time ago on our blog about the details: http://corporate.tuenti.com/es/dev/blog/Building-a-VoIP-Serv...

Looking forward to hearing more about this on your website, That'll Never Work© News.

In my humble opinion, your comment is unwarranted. I never said that it will never work.

I actually spent several days last summer evaluating and developing prototypes on top of platform APIs (e.g. TokBox, Sinch) and tested the call quality in several different situations (moving from WiFi to 3G, dropping and regaining signal during the call, call behavior while moving in public transport etc.)

I described my experience and conclusion, hoping to spark informed discussion of the topic. Your comment didn't add any information to it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact