Codec Freedom -- Specifications -- Messaging over AMQP

MSRP defines messaging through text/plain exchanges, but other formats may also be interpreted as (richer forms of) messaging. There is no reason why the same could not be done over AMQP 1.0, which is more generally useful as a messaging protocol. Both MSRP and AMQP facilitate MIME-typed object exchange, and in the case of AMQP this usually involves queueing between sender and recipient.

The established communications protocol for the Internet is XMPP.  Unlike the world of telephony, which has never reached consensus on messageing protocols, the Internet appears to have this topic covered rather well.  This means that MIME-type "text/xmpp+xml" is a good candidate for message submissions over modified G.711, and should be supported as a viable alternative for SMS, EMS and MMS.

Many file formats that could be useful as email attachments can also be passed over a modified G.711 connection.  For instance, a PDF could be transmitted over the AMQP channel.  But since these connections can be really slow, it is more likely that the location of such a file (including a hard-to-guess one-time randome string) is submitted over AMQP and made available for download over the Internet.  The ability to pass the URL of the PDF (or other office-friendly file format) is then all that is required.  This is an out-of-band format.

Calendaring exchanges

Smaller files may be transported over AMQP without problems.  A good example for that could be an iCalendar files with MIME-type "text/calendar", basically implementing an iTIP protocol over AMQP and so, over a modified G.711 connection.  If this integrates with the local calendaring systems on both ends, AMQP could carry meeting proposals and greatly simplify scheduling.  This may be especially using while teleconferencing over modified G.711.

Encrypted phone calls

One possible advantage of having a data channel is to establish a shared secret, and then to reconnect with encryption applied to the entire data stream.  Depending on user settings, such encryption could be enforced (for a given remote party) opportunistic (on phones that are able to encrypt) or absent (in phones that are not setup for encryption).

Several mechanisms have been defined for phone call encryption.  TODO: Survey, choices.

Encryption is applied to the lowest level, namely the G.711 exchange.  It is applied in counter-mode, which means that bits are XOR-ed with a generated sequence of bits that can only be reproduced by peers holding the right keys.

TODO: Really only counter mode?  And no checksum?  Preserving the sending capacity is important, but can it be done with independently encrypted voice and data streams?