3 ms·

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 t

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 https://tools.ietf.org/html/rfc5359#section-2.15 [1] Pick-up: https://tools.ietf.org/html/rfc5359#section-2.16 https://tools.ietf.org/html/rfc5359#section-2.16

anon102010 7y ago
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.

anon102010 7y ago

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.