Codec Freedom - Partial Projects

This page details a number of projects that fall under the scope of Codec Freedom. They are components that work together to make the system work across the Internet and telephony system.

Standard Specification

This work is actually in progress -- defining how to wrap bits and bytes into the existing connections meant for the phone system's G.711 backbone and GSM-based CSD. We figured out that it is possible to achieve Codec Freedom for all these systems, and are specifying how.

The intention is to turn this into an Internet Draft, and aim for an RFC. But to test the specification, it should be tried in many applications. And that's where the attention for the project scatters.

What we are looking for is people who are willing to implement the specification in their favourite software. A few structures that can be helpful follow below. Please let us know if you are interested!

Initial Test Suite for G.711

The first thing we should do, is create a method for inserting data bits into a G.711 connection, and try it everywhere -- using VoIP deals and perhaps even ISDN devices for G.711.

What is needed, is a method of adding data bits to an A-law flow, and one that extracts data from it. The toolkit should also be able to map between A-law and uLaw according to the definitions of the G.711 specification.

The purpose here would be to find how reliable the connections are:

Clearly, it would help if not UDP but SCTP with its reliable out-of-order delivery was used for these RTP streams. That, however, assumes co-operation from VoIP providers, and the trick here is to establish Codec Freedom through end points only.

G.711 architecture

Sending CSD from Android, Jolla or iPhone

Old-school GSM phones used to be able to connect with CSD to a PPP server. This was back in the days that our laptops would use an infrared link to those phones. Things have certainly changed, but the CSD protocol is still commonly supported by GSM-networks these days.

Smartphones usually run Internet over GPRS, UMTS or LTE, and cannot setup these CSD connections anymore. Understandable because CSD is charged per minute like a phone call; less understandable because it is a realtime, constant-pace protocol.

To be able to communicate CSD from a smartphone, we should re-introduce it, probably in native code that may pop up somewhere in an API that can handle the remainder of the communication.

To test, two programmed phones may communicate; or, one of them may be an old-school GSM phone; or, a modem service number may be dialed.

CSD soft modem recipients

When a CSD call arrives at a phone number, it is usually delivered as a voice channel with the modem signals played out on it. Variations may exist.

The reception of modem calls is usually ill-advised over general networks; but the bandwidth of fibre connections may actually make this possible again, especially when the phone number is technically arranged by the same party as the fibre network.

What is needed to receive such calls is a soft modem application that extracts the AMQP 1.0 flow and makes it locally available. SIP and SDP packets can be delivered to a nearby SIP application, especially when the Content-Disposition is set to session. Any codec bytes received would be packaged in RTP messages, and sent as per the direction of the SIP application.

Candidate software to extend:

CSD architecture

GSM connection research

The GSM connection page gives a lot of issues that cannot be answered right away. Some research ought to be done here. It would make a very interesting network research project for a student assignment in the course of their study.

GSM Connection Structure

RTP / AMQP relays with ZRTP support

An AMQP relay is a place where users can send and receive MIME-typed files. It may communicate to users as a webbed cloud server, remote filesystem, elastic storage service, FTP server, chat gateway, and so on. Users would send files through this system, or receive files delivered to it. Often, it implements a queue to allow time-delayed delivery, but this is not a necessity in the AMQP 1.0 version.

An RTP relay is commonly used to reflect media streams through a public IP address. This is helpful to pierce through NAT, which also happens to be one of the usecases for an AMQP relay.

A combined RTP / AMQP relay can observe a G.711 flow, and modify it with an additional AMQP context that pass through it, and it may pickup an AMQP flow in the incoming stream. The same system might also be used for crossover between IPv4 and IPv6.

Relaying of ZRTP is easy to add; it is clearly distinguishable on the RTP flow, and since it is not realtime data it can be forwarded over AMQP with MIME-type message/zrtp.

Candidate software to extend:

Mobile phone Apps

Mobile phones should implement a CSD channel to implement this mechanism. CSD is a realtime channel over which data bits can be sent, including forward error correction. The resulting bitrate is not high, unless HSCSD is implemented, but it is a fixed-latency channel, making it suitable to stream a modern codec. CSD is usually charged just like a voice call.

This usually requires a native application, because the API shown to generic Apps does not always provide a facility to setup CSD. Once AMQP is setup, it is possible to send various MIME-typed data packets across.

The tool would listen on a loopback interface for incoming traffic over AMQP, SIP/SDP and RTP. Incoming SIP/SDP would be forwarded as an AMQP blob with Content-Disposition set to session, and RTP would be relayed as codec bytes. Possibly, SDP options that require too much bandwidth would be removed from offers that pass through.

Candidate software to extend:

Phone software

A SIP phone is a good place to insert the same procedure. It is also a very suitable place to arrange codec changes, and the main change would be that modern codecs pass through a rate-limited stream that is known to the outside world as a old-school telephony connection.

Candidate software to extend:

blogroll