Codec Freedom -- Specifications -- Codec Frames in packet mode
When sent in packet mode, codec frames may need some transport handling before they are subjected to escaping and the connection profile. This specification aims for optimal compaction of RTP frames.
Robust Header Compression
There is a very useful standard for compression RTP frames, namely Robust Header Compression, or RoHC for short. Within each, a number of profiles have been defined, among which are of course profiles for IP/UDP/RTP header stacks. These profiles define repeated and predictable information in the headers concerned and take measures to remove those patterned bits of information from a flow between given end points. In the most extreme variations, these headers are setup once and then simply removed.
This means that it is cheaper to include all of the headers IP/UDP/RTP and employ RoHC, rather than minimising the parts of RTP that we pass. Since RTP is intended to run directly between end points, this is a much preferred form of communication. Local setups can always choose to take care of the routing for these RTP packets through the Codec Freedom stack; for instance, by using an RTP relay on either or both ends. The inclusion of all headers causes maximum freedom without any real cost.
Although IPv4 is supported by RoHC, it is better not to use that anymore. SIP over IPv4 is a specialist deal, and quickly means we need to resort to commercial providers who are obliged to tap their networks; using IPv6 however, virtually anyone can setup a SIP service. For this reason, both on your end and all the remotes you talk to, Codec Freedom enforces the use of IPv6.
Using the IP/UDP/RTP profile
The profile for IPv6/UDP/RTP is defined as follows:
Codec Freedom runs in R-mode, or bidirectional reliable mode, because connection profiles for communication work in both directions.
LARGE_CIDS is false, and MAX_CID is correspondingly set to TODO:15. Context Identifiers are sent in their short, one-byte form.
Codec Freedom uses the profile for IPv6/UDP/RTP 0x0101 from RFC 5225, and assigns to it the Context Identifier (CID) 0x00; this value is not actually sent, so by default frames are considered to fall under this Context Identifier. In return, all other forms will be explicitly marked.
TODO: Define MRRU?
It is advised to provide additional support for 0x0102 and 0x0103, respectively RoHCv2 UDP and RoHCv2 ESP.
Framing RoHC-compressed codecs
Codecs are now transmitted through Codec Freedom, where they arrive as IPv6/UDP/RTP packets. These are passed through RoHC, which compresses the packets. The outcome of the packets is relayed as-is over the escaped packet mode. This means that codec frames as they appear over the connection profile are in fact RoHC packets; they will start off by setting up the predictable patterns and then continue to send them without including the predictable information. This means that more room is made available for data transmission.
RoHC feedback is sent in the reverse direction, and serves to ensure the robustness of the compression mechanism. When codec frames return, they should be scanned for contained feedback. When nothing more is contained, the codec frame is discarded.