Codec Freedom -- Specifications -- Connection Profiles -- Error Handling

In the course of a connection, things may go wrong. This may not lead to problems for voice, other than a glitch on the line. For data, it may be disastrous. The MSRP transaction layer handles errors and recovers from them.

TODO: This document is specific to MSRP. We moved on to AMQP 1.0 to replace MSRP with a more general framework.

MSRP does a few useful things. It can cut a media stream up in small chunks, multiplex them (that is, the chunks identify the streams to which they belong) and it acknowledges each chunk separately.

MSRP Transactions, Queues, Resends

What we mean by an MSRP Transaction is the complete and acknowledged delivery of a single chunk. Until a transaction is complete, a chunk is kept in a queue so that it may be resent if need be. Once delivery of a chunk is confirmed, it is removed from the queue.

MSRP Chunk-Checksums and Transaction Errors

When an MSRP Transaction fails, this is usually noticed through an error report at the MSRP level. This can be processed in a manner that suits the error supplied; not all error call for a resubmission.

To facilitate resends after bad delivery (over a choppy channel, for instance) we add the notion of a Chunk-Checksum to each MSRP chunk delivered as part of this specification. The header is formatted as follows:

Chunk-Checksum: 1bc093a8

This is the hexadecimal notation of the CRC-32 checksum of the binary data of the chunk that follows the MSRP headers. CRC-32 is not a secure checksum, but it is designed to find transmission errors, which is the goal here.

When the receiving side notices a fault with the Chunk-Checksum, it will report an error that indicates that a resend is warranted, namely

400 Unintelligible

RESET from Lower Layers

In exceptional cases, the connection may experience so much trouble that the MSRP layer cannot correct it. In such cases, the line will be reset.

A remote reset is marked by a special signal named RESET sent up from the line; the local MSRP endpoint must then immediately stop sending bytes from the current connection, and return to the start state. Alternatively, the local endpoint may choose to send a RESET signal down, in which case it should ignore any input from the remote until a RESDONE signal is sent back up.

Due to these implementation aspects, reset is a synchronous event that impacts both endpoints at the same time, so they start handling the apparent problem at the same time.

A RESET is a signal that indicates starting from scratch within a virtual connection within the "physical" connection from the connection profile. That is, the connection remains open, but the data sent over it starts from a well-known point. Codec submission is not interrupted by a RESET.

Specifically for MSRP, a reset means that currently streamed media may continue to stream, but any transactions (or chunks) being processed at the time of the RESET are considered not to have been delivered, and are setup for resend. But before getting there, the MSRP connection must start from scratch; this may involve re-initialising connection encryption.

Note that a RESET applies only to the transmission of data, but not to the transmmission of the codec bytes. It is assumed that voice data may survive a glitch on the line, unlike data which would be totally upset and undefined; in other words, in a situation that can only be resolved by forcing a return to a known state.