Real Time Internet Peering for Telephony (RIPT) Comparison with SIP | Hacker News Reader

Real Time Internet Peering for Telephony (RIPT) Comparison with SIP

tools.ietf.org

56 pointscurrysausage25 comments

TL;DR: https://centr.org/news/blog/voip-goes-web-the-allure-of-http...

Yet another protocol that sits on top of HTTP. I have a general heuristic I like to use, which admittedly isn't always right but is right enough to be useful to me: if someone wants to make a new protocol and their solution is that protocol needs to be on HTTP that person shouldn't be making protocols.

It would be nice if end to end encryption was mandatory, instead of hand-wavingly allowed by saying implementations may encrypt the media stream and then sending it inside an insecure TLS stream. (They propose using an out of band session initiation protocol to exchange the keys.)

As someone who has to troubleshoot telephony applications, mandatory encryption makes troubleshooting much harder. As someone who runs applications on private, isolated networks, mandatory encryption just adds more overhead for me without much benefit.

Dinosaurs said the same thing about HTTP and Telnet. You have a point, but its flat out wrong

https does make troubleshooting harder. So does SSH.

'If you can't stand the heat, get out of the kitchen'

I didn't say encrpytion was bad

But for an isolated use case where you control both ends and the network itself, it's entirely valid to say that it's overhead with little benefit.

Personally I think the benefits of using encrpytion by default outweigh the downsides, but I can see others may disagree, I wouldn't call them "flat out wrong".

On the one hand, I would like a debug mode that let me run without encryption. On the other hand, I agree that if it's not required then it will end up being skipped out on in a real, production system on the public internet.

I disagree that encrypting the header data for SIP to be all that critical, even on the public internet, the RTP yeah, thats a good thing to encrypt, but headers? nah - its good if you can, but when you're tryin to bring up two systems with no real user interface to troubleshoot, often the headers data is the most useful thing you have.

It might be less sensitive, but isn't there still metadata in there? Or signaling information that would let an (MITM) attacker downgrade the RTP connection?

I dont know enough about SRTP negotiation to know if a downgrade attack is possible, but I can see ways in a new system to deal with that though.

One of the best advantages of SIP was interoperability, I worked with many vendors which were able to use Cisco/Asterisk/Skype (when they supported SIP), ACME...yes it was painful to troubleshoot headers and messages but most of the time worked. Many issues when protocol was initially deployed and replaced H323 but at the end it prevailed

My big complaint with SIP is latency - we should be able to get latency way down and call pleasure is enhanced significantly with low latency - how does this help

SIP (Session Initiation Protocol) is used for initiating, maintaining, and terminating sessions, while media transport is delegated to other protocols (RTP, SRTP).

This would change with RIPT, and latency is definitely a consideration:

https://tools.ietf.org/html/draft-rosenberg-dispatch-ript-si...

Latency in a VoIP phone call has nothing to do with the control protocols and everything to do with your connectivity and the configuration of the jitter buffers on either end.

There should be no practical difference in audio performance, either latency or quality, between different VoIP signaling protocols unless something is wrong. If you're experiencing latency on calls that is significantly greater than your network latency plus jitter then something is wither misconfigured or malfunctioning.

That said as RIPT attaches the media to the signaling in a single flow of packets it should have far fewer problems negotiating NATs and similar scenarios that have been known to cause problems for SIP. Those problems cause complete loss of audio in one or both directions though, anything affecting call quality is almost certainly a network performance issue.

Call setup times with SIP are often much longer than their TDM predecessors, its one of my complaints with SIP.

Usually that means your ATA is not configured properly. With the correct dial plan settings, call setup time should be comparable to the PSTN.

I have many other complaints with SIP, mostly related to the assumption by many clients that there is never any packet loss during call setup, but call setup time is not one.

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.

As 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.

I'm upvoting your comment because, while technically naive, it squarely addresses what matters to users. As others noted, SIP and RIPT have absolutely nothing to do with call quality. RIPT is intended to make if easier to write software that implements calling features.

In a former life I was the director of call-processing / media-handling development at Vonage. SIP was an overly-complicated, overly-featureful protocol that fought us at every turn. But our really frustrating problems were with our user's Internet connections. Nobody cared what calling features we had, but media latency, jitter, and just plain connection flakiness was a major driver of customer churn.

For a VoIP provider, SIP is a vast improvement over telco standards such as SS7 and Megaco (H.248). But it envisioned a utopian, distributed world where end-users directly connected with one another over the Internet, with maybe a little bit of help from directory services. In the real world, VoIP is implemented as a strictly client-server architecture. This is driven by needs for security, PSTN interconnection, accounting, and above all coordination of state management. SIP smears call state over the entire network; every piece involved is sovereign of its own little part of the puzzle, and has to cajole the other parts into making appropriate state changes. For example, call parking (putting a call on hold and then picking it up on another phone) in idiomatic SIP requires a parking server just to keep the call alive. [0] [1]

Based on a quick look, RIPT seems to resolve some of SIP's headaches. It's still too complicated. For customer-facing apps all we really need is a persistent connection to the server, with events saying "customer wants to call X", "incoming call", "customer pushed button Y" and "here's a media stream". Let the server handle call state. PSTN and other interop is a whole 'nother problem space with little in common with customer-facing features, only requires call-leg state rather than call/session management, and should be addressed with a completely different protocol.

[0] Park: https://tools.ietf.org/html/rfc5359#section-2.15

[1] Pick-up: https://tools.ietf.org/html/rfc5359#section-2.16

I have configured SIP to avoid some of the client / server model. You can do that on a local network you can control, and if you can get your firewall to play or can expose a SIP endpoint to the public internet directly you can cut a fair bit of latency out.

My question - will RIPT REDUCE latency in the ordinary case vs well configured SIP?

I've driven latency reduction by doing the onsite SIP PBX to a set of analog phone lines - in some setups that BEATS the round trips.

SIP would work much better if every phone was on a publicly routed unfiltered network. But that simply isn't the case. Others posting are claiming the phones under RIPT will be able to talk directly too each other - but how?

The stack adds latency - audio encoding, bufferbloats, etc - whatever is happening results in worse audio latency than 30 year old tech which makes little sense.

These days, latency is very low for most calls in North America. In fact, when we calculate MOS (which is a score for your call quality), we don’t even use latency if it’s under 100ms.

These days, I find more call quality issues are a result of issues on the LAN rather than the Internet. More specifically, I see voice quality degradation caused by routers/firewalls that are not quite able to deal with the volume of traffic being pushed through them.

SIP has some disadvantageslike a lack of NAT awareness, a common issue of SIP implementations while being fully compliant with the standard - cant interoperate, incompatible extensions, long call setup time, and a lack of defined minimum codecs.

While I'm sure all of this will fix that, it becomes yet another protocol that will need to be supported - nor am I particularly convinced that encryption everywhere is something you always want (if I use SIP as an example, often packet captures are a hard requirement to troubleshoot why server A cant talk to server B).

I'm open to it though, the TL;DR posted elsewhere in the comments is much more digestible than the draft standard. But it looks like it solves some of the issues with SIP, but introduces its own other issues.

Does it really make sense to start over for NAT now that ipv6 is so far along?

Reply on news.ycombinator.com