tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5456

 
 
 

IAX: Inter-Asterisk eXchange Version 2

Part 3 of 5, p. 39 to 58
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 39 
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

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
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.

Top      Up      ToC       Page 42 
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.

Top      Up      ToC       Page 43 
   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.

Top      Up      ToC       Page 44 
   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

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
                        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 Format

8.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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
   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

Top      Up      ToC       Page 49 
   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)

Top      Up      ToC       Page 50 
                        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.

Top      Up      ToC       Page 51 
                        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.

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
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.

Top      Up      ToC       Page 54 
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.

Top      Up      ToC       Page 55 
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.

Top      Up      ToC       Page 56 
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                    |
      |      |           |                                         |

Top      Up      ToC       Page 57 
      | 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.

Top      Up      ToC       Page 58 
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)

Next RFC Part