RealVoice Network-Level Protocols
Timothy Milliron

RealVoice uses a peer-to-peer network abstraction, mimicking the structure of the phone network. In order to accomplish good bandwidth, low latency communication, RealVoice employs unreliable UDP sockets for the transmission of voice data. However, since reliability is critical in certain segments of the protocol (connecting, maintaining), TCP sockets are also used. In short, a dual-socket peer-to-peer interface embodies the RealVoice structure. The network protocol can be defined as below (details about data format are at the bottom of the page).

• When a RealVoice process starts, it opens a TCP server port at a well-known RealVoice port number (RV_TCP_PORT == 25445, which is RealVoice in base-256 arithmetic mod 65536 and listens on that port for .
• When a RealVoice process (the local process) wants to connect to another RealVoice process (the remote process), it connects via TCP to the well-known port address. Then, it sends a byte with the RV_CONNECT code, a string with its username, and another string with the username it would like to connect to.
• Upon receiving of this connecttion request, the remote process first checks the strings to be sure that the desired username is its.
  • If it is, the protocol goes on.
  • If it is not, the remote process sends an RV_DIFFERENT_NAME message to
    • The local process can handle a RV_DIFFERENT_NAME message as it desires (connecting, for example, even though the names are differen). In any case, values like RV_NAME_OKAY should be sent back
• After the connection request, the remote process sends back a byte-code RV_ACCEPT,(
• Now, the two sides decide on a data-compression format. They do this by sending a bit vector from local to remote, masking it so only one bit is left, and sending if back from remote to local. Currently, only 1 compression format is supported, RV_COMPRESS_SGI.
• Now, the two sides agree on a packet-rate (# of packets per second) by finding how many bytes were sent. This is accomplished when both sides sent a proposed packet-rate score, and the lowest wins.packet=rates are sent as bytes.
• Finally, the hosts send each other their UDP address to send voice data to. Compression follows
• Any control notification should communicate through TCP

The above scenario allows for considerable flexibility to configure a RealVoice session. One thing that should be added to the specification is that certain audio and datalink parameters need to be written at compile time.

Data Formats
Several data format details are important to notice:

• All data sent over any port is sent in network byte-order.
• UDP packets are sent with four-byte sequence number headers (in network byte-order) so that they may be reordered on the other end.
• UDPAddresses are sent by a 32 bit int (the IP address) followed by a 16 bit int (the port).