Some notes on https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-03 I took while reading it. This draft focuses on one of the aspects of VoIP: peering/trunking.

1. RIPP notes
Giacomo Vacca - 201908

2. RIPP: Real-time Interconnection Peering Protocol
https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-03
This draft focuses on one of the aspects of VoIP: peering/trunking.
Aims to replace SIP/SDP/RTP in that context.
Designed on top of HTTP/3.
Mandates secure caller ID, automated trunk provisioning, seamless failover of
calls.
From Rosenberg and Cullins, authors of SIP.

3. Cloud Computing today
Highly focused on HTTP applications.
Client/Server, Request/Response scenarios.
HTTP load balancers, auto-scaling are typically offered.
Examples:
- K8s
- API GWs
- Istio

4. The Problem
Today interconnections with PSTN still happens typically via SIP.
In SIP-land, developers typically build their own load balancing, HA, failover,
clustering, security and scale strategies, instead of using platform features.
Complex provisioning, static IP addresses, difficult to move calls from a server to
another.

5. The solution
RIPP replaces SIP/SDP and RTP to allow a domain to send and receive calls.
Based on top of HTTP/3 to benefit from UDP.
Includes a self-provisioning mechanism.
Designed to work with HTTP load balancers without modifications.
Includes seamless failover of calls from a server to another.
Mandatory authentication and encryption.

6. Hop-by-hop, client/server
SIP is end-to-end and includes a complex set of tools to allow routing of calls
across various endpoints.
RIPP uses the HTTP approach of Hop-by-Hop interaction. Everything is a
client/server, request/response interaction (potentially through HTTP load
balancers).
In RIPP one entity can act as client or server, and the other as server or client.
The two operations are separate.
A server receives calls from a client. Media flows from the client to the server.
Media to the client flows back on the same connection.

7. Signaling and media together
SIP separates signaling (SIP/SDP) from media (RTP).
RIPP operates in an atomic way, and combines signalling and media inside the
same connection.
Low latency is achieved by many parallel connections sending/receiving media
over QUIC.
Bidirectional bytestreams between consumer and provider are called byways.

8. IP addresses vs URIs
SIP requires IP addresses for proper routing.
RIPP relies on URIs without IP addresses.
Important: The client never provides its address to the server. Data is sent in
the reverse direction (server to client) over the same connection.

9. Authentication
SIP: mutual TLS.
RIPP: client/server paradigm, with client authenticating on server. Roles are just
reversed when the authentication needs to happen in the other direction.

10. Encryption
SIP: TLS (signalling) and SRTP (media).
RIPP: all over TLS (TLSv1.3 mandatory with HTTP/3).

11. Calls vs Connections
SIP: losing a connection may impact calls that were negotiated over that
connection.
RIPP: connections and calls are well separate concepts. Calls can be moved to
other servers without affecting the connections.

12. Roles (RIPP: OAuth2.0)
Trunking provider: Authorisation Server and Resource Server
Trunking customer: Resource Owner
Trunking consumer: Client
Customer and consumer can be the same entity.

13. Operation
1. Configuration. The trunking provider acts as a OAuth resource provider.
2. Provisioning. The trunking customer connects a trunk from a trunking provider
to a trunking consumer. The trunking provider gives the customer a trunk URI
and an authorisation code.
a. POST to /consumerTrunk on trunk URI
3. Both get the (receive) capabilities details. (These are static and this is why SDP is not needed.)
a. GET to /capAdv
4. Initiate calls.
a. POST to /calls on trunk URI (either provider trunk URI or consumer trunk URI), with phone
number and identity header (RFC 8224) + OAuth token.
b. Response: 201 with a unique call URI (+ cookie)
5. Delete trunks
a. DELETE to trunk provider URI

14. Call management
The trunk consumer creates 2 long running HTTP connections (2 byways):
1. GET to retrieve events (1 byway from client to server. “Forward byway”)
2. PUT to send events (1 byway from server to client. “Reverse byway”)

15. Events
Events are sent over a byway and are encoded in a JSON object.
Events can be:
- alerting
- connected
- ended
- migrate
- keepalive
- transfer-and-takeback

16. Media
Every time an entity sends a media packet to the other, an ACK is expected in the
reverse direction.
RTCP reports are not needed since each packet is individually ACKnowledged to
the sender.

17. Migrating a call
Client: end byway used for the call and create a new one for the same call.
Server: asks the client to migrate, causing the client to end the byway and creating
a new one.

18. Call URLs
When the consumer asks the provider to generate a call, it gets a call URI from
the provider.
POST /trunks/123/calls&target=123454545@e164.arpa
The response is a 202 with call URI, e.g.
/call/xyz
Phone numbers are indicated with number@e164.arpa

19. Creating the byways
All these are requests from the consumer to the provider, in case of call from
consumer to provider:
s2c signalling byway: GET /call/xyz/event
c2s media byway: POST /call/xyz/media-forward
s2c media byway: POST /call/xyz/media-reverse
In case of call from provider to consumer, the roles are simply reversed.

20. Events
The server sends events on the s2c signalling byway
The client sends events as PUT /call/xyz/event

21. Multiple byways
Each media packet must be acknowledged by the receiver.
For this reason, media is sent through multiple byways.
A byway that hasn’t received an ACK is considered blocked.
When a certain number of byways are blocked, the entities are expected to open
new ones.