RFC 5456
IAX: Inter-Asterisk eXchange Version 2
7. Message Transport
IAX is sent over UDP and uses an application-level protocol to provide reliable transport where needed. With respect to transport, there are two message formats: reliable or 'Full Frames' and unacknowledged 'Mini' or 'Meta' frames. All messages except certain voice and video messages are reliable. Reliable messages are transported by a scheme that maintains message
counts and time-stamps for both peers involved in the call. The counts are per call. Each peer maintains a timer for all reliable messages and MUST periodically retransmit those messages until they acknowledge or the retry limit is exceeded. When starting a call, the outgoing and incoming message sequence numbers MUST both be set to zero. Each reliable message that is sent increments the message count by one except the ACK, INVAL, TXCNT, TXACC, and VNAK messages, which do not change the message count. The message includes the outgoing message count and the highest numbered incoming message that has been received. In addition, it contains a time-stamp that represents the number of milliseconds since the call started. Or, in the case of certain network timing messages, it contains a copy of the time-stamp sent to it. Time-stamps MAY be approximate, but, MUST be in order. When any message is received, the time-stamps MUST be checked to make sure that they are in order. If a message is received out of order, it MUST be ignored and a VNAK message sent to resynchronize the peers. If the message is a reliable message, the incoming message counter MUST be used to acknowledge all the messages up to that sequence number that have been sent. If no acknowledgment is received after a locally configured number of retries (default 4), the call leg SHOULD be considered unusable and the call MUST be torn down without any further interaction on this call leg.7.1. Trunking
IAX allows multiple media exchanges between the same two peers to be multiplexed into a single trunk call coalescing media payload into a combined packet. This decreases bandwidth usage as there are fewer total packets being transmitted. Trunking MAY occur in one or both directions of an IAX exchange. A trunk consists of a trunk header and one or more trunked IAX calls. The trunk message contains a time-stamp specifying the time of transmission of the trunk frame. The audio data from the trunked calls are encapsulated in the trunk frame following the header. Each trunked call consists of two octets specifying the call's source number, two octets specifying the length in octets of the media data, and the media data itself. IAX permits transmitting the time-stamps of each encapsulated Mini Frame as well, so that accurate timing information can be used for jitter buffers, etc. A flag in the meta command header specifies whether the encapsulated Mini Frames retain their original time-stamps. If they do not retain them, they MUST assume the time-stamp in the trunk header upon being received by the trunk peer.
7.2. Timers
There are various timers in the IAX protocol. There are other application-level timers, such as the call timer and ring timer, that are beyond the scope of this document. This section describes the IAX timers and specifies their default values and behaviors.7.2.1. Retransmission Timer
The message retransmission procedures are described in Section 7. On each call, there is a timer for how long to wait for an acknowledgment of a message. This timer starts at twice the measured Round-Trip Time from the last PING/PONG command. If a retransmission is needed, it is exponentially increased until it meets a boundary value. The maximum retry time period boundary is 10 seconds.7.2.2. Registration Period Timer
Registrations are valid for a specified time period. It is the client's responsibility to renew this registration before the time period expires. The registrations SHOULD be renewed at random intervals to prevent network congestion. A registrar MUST monitor this time period and invalidate the registration if the client/ registrant has not renewed their registration before the timer elapses.7.3. NAT Considerations
IAX is very well suited to operating behind NAT due to its single port approach. This approach eliminates any start of call media stream delays while the NAT gateway establishes a bidirectional port association. Deploying a single IAX server behind a NAT gateway requires little effort. If the server acts as a registrar, the IAX UDP port on the NAT gateway must be forwarded to the server. If the server acts as a registrant, the default, 60 second, REGREQ refresh timer should be sufficient to maintain a port association in the NAT gateway; however, a static port mapping is preferred. If multiple servers are to be deployed behind a single NAT gateway, most NAT gateways require each IAX server to use different UDP ports. Of course, there may be NAT implementations that recognize when multiple devices utilize the same private port and manage it appropriately.
7.4. Encryption
IAX supports call encryption using the symmetric key, Rijndael [AES] block cipher (also called AES -- Advanced Encryption Standard). Rijndael is a 128-bit block cipher utilizing a shared secret. IAX encrypts on a call-by-call basis starting with a plaintext NEW message indicating, in addition to the other message parameters, that the call should be encrypted. This indication is given by sending the ENCRYPTION IE (Section 8.6.34) in the NEW request message. If the called host supports encryption, it will respond with a plaintext AUTHREQ message that also includes the ENCRYPTION IE. All subsequent messages in the call MUST be encrypted. If the called host does not support encryption, the AUTHREQ sent in response to the NEW must not include the ENCRYPTION IE and the calling host MUST either HANGUP the request or continue with the unencrypted call. The key to use in encrypting the messages is computed by taking the CHALLENGE IE Section 8.6.14 from the AUTHREQ and concatenating any one of the shared passwords then computing the 128-bit MD5 digest of this combination. To decrypt, if there is more than one password for the peer, each must be tried until the message is successfully decoded. The key remains constant for the duration of the call. Only the data portion of the messages are encoded.8. Message Encoding
8.1. Frame Structure
This section contains the specification for each type of frame that IAX defines.8.1.1. Full Frames
Full Frames can send signaling or media data. Generally, Full Frames are used to control initiation, setup, and termination of an IAX call, but they can also be used to carry stream data (though this is generally not optimal). Full Frames are sent reliably, so all Full Frames require an immediate acknowledgment upon receipt. This acknowledgment can be explicit via an 'ACK' message (see Section 8.4) or implicit based upon receipt of an appropriate response to the Full Frame issued. The standard Full Frame header length is 12 octets.
Field descriptions:
'F' bit
This bit specifies whether or not the frame is a Full Frame. If
the 'F' bit is set to 1, the frame is a Full Frame. If it is set
to 0, it is not a Full Frame.
Source call number
This 15-bit value specifies the call number the transmitting
client uses to identify this call. The source call number for an
active call MUST NOT be in use by another call on the same client.
Call numbers MAY be reused once a call is no longer active, i.e.,
either when there is positive acknowledgment that the call has
been destroyed or when all possible timeouts for the call have
expired.
'R' bit
This bit specifies whether or not the frame is being
retransmitted. If the 'R' bit is set to 0, the frame is being
transmitted for the first time. If it is set to 1, the frame is
being retransmitted. IAX does not specify a retransmit timeout;
this is left to the implementor.
Destination call number
This 15-bit value specifies the call number the transmitting
client uses to reference the call at the remote peer. This number
is the same as the remote peer's source call number. The
destination call number uniquely identifies a call on the remote
peer. The source call number uniquely identifies the call on the
local peer.
Time-stamp
The time-stamp field contains a 32-bit time-stamp maintained by an
IAX peer for a given call. The time-stamp is an incrementally
increasing representation of the number of milliseconds since the
first transmission of the call.
OSeqno
The 8-bit OSeqno field is the outbound stream sequence number.
Upon initialization of a call, its value is 0. It increases
incrementally as Full Frames are sent. When the counter
overflows, it silently resets to 0.
ISeqno
The 8-bit ISeqno field is the inbound stream sequence number.
Upon initialization of a call, its value is 0. It increases
incrementally as Full Frames are received. At any time, the
ISeqno of a call represents the next expected inbound stream
sequence number. When the counter overflows, it silently resets
to 0.
Frametype
The Frametype field identifies the type of message carried by the
frame. See Section 8.2 for more information.
'C' bit
This bit determines how the remaining 7 bits of the Subclass field
are coded. If the 'C' bit is set to 1, the Subclass value is
interpreted as a power of 2. If it is not set, the Subclass value
is interpreted as a simple 7-bit unsigned integer.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSeqno | ISeqno | Frame Type |C| Subclass |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Full Frame Binary Format
8.1.2. Mini Frames
Mini Frames are so named because their header is a minimal 4 octets.
Mini Frames carry no control or signaling data; their sole purpose is
to carry a media stream on an already-established IAX call. They are
sent unreliably. This decision was made because VoIP calls typically
can miss several frames without significant degradation in call
quality while the incurred overhead in ensuring reliability increases
bandwidth requirements and decreases throughput. Further, because
voice calls are typically sent in real time, lost frames are too old
to be reintegrated into the audio stream by the time they can be
retransmitted.
Field descriptions:
'F' bit
Mini Frames MUST have the 'F' bit set to 0 to specify that they
are not Full Frames.
Source call number
The source call number is the number that is used by the
transmitting peer to identify the current call.
time-stamp
Mini frames carry a 16-bit time-stamp, which is the lower 16 bits
of the transmitting peer's full 32-bit time-stamp for the call.
The time-stamp allows synchronization of incoming frames so that
they MAY be processed in chronological order instead of the
(possibly different) order in which they are received. The 16-bit
time-stamp wraps after 65.536 seconds, at which point a full frame
SHOULD be sent to notify the remote peer that its time-stamp has
been reset. A call MUST continue to send mini frames starting
with time-stamp 0 even if acknowledgment of the resynchronization
is not received.
The F bit, source call number, and 16-bit time-stamp comprise the
entire 4-octet header for a full frame. Following this header is the
actual stream data, of arbitrary length, up to the maximum supported
by the network.
Mini frames are implicitly defined to be of type 'voice frame'
(frametype 2; see Section 8.2). The subclass is implicitly defined
by the most recent full voice frame of a call (i.e. the subclass for
a voice frame specifies the CODEC used with the stream). The first
voice frame of a call SHOULD be sent using the CODEC agreed upon in
the initial CODEC negotiation. On-the-fly CODEC negotiation is
permitted by sending a full voice frame specifying the new CODEC to
use in the subclass field.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Source call number | time-stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Data : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Mini Frame Binary Format8.1.3. Meta Frames
Meta frames serve one of two purposes. Meta video frames allow the transmission of video streams with an optimized header. They are similar in purpose to mini voice frames. Meta trunk frames are used for trunking multiple IAX media streams between two peers into one header, to further minimize bandwidth consumption.8.1.3.1. Meta Video Frames
Field descriptions: 'F' bit Meta video frames MUST have the 'F' bit set to 0 to indicate that they are not full frames. Meta Indicator The meta indicator is a 15-bit field of all zeroes, used to indicate that the frame is a Meta Frame. Meta Frames are identifiable because the first 16 bits will always be zero in any Meta Frame, whereas Full or Mini Frames will have either the 'F' bit set or some (nonzero) value for the source call number (or both). 'V' bit The 'V' bit in a meta video frame is set to 1 to specify that the frame is a meta video frame. Source call number The call number that is used by the transmitting peer to identify this video call.
time-stamp
Meta video frames carry a 16-bit time-stamp, which is the lower 16
bits of the transmitting peer's full 32-bit time-stamp for the
call. When this time-stamp wraps, a Full Frame SHOULD be sent to
notify the remote peer that the time-stamp has been reset to 0.
Following the time-stamp is the actual video stream data. Meta video
frames are implicitly defined to be of type 'video frame' (frametype
3; see Section 8.2). The video CODEC used is implicitly defined by
the subclass of the most recent full video frame of a call.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|?| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Meta Video Frame Binary Format
8.1.3.2. Meta Trunk Frames
IAX natively supports two methods of trunking multiple media streams
between two peers into a single association. The first method sends
a standard meta header, along with a single 32-bit time-stamp
describing the transmission time of the trunk frame. Following the
time-stamp are one or more media frames consisting of the call number
and the length in octets of the stream data included in the frame.
The second method of trunking is very similar to the first. It sends
a standard meta header, including the 32-bit time-stamp describing
the time of transmission of the trunk frame. But the media frames
included in the trunk are actually complete Mini Frames, including
the 16-bit time-stamp for each call. The first method uses slightly
less bandwidth (2 fewer octets per call in the trunk), while the
second method maintains the individual time-stamps for each call so
that jitter buffering can use the actual time-stamps associated with
a call instead of the (less accurate) time-stamp representing the
entire trunk. Either method is permissible for trunking.
Field descriptions:
'F' bit
Meta trunk frames MUST have the 'F' bit set to 0 to indicate that
they are not Full Frames.
Meta Indicator
The meta indicator is a 15-bit field of all zeroes, used to
indicate that the frame is a Meta Frame. Meta Frames are
identifiable because the first 16 bits will always be zero in any
Meta Frame, whereas Full or Mini Frames will have either the 'F'
bit set or some (nonzero) value for the source call number (or
both).
'V' bit
The 'V' bit in a meta trunk frame is set to 0 to specify that the
frame is not a meta video frame.
Meta Command
This 7-bit field identifies whether or not the Meta Frame is a
trunk. A value of '1' indicates that the frame is a meta trunk
frame. All other values are reserved for future use. See the
IANA Registry for additional IAX Meta Command Assignments.
Command Data
This 8-bit field specifies flags for options that apply to a
trunked call. The least significant bit of the field is the
'trunk time-stamps' flag. A value of 0 indicates that the calls
in the trunk do not include their individual time-stamps. A value
of 1 indicates that the calls do each include their own time-
stamp. All other bits are reserved for future use.
time-stamp
Meta trunk frames carry a 32-bit time-stamp, which represents the
actual time of transmission of the trunk frame. This is distinct
from the time-stamps of the calls included in the trunk.
Following the 32-bit time-stamp is one or more trunked calls. If the
'trunk time-stamps' flag is set to 0, each entry consists of 2 octets
specifying the source call number of the call, 2 octets specifying
the length in octets of the media data, and then the media data. If
the 'trunk time-stamps' flag is set to 1, each entry consists of 2
octets specifying the length in octets of the media data, and then a Mini Frame (2 octets specifying source call number, 2 octets specifying 16-bit time-stamp, and the media data). The following two diagrams help illustrate this structure. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Meta Indicator |V|Meta Command | Cmd Data (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time-stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Source Call Number | Data Length (in octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Data : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Source Call Number | Data Length (in octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Data : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Meta Trunk Frame Binary Format (trunk time-stamps 0)
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Meta Indicator |V|Meta Command | Cmd Data (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time-stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Length (in octets) |R| Source Call Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time-stamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Data | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Length (in octets) |R| Source Call Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time-stamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Data | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Meta Trunk Frame Binary Format (trunk time-stamps 1)8.1.4. Encrypted Frames
All of the above frames may be encrypted. The header call numbers are passed through in the clear, first 4 bytes for a Full Frame or 2 bytes for a Mini Frame. The remainder of the frame is padded with between 16 and 32 bytes of random data, then encrypted with AES each block being XOR'd with the previous block. The padding is added at the front of the data. Figure 10 shows a padded Full Frame before encryption, and Figure 11 shows the frame after encryption. Other frame types follow the same procedure, except the cleartext portion is shorter, as described above.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Source Call Number |R| Destination Call Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12 Random bytes | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 28 Random bits |padding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : between 0 and 15 (as indicated by the padding field above) : : Random bytes : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Remainder of Actual Frame : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Full Frame before encryption Since AES requires a 16 byte block size, some padding is essential. This padding has been placed at the beginning of the payload because it makes it more difficult to take advantage of the predictability of the IAX frame header. For example, the first encrypted Frame an IAX client sends within an incoming IAX call is entirely predictable: It is always an ACK - where even the time-stamp is guessable as it is the time the AUTHREP packet was sent. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Source Call Number |R| Destination Call Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted data | | Multiple of 16 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Frame after encryption The same encryption rules apply to the Mini Frames, except that the initial unencrypted portion is only 2 bytes.
8.2. Frame Types
The IAX protocol specifies 10 types of possible frames for the "frametype" field of a Full Frame. They are described in the following subsections.8.2.1. DTMF Frame
The frame carries a single digit of DTMF (Dual Tone Multi-Frequency). More information about DTMF can be found in RFC 4733 [RFC4733] and [RFC4734]. For DTMF frames, the subclass is the actual DTMF digit carried by the frame.8.2.2. Voice Frame
The frame carries voice data. The subclass specifies the audio format of the data. Predefined voice formats can be found in Section 8.7.8.2.3. Video Frame
The frame carries video data. The subclass specifies the video format of the data. Predefined video formats can be found in Section 8.7.8.2.4. Control Frame
The frame carries session control data, i.e., it refers to control of a device connected to an IAX endpoint. The subclass is a value from Section 8.3 describing the device control signal.8.2.5. Null Frame
Frames with the Null value MUST NOT be transmitted.8.2.6. IAX Frame
The frame carries control data that provides IAX protocol-specific endpoint management. This frametype is used to manage IAX protocol interactions that are generally independent of the type of endpoints. The subclass is a value from Section 8.4 describing an IAX event.
8.2.7. Text Frame
The frame carries a non-control text message in UTF-8 [RFC3629] format. All text frames have a subclass of 0.8.2.8. Image Frame
The frame carries a single image. The subclass describes the format of the image from Section 8.7.8.2.9. HTML Frame
The frame carries HTML data. The subclass is a value from the HTML Subclasses table in Section 8.5.
8.2.10. Comfort Noise Frame
The frame carries comfort noise. The subclass is the level of comfort noise in -dBov. The following table specifies valid Frame Type Values: +------+-------------+--------------------------+-------------------+ | TYPE | Description | Subclass Description | Data Description | +------+-------------+--------------------------+-------------------+ | 0x01 | DTMF | 0-9, A-D, *, # | Undefined | | | | | | | 0x02 | Voice | Audio Compression Format | Data | | | | | | | 0x03 | Video | Video Compression Format | Data | | | | | | | 0x04 | Control | See Control Frame Types | Varies with | | | | | subclass | | | | | | | 0x05 | Null | Undefined | Undefined | | | | | | | 0x06 | IAX Control | See IAX Protocol | Information | | | | Messages | Elements | | | | | | | 0x07 | Text | Always 0 | Raw Text | | | | | | | 0x08 | Image | Image Compression Format | Raw image | | | | | | | 0x09 | HTML | See HTML Frame Types | Message Specific | | | | | | | 0x0A | Comfort | Level in -dBov of | None | | | Noise | comfort noise | | +------+-------------+--------------------------+-------------------+ Refer to the IANA Registry for additional IAX Frame Type values.
8.3. Control Frames Subclasses
The following table specifies valid Control Frame Subclasses: +-------------+---------------+-------------------------------------+ | VALUE | Name | Description | +-------------+---------------+-------------------------------------+ | 0x01 | Hangup | The call has been hungup at the | | | | remote end | | | | | | 0x02 | Reserved | Reserved for future use | | | | | | 0x03 | Ringing | Remote end is ringing (ring-back) | | | | | | 0x04 | Answer | Remote end has answered | | | | | | 0x05 | Busy | Remote end is busy | | | | | | 0x06 | Reserved | Reserved for future use | | | | | | 0x07 | Reserved | Reserved for future use | | | | | | 0x08 | Congestion | The call is congested | | | | | | 0x09 | Flash Hook | Flash hook | | | | | | 0x0a | Reserved | Reserved for future use | | | | | | 0x0b | Option | Device-specific options are being | | | | transmitted | | | | | | 0x0c | Key Radio | Key Radio | | | | | | 0x0d | Unkey Radio | Unkey Radio | | | | | | 0x0e | Call Progress | Call is in progress | | | | | | 0x0f | Call | Call is proceeding | | | Proceeding | | | | | | | 0x10 | Hold | Call is placed on hold | | | | | | 0x11 | Unhold | Call is taken off hold | +-------------+---------------+-------------------------------------+ Refer to the IANA Registry for additional IAX Control Frame Subclass values.
8.4. IAX Frames
Frames of type 'IAX' are used to provide management of IAX endpoints. They handle IAX signaling (e.g., call setup, maintenance, and tear- down). They MAY also handle direct transmission of media data, but this is not optimal for VoIP calls. They do not carry session- specific control (e.g., device state), as this is the purpose of Control Frames. The IAX commands are listed and described below. The following table specifies all valid IAX Frame values: +------+-----------+-----------------------------------------+ | Hex | Name | Description | +------+-----------+-----------------------------------------+ | 0x01 | NEW | Initiate a new call | | | | | | 0x02 | PING | Ping request | | | | | | 0x03 | PONG | Ping or poke reply | | | | | | 0x04 | ACK | Explicit acknowledgment | | | | | | 0x05 | HANGUP | Initiate call tear-down | | | | | | 0x06 | REJECT | Reject a call | | | | | | 0x07 | ACCEPT | Accept a call | | | | | | 0x08 | AUTHREQ | Authentication request | | | | | | 0x09 | AUTHREP | Authentication reply | | | | | | 0x0a | INVAL | Invalid message | | | | | | 0x0b | LAGRQ | Lag request | | | | | | 0x0c | LAGRP | Lag reply | | | | | | 0x0d | REGREQ | Registration request | | | | | | 0x0e | REGAUTH | Registration authentication | | | | | | 0x0f | REGACK | Registration acknowledgement | | | | | | 0x10 | REGREJ | Registration reject | | | | | | 0x11 | REGREL | Registration release | | | | |
| 0x12 | VNAK | Video/Voice retransmit request |
| | | |
| 0x13 | DPREQ | Dialplan request |
| | | |
| 0x14 | DPREP | Dialplan reply |
| | | |
| 0x15 | DIAL | Dial |
| | | |
| 0x16 | TXREQ | Transfer request |
| | | |
| 0x17 | TXCNT | Transfer connect |
| | | |
| 0x18 | TXACC | Transfer accept |
| | | |
| 0x19 | TXREADY | Transfer ready |
| | | |
| 0x1a | TXREL | Transfer release |
| | | |
| 0x1b | TXREJ | Transfer reject |
| | | |
| 0x1c | QUELCH | Halt audio/video [media] transmission |
| | | |
| 0x1d | UNQUELCH | Resume audio/video [media] transmission |
| | | |
| 0x1e | POKE | Poke request |
| | | |
| 0x1f | Reserved | Reserved for future use |
| | | |
| 0x20 | MWI | Message waiting indication |
| | | |
| 0x21 | UNSUPPORT | Unsupported message |
| | | |
| 0x22 | TRANSFER | Remote transfer request |
| | | |
| 0x23 | Reserved | Reserved for future use |
| | | |
| 0x24 | Reserved | Reserved for future use |
| | | |
| 0x25 | Reserved | Reserved for future use |
+------+-----------+-----------------------------------------+
Refer to the IANA Registry for additional IAX Frame values.
8.5. HTML Command Subclasses
IAX HTML Command Subclasses: +--------+----------------------------+ | NUMBER | DESCRIPTION | +--------+----------------------------+ | 0x01 | Sending a URL | | | | | 0x02 | Data frame | | | | | 0x04 | Beginning frame | | | | | 0x08 | End frame | | | | | 0x10 | Load is complete | | | | | 0x11 | Peer does not support HTML | | | | | 0x12 | Link URL | | | | | 0x13 | Unlink URL | | | | | 0x14 | Reject Link URL | +--------+----------------------------+ Refer to the IANA Registry for additional IAX HTML Command Subclass values.
(page 58 continued on part 4)
