
Real Time Internet Peering for Telephony (RIPT) Comparison with SIP - currysausage
https://tools.ietf.org/html/draft-rosenberg-dispatch-ript-sipdiffs-00
======
currysausage
TL;DR: [https://centr.org/news/blog/voip-goes-web-the-allure-of-
http...](https://centr.org/news/blog/voip-goes-web-the-allure-of-http.html)

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

------
hedora
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.)

~~~
Aloha
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.

~~~
yjftsjthsd-h
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.

~~~
Aloha
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.

~~~
yjftsjthsd-h
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?

~~~
Aloha
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.

------
spicyramen
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

------
anon102010
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

~~~
wolrah
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.

~~~
anon102010
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
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.

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

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

