4 ms·
The idea that RIPT will be phone endpoint to phone endpoint for media is ridiculous which means latency will go up. I hope I misread the spec! Because phones a
by anon102010 7y ago
The idea that RIPT will be phone endpoint to phone endpoint for media is ridiculous which means latency will go up. I hope I misread the spec!
Because phones are usually double natted / double firewalled the vonages / ringcentral and friends will have the phones connect to their servers, and pass the media that way.
I currently finally got the media side to handoff pretty directly from our phone system to whatever media endpoint is suggested to handle the call termination for SIP - latency is improved, but the media bridges to local telco etc seem to be adding their own latency.
What is crazy is you used to be able to call three floors down (separate network but next door) and get no latency. Literally. The call was circuit switched through something in town or sometimes closer.
Now with RIPT that media is going to travel to the ringcentral west point server, then back, to go three floors, and YES, latency will be higher than 30 year old tech. Imagine that. Billions spent, and the quality is worse.
I hope this is wrong.
- wolrah 7y agoAs you've noted, the direct media thing is great but doesn't really work reliably with phones behind NAT unless there's special processing at the NAT side. And of course most NAT devices that offer said processing get it wrong and usually make things worse. I've been working in VoIP for years. We do direct media when we can, but we bounce it through the server fairly often because NAT sucks. RIPT seems to built primarily with cloud hosted applications in mind, which need to scale and are likely being connected to by clients behind NAT. It's explicitly not like SIP, where every user agent is equal and would theoretically communicate directly where possible. This is why I wish IPv6 had a real killer app to make it catch on, it'd make life so much easier for me and SIP would work how it's supposed to.