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 4 of 5, p. 58 to 87
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
8.6.  Information Elements

   IAX messages sent as Full Frames MAY carry information elements to
   specify user- or call-specific data.  Information elements are
   appended to a frame header in its data field.  Zero, one, or multiple
   information elements MAY be included with any IAX message.

   Information elements are coded as follows:

      The first octet of any information element consists of the "IE"
      field.  The IE field is an identification number that defines the
      particular information element.  Table 1 lists the defined
      information elements and each information element is defined below
      the table.

      The second octet of any information element is the "data length"
      field.  It specifies the length in octets of the information
      element's data field.

Top      Up      ToC       Page 59 
      The remaining octet(s) of an information element contain the
      actual data being transmitted.  The representation of the data is
      dependent on the particular information element as identified by
      its "IE" field.  Some information elements carry binary data, some
      carry UTF-8 [RFC3629] data, and some have no data field at all.
      Elements that carry UTF-8 MUST prepare strings as per [RFC3454]
      and [RFC3491], so that illegal characters, case folding, and other
      characters properties are handled and compared properly.  The data
      representation for each information element is described below.

   The following table specifies the Information Element Binary Format:

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      IE       |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :             DATA              :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following is a table of the information elements IAX defines, and
   a brief description of each information element's purpose.  More
   information about each IE may be found below the table.

   +------+----------------+-------------------------------------------+
   | HEX  | NAME           | DESCRIPTION                               |
   +------+----------------+-------------------------------------------+
   | HEX  | NAME           | DESCRIPTION                               |
   | 0x01 | CALLED NUMBER  | Number/extension being called             |
   | 0x02 | CALLING NUMBER | Calling number                            |
   | 0x03 | CALLING ANI    | Calling number ANI for billing            |
   | 0x04 | CALLING NAME   | Name of caller                            |
   | 0x05 | CALLED CONTEXT | Context for number                        |
   | 0x06 | USERNAME       | Username (peer or user) for               |
   |      |                | authentication                            |
   | 0x07 | PASSWORD       | Password for authentication               |
   | 0x08 | CAPABILITY     | Actual CODEC capability                   |
   | 0x09 | FORMAT         | Desired CODEC format                      |
   | 0x0a | LANGUAGE       | Desired language                          |
   | 0x0b | VERSION        | Protocol version                          |
   | 0x0c | ADSICPE        | CPE ADSI capability                       |
   | 0x0d | DNID           | Originally dialed DNID                    |
   | 0x0e | AUTHMETHODS    | Authentication method(s)                  |
   | 0x0f | CHALLENGE      | Challenge data for MD5/RSA                |
   | 0x10 | MD5 RESULT     | MD5 challenge result                      |
   | 0x11 | RSA RESULT     | RSA challenge result                      |

Top      Up      ToC       Page 60 
   | 0x12 | APPARENT ADDR  | Apparent address of peer                  |
   | 0x13 | REFRESH        | When to refresh registration              |
   | 0x14 | DPSTATUS       | Dialplan status                           |
   | 0x15 | CALLNO         | Call number of peer                       |
   | 0x16 | CAUSE          | Cause                                     |
   | 0x17 | IAX UNKNOWN    | Unknown IAX command                       |
   | 0x18 | MSGCOUNT       | How many messages waiting                 |
   | 0x19 | AUTOANSWER     | Request auto-answering                    |
   | 0x1a | MUSICONHOLD    | Request musiconhold with QUELCH           |
   | 0x1b | TRANSFERID     | Transfer Request Identifier               |
   | 0x1c | RDNIS          | Referring DNIS                            |
   | 0x1d | Reserved       | Reserved for future use                   |
   | 0x1e | Reserved       | Reserved for future use                   |
   | 0x1f | DATETIME       | Date/Time                                 |
   | 0x20 | Reserved       | Reserved for future use                   |
   | 0x21 | Reserved       | Reserved for future use                   |
   | 0x22 | Reserved       | Reserved for future use                   |
   | 0x23 | Reserved       | Reserved for future use                   |
   | 0x24 | Reserved       | Reserved for future use                   |
   | 0x25 | Reserved       | Reserved for future use                   |
   | 0x26 | CALLINGPRES    | Calling presentation                      |
   | 0x27 | CALLINGTON     | Calling type of number                    |
   | 0x28 | CALLINGTNS     | Calling transit network select            |
   | 0x29 | SAMPLINGRATE   | Supported sampling rates                  |
   | 0x2a | CAUSECODE      | Hangup cause                              |
   | 0x2b | ENCRYPTION     | Encryption format                         |
   | 0x2c | ENCKEY         | Reserved for future Use                   |
   | 0x2d | CODEC PREFS    | CODEC Negotiation                         |
   | 0x2e | RR JITTER      | Received jitter, as in RFC 3550           |
   | 0x2f | RR LOSS        | Received loss, as in RFC 3550             |
   | 0x30 | RR PKTS        | Received frames                           |
   | 0x31 | RR DELAY       | Max playout delay for received frames in  |
   |      |                | ms                                        |
   | 0x32 | RR DROPPED     | Dropped frames (presumably by jitter      |
   |      |                | buffer)                                   |
   | 0x33 | RR OOO         | Frames received Out of Order              |
   | 0x34 | OSPTOKEN       | OSP Token Block                           |
   +------+----------------+-------------------------------------------+

                 Table 1: Information Element Definitions

   Refer to the IANA Registry for additional IAX Information Element
   values.

Top      Up      ToC       Page 61 
8.6.1.  CALLED NUMBER

   The purpose of the CALLED NUMBER information element is to indicate
   the number or extension being called.  It carries UTF-8-encoded data.
   The CALLED NUMBER information element MUST use UTF-8 encoding and not
   numeric data because destinations are not limited to E.164 numbers
   ([E164]), national numbers, or even digits.  It is possible for a
   number or extension to include non-numeric characters.  The CALLED
   NUMBER IE MAY contain a SIP URI, [RFC3261] or a URI in any other
   format.  The ability to serve a CALLED NUMBER is server dependent.

   The CALLED NUMBER information element is generally sent with IAX NEW,
   DPREQ, DPREP, DIAL, and TRANSFER messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x01     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :  UTF-8-encoded CALLED NUMBER  :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.2.  CALLING NUMBER

   The purpose of the CALLING NUMBER information element is to indicate
   the number or extension of the calling entity to the remote peer.  It
   carries UTF-8-encoded data.

   The CALLING NUMBER information element is usually sent with IAX NEW
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x02     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   : UTF-8-encoded CALLING NUMBER  :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.3.  CALLING ANI

   The purpose of the CALLING ANI information element is to indicate the
   calling number ANI (Automatic Number Identification) for billing.  It
   carries UTF-8-encoded data.

Top      Up      ToC       Page 62 
   The CALLING ANI information element MAY be sent with an IAX NEW
   message, but it is not required.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x03     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :   UTF-8-encoded CALLING ANI   :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.4.  CALLING NAME

   The purpose of the CALLING NAME information element is to indicate
   the calling name of the transmitting peer.  It carries UTF-8-encoded
   data.

   The CALLING NAME information element is usually sent with IAX NEW
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x04     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :   UTF-8-encoded CALLING NAME  :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.5.  CALLED CONTEXT

   The purpose of the CALLED CONTEXT information element is to indicate
   the context (or partition) of the remote peer's dialplan that the
   CALLED NUMBER is interpreted.  It carries UTF-8-encoded data.

   The CALLED CONTEXT information element MAY be sent with IAX NEW or
   TRANSFER messages, though it is not required.

Top      Up      ToC       Page 63 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x05     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   : UTF-8-encoded CALLED CONTEXT  :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.6.  USERNAME

   The purpose of the USERNAME information element is to specify the
   identity of the user participating in an IAX message exchange.  It
   carries UTF-8-encoded data.

   The USERNAME information element MAY be sent with IAX NEW, AUTHREQ,
   REGREQ, REGAUTH, or REGACK messages, or any time a peer needs to
   identify a user.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x06     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :     UTF-8-encoded USERNAME    :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.7.  CAPABILITY

   The purpose of the CAPABILITY information element is to indicate the
   media CODEC capabilities of an IAX peer.  Its data is represented in
   a 4-octet bitmask according to Section 8.7.  Multiple CODECs MAY be
   specified by logically OR'ing them into the CAPABILITY information
   element.

   The CAPABILITY information element is sent with IAX NEW messages if
   appropriate for the CODEC negotiation method the peer is using.

Top      Up      ToC       Page 64 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x08     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CAPABILITY according to Media |
   | Format Subclass Values Table  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.8.  FORMAT

   The purpose of the FORMAT information element is to indicate a single
   preferred media CODEC.  When sent with a NEW message, the indicated
   CODEC is the desired CODEC an IAX peer wishes to use for a call.
   When sent with an ACCEPT message, it indicates the actual CODEC that
   has been selected for the call.  Its data is represented in a 4-octet
   bitmask according to Section 8.7.  Only one CODEC MUST be specified
   in the FORMAT information element.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x09     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   FORMAT according to Media   |
   | Format Subclass Values Table  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.9.  LANGUAGE

   The purpose of the LANGUAGE information element is to indicate the
   language in which the transmitting peer would like the remote peer to
   send signaling information.  It carries UTF-8-encoded data and tags
   should be selected per [RFC5646] and [RFC4647].

   The LANGUAGE information element MAY be sent with an IAX NEW message.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0a     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :     UTF-8-encoded LANGUAGE    :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 65 
8.6.10.  VERSION

   The purpose of the VERSION information element is to indicate the
   protocol version the peer is using.  Peers at each end of a call MUST
   use the same protocol version.  Currently, the only supported version
   is 2.  The data field of the VERSION information element is 2 octets
   long.

   The VERSION information element MUST be sent with an IAX NEW message.

   When sent, the VERSION information element MUST be the first IE in
   the message.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0b     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0002             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.11.  ADSICPE

   The purpose of the ADSICPE information element is to indicate the CPE
   (Customer Premises Equipment) ADSI (Analog Display Services
   Interface) capability.  The data field of the ADSICPE information
   element is 2 octets long.

   The ADSICPE information element MAY be sent with an IAX NEW message.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0c     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       ADSICPE Capability      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.12.  DNID

   The purpose of the DNID information element is to indicate the Dialed
   Number ID, which may differ from the 'called number'.  It carries
   UTF-8-encoded data.

   The DNID information element MAY be sent with an IAX NEW message.

Top      Up      ToC       Page 66 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0d     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :    UTF-8-encoded DNID Data    :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.13.  AUTHMETHODS

   The purpose of the AUTHMETHODS information element is to indicate the
   authentication methods a peer accepts.  It is sent as a bitmask two
   octets long.  The table below lists the valid authentication methods.

   The AUTHMETHODS information element MUST be sent with IAX AUTHREQ and
   REGAUTH messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0e     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Valid Authentication Methods |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following table lists valid values for authentication:

                   +--------+--------------------------+
                   | METHOD | DESCRIPTION              |
                   +--------+--------------------------+
                   | 0x0001 | Reserved (was Plaintext) |
                   |        |                          |
                   | 0x0002 | MD5                      |
                   |        |                          |
                   | 0x0004 | RSA                      |
                   +--------+--------------------------+

   Refer to the IANA Registry for additional IAX Authentication Method
   values.

8.6.14.  CHALLENGE

   The purpose of the CHALLENGE information element is to offer the MD5
   or RSA challenge to be used for authentication.  It carries the
   actual UTF-8-encoded challenge data.

Top      Up      ToC       Page 67 
   The CHALLENGE information element MUST be sent with IAX AUTHREQ and
   REGAUTH messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0f     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :  UTF-8-encoded Challenge Data :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.15.  MD5 RESULT

   The purpose of the MD5 RESULT information element is to offer an MD5
   response to an authentication CHALLENGE.  It carries the UTF-8-
   encoded challenge result.  The MD5 Result value is computed by taking
   the MD5 [RFC1321] digest of the challenge string and the password
   string.

   The MD5 RESULT information element MAY be sent with IAX AUTHREP and
   REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE
   has been received.  This information element MUST NOT be sent except
   in response to a CHALLENGE.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x10      |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :    UTF-8-encoded MD5 Result   :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.16.  RSA RESULT

   The purpose of the RSA RESULT information element is to offer an RSA
   response to an authentication CHALLENGE.  It carries the UTF-8-
   encoded challenge result.  The result is computed as follows: first,
   compute the SHA1 digest [RFC3174] of the challenge string and second,
   RSA sign the SHA1 digest using the private RSA key as specified in
   PKCS #1 v2.0 [PKCS].  The RSA keys are stored locally.

   Upon receiving an RSA RESULT information element, its value must be
   verified with the sender's public key to match the SHA1 digest
   [RFC3174] of the challenge string.

Top      Up      ToC       Page 68 
   The RSA RESULT information element MAY be sent with IAX AUTHREP and
   REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE
   have been received.  This information element MUST NOT be sent except
   in response to a CHALLENGE.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x11     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :    UTF-8-encoded RSA Result   :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.17.  APPARENT ADDR

   The purpose of the APPARENT ADDR information element is to indicate
   the perceived network connection information used to reach a peer,
   which may differ from the actual address when the peer is behind NAT.
   The APPARENT ADDR IE is populated using the source address values of
   the UDP and IP headers in the IAX message to which this response is
   generated.  The data field of the APPARENT ADDR information element
   is the same as the POSIX sockaddr struct for the address family in
   use (i.e., sockaddr_in for IPv4, sockaddr_in6 for IPv6).  The data
   length depends on the type of address being represented.

   The APPARENT ADDR information element MUST be sent with IAX TXREQ and
   REGACK messages.  When used with a TXREQ message, the APPARENT ADDR
   MUST specify the address of the peer to which the local peer is
   trying to transfer its end of the connection.  When used with a
   REGACK message, the APPARENT ADDR MUST specify the address it uses to
   reach the peer (which may be different than the address the peer
   perceives itself as in the case of NAT or multi-homed peer machines).

   The data field of the APPARENT ADDR information element is the same
   as the Linux struct sockaddr_in: two octets for the address family,
   two octets for the port number, four octets for the IPv4 address, and
   8 octets of padding consisting of all bits set to 0.  Thus, the total
   length of the APPARENT ADDR information element is 18 octets.

   The following diagram demonstrates the generic APPARENT ADDR format:

Top      Up      ToC       Page 69 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        sockaddr struct        |
   :   for address family in use   :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following diagram demonstrates the APPARENT ADDR format for an
   IPv4 address:

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |      0x10     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0200             | <- Address family (INET)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x11d9             | <- Portno (default 4569)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      32-bit IP address        |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   |      8 octets of all 0s       |
   |   (padding in sockaddr_in)    |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 70 
   The following diagram demonstrates the APPARENT ADDR format for an
   IPv6 address:

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |      0x1C     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0A00             | <- Address family (INET6)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x11d9             | <- Portno (default 4569)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           32 bits             | <- Flow information
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      128-bit IP address       | <- Ip6 Address
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           32 bits             | <- Scope ID
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.18.  REFRESH

   The purpose of the REFRESH information element is to indicate the
   number of seconds before an event expires.  Its data field is 2
   octets long.

   The REFRESH information element is used with IAX REGREQ, REGACK, and
   DPREP messages.  When sent with a REGREQ, it is a request that the
   peer maintaining the registration set the timeout to REFRESH seconds.
   When sent with a DPREP or REGACK, it is informational and tells a
   remote peer when the local peer will no longer consider the event
   valid.  The REFRESH sent with a DPREP tells a peer how long it SHOULD
   store the received dialplan response.

   If the REFRESH information element is not received with a DPREP, the
   expiration of the cache data is assumed to be 10 minutes.  If the
   REFRESH information element is not received with a REGACK,
   registration expiration is assumed to occur after 60 seconds.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x13     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  2 octets specifying refresh  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 71 
8.6.19.  DPSTATUS

   The purpose of the DPSTATUS information element is to indicate the
   status of a CALLED NUMBER in a remote dialplan.  Its data field is a
   2-octet bitmask specifying flags from the table below.  Exactly one
   of the low 3 bits MUST be set, and zero, 1, or 2 of the high 2 bits
   MAY be set.

   The DPSTATUS information element MUST be sent with IAX DPREP
   messages, as it is the payload of the dialplan response.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x14     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|                     |N|C|E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following table lists the dialplan status flags:

                 +--------+------------------------------+
                 | FLAG   | DESCRIPTION                  |
                 +--------+------------------------------+
                 | 0x0001 | Exists                       |
                 |        |                              |
                 | 0x0002 | Can exist                    |
                 |        |                              |
                 | 0x0004 | Non-existent                 |
                 |        |                              |
                 | 0x4000 | Retain dialtone (ignorepat)  |
                 |        |                              |
                 | 0x8000 | More digits may match number |
                 +--------+------------------------------+

   Refer to the IANA Registry for additional IAX dialplan status values.

8.6.20.  CALLNO

   The purpose of the CALLNO information element is to indicate the call
   number a remote peer needs to use as a destination call number to
   identify a call being transferred.  The peer managing a transfer
   sends the CALLNO for one transfer endpoint to the other transfer
   endpoint so that it knows what call number to specify for the
   transfer.  The data field is 2 octets long and specifies a call
   number in the same manner as a source call number or destination call
   number is specified in a frame header.

Top      Up      ToC       Page 72 
   The CALLNO information element MUST be sent with IAX TXREQ, TXREADY,
   and TXREL messages.  Transferring cannot succeed if the CALLNO IE is
   not included with the appropriate transfer messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x15      |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Callno of transfer recipient |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.21.  CAUSE

   The purpose of the CAUSE information element is to indicate the
   reason an event occurred.  It carries a description of the CAUSE of
   the event as UTF-8-encoded data.  Notification of the event itself is
   handled at the message level.

   The CAUSE information element SHOULD be sent with IAX HANGUP, REJECT,
   REGREJ, and TXREJ messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x16     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :  UTF-8-encoded CAUSE of event :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.22.  IAX UNKNOWN

   The purpose of the IAX UNKNOWN information element is to indicate
   that a received IAX command was unknown or unrecognized.  The 1-octet
   data field contains the subclass of the received frame that was
   unrecognized.

   The IAX UNKNOWN information element MUST be sent with IAX UNSUPPORT
   messages.

Top      Up      ToC       Page 73 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x17     |      0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rec'd Subclass|
   +-+-+-+-+-+-+-+-+

8.6.23.  MSGCOUNT

   The purpose of the MSGCOUNT information element is to indicate how
   many voicemail messages are waiting in a registered user's mailbox.
   The data field is 2 octets long.  If it is set to all 1s, there is at
   least one message present.  Any other value specifies the number of
   old messages in the high 8 bits and the number of new messages in the
   low 8 bits.

   The IAX MSGCOUNT information element MAY be sent with IAX REGACK
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x18     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Old messages |  New messages |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.24.  AUTOANSWER

   The purpose of the AUTOANSWER information element is to request that
   a call be auto-answered upon receipt of a NEW message that includes
   the AUTOANSWER information element.  Note that this is a request and
   may or may not be granted by the remote peer.  There is no data field
   with this information element, as its presence alone indicates all
   necessary information.

   The AUTOANSWER information element MAY be sent with IAX NEW messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x19     |      0x00     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 74 
8.6.25.  MUSICONHOLD

   The purpose of the MUSICONHOLD information element is to request that
   music-on-hold be played while a call is in the QUELCH state.  The
   optional data field specifies a music-on-hold class to be used, as
   UTF-8-encoded data.  In the absence of a data field, no music-on-hold
   class is specified and the IE SHOULD be treated as a generic request
   for music-on-hold.

   The MUSICONHOLD information element MAY be sent with IAX QUELCH
   messages.

   If no MUSICONHOLD information element is received, music-on-hold is
   not requested.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x1a     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :  Optional Music On Hold Class :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.26.  TRANSFERID

   The purpose of the TRANSFERID information element is to identify a
   transfer across all three peers participating in a transfer event.
   It carries a number, four octets long, that SHOULD be unique for the
   duration of the transfer process.

   The TRANSFERID information element SHOULD be sent with IAX TXREQ and
   TXCNT messages to aid the peers involved in a transfer in identifying
   the proper calls.  It is not required as long as the transferring
   peers can positively identify the calls participating in the transfer
   without the TRANSFERID.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x1b     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4-octet transfer        |
   |           identifier          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 75 
8.6.27.  RDNIS

   The purpose of the RDNIS (Redirected Dialed Number Identification
   Service) information element is to indicate the referring DNIS.  It
   carries UTF-8-encoded data.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x1c     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :      UTF-8-encoded RDNIS      :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.28.  DATETIME

   The DATETIME information element indicates the time a message is
   sent.  This differs from the header time-stamp because that time-
   stamp begins at 0 for each call, while the DATETIME is a call-
   independent value representing the actual real-world time.  The data
   field of a DATETIME information element is four octets long and
   stores the time as follows: the 5 least significant bits are seconds,
   the next 6 least significant bits are minutes, the next least
   significant 5 bits are hours, the next least significant 5 bits are
   the day of the month, the next least significant 4 bits are the
   month, and the most significant 7 bits are the year.  The year is
   offset from 2000, and the month is a 1-based index (i.e., January ==
   1, February == 2, etc.).  The timezone of the clock MUST be UTC to
   avoid confusion between the peers.

   The DATETIME information element SHOULD be sent with IAX NEW and
   REGACK messages.  However, it is strictly informational.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x1f     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     year    | month |   day   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  hours  |  minutes  | seconds |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 76 
8.6.29.  CALLINGPRES

   The purpose of the CALLINGPRES information element is to indicate the
   calling presentation of a caller.  The data field is 1 octet long and
   contains a value from the table below.

   The CALLINGPRES information element MUST be sent with IAX NEW
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x26     |      0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Calling Pres. |
   +-+-+-+-+-+-+-+-+

   The following table lists valid calling presentation values:

              +------+--------------------------------------+
              | FLAG | PRESENTATION                         |
              +------+--------------------------------------+
              | 0x00 | Allowed user/number not screened     |
              |      |                                      |
              | 0x01 | Allowed user/number passed screen    |
              |      |                                      |
              | 0x02 | Allowed user/number failed screen    |
              |      |                                      |
              | 0x03 | Allowed network number               |
              |      |                                      |
              | 0x20 | Prohibited user/number not screened  |
              |      |                                      |
              | 0x21 | Prohibited user/number passed screen |
              |      |                                      |
              | 0x22 | Prohibited user/number failed screen |
              |      |                                      |
              | 0x23 | Prohibited network number            |
              |      |                                      |
              | 0x43 | Number not available                 |
              +------+--------------------------------------+

   Refer to the IANA Registry for additional IAX Calling Presentation
   values.

Top      Up      ToC       Page 77 
8.6.30.  CALLINGTON

   The purpose of the CALLINGTON information element is to indicate the
   calling type of number of a caller, according to ITU-T Recommendation
   Q.931 specifications.  The data field is 1 octet long and contains
   data from the table below.

   The CALLINGTON information element MUST be sent with IAX NEW
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x27     |      0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Calling TON  |
   +-+-+-+-+-+-+-+-+

   The following table lists valid calling type of number values from
   ITU-T Recommendation Q.931:

                    +-------+-------------------------+
                    | VALUE | DESCRIPTION             |
                    +-------+-------------------------+
                    | 0x00  | Unknown                 |
                    |       |                         |
                    | 0x10  | International Number    |
                    |       |                         |
                    | 0x20  | National Number         |
                    |       |                         |
                    | 0x30  | Network Specific Number |
                    |       |                         |
                    | 0x40  | Subscriber Number       |
                    |       |                         |
                    | 0x60  | Abbreviated Number      |
                    |       |                         |
                    | 0x70  | Reserved for extension  |
                    +-------+-------------------------+

   Refer to the IANA Registry for any additional IAX Calling Type of
   Number values.

8.6.31.  CALLINGTNS

   The CALLINGTNS information element indicates the calling transit
   network selected for a call.  Values are chosen according to ITU-T
   Recommendation Q.931 specifications.  The data field is two octets
   long.  The first octet stores the network identification plan in the

Top      Up      ToC       Page 78 
   least significant four bits according to the first table below, and
   the type of network in the next three least significant bits
   according to the second table below.  The second octet stores the
   actual network identification in UTF-8-encoded data.

   The CALLINGTNS information element MUST be sent with IAX NEW
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x28     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | TON | Plan  | UTF-8 Net ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following tables list the valid values for the data field of the
   'calling tns' IE.

   Q.931 Network Identification Plan Values:

                +------+----------------------------------+
                | BITS | DESCRIPTION                      |
                +------+----------------------------------+
                | 0000 | Unknown                          |
                |      |                                  |
                | 0001 | Caller Identification Code       |
                |      |                                  |
                | 0011 | Data Network Identification Code |
                +------+----------------------------------+

   Refer to the IAX Transit Network Identification IANA Registry for any
   additional values.

   Q.931 Type of Network Values:

              +------+--------------------------------------+
              | BITS | DESCRIPTION                          |
              +------+--------------------------------------+
              | 000  | User Specified                       |
              |      |                                      |
              | 010  | National Network Identification      |
              |      |                                      |
              | 011  | International Network Identification |
              +------+--------------------------------------+

   Refer to the IAX Type of Network IANA Registry for any additional
   values.

Top      Up      ToC       Page 79 
8.6.32.  SAMPLINGRATE

   The purpose of the SAMPLINGRATE information element is to specify to
   a remote IAX peer the sampling rate in hertz of the audio data being
   the peer will use when sending data.  Its data field is 2 octets
   long.

   If the SAMPLINGRATE information element is not specified, a default
   sampling rate of 8 kHz may be assumed.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x29     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Sampling Rate in Hertz    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.33.  CAUSECODE

   The purpose of the CAUSECODE information element is to indicate the
   reason a call was REJECTed or HANGUPed.  It derives from ITU-T
   Recommendation Q.931.  The data field is one octet long and contains
   an entry from the table below.

   The CAUSECODE information element SHOULD be sent with IAX HANGUP,
   REJECT, REGREJ, and TXREJ messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x2a     |      0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cause Code  |
   +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 80 
   +--------+----------------------------------------------------------+
   | NUMBER | CAUSE                                                    |
   +--------+----------------------------------------------------------+
   | 1      | Unassigned/unallocated number                            |
   |        |                                                          |
   | 2      | No route to specified transit network                    |
   |        |                                                          |
   | 3      | No route to destination                                  |
   |        |                                                          |
   | 6      | Channel unacceptable                                     |
   |        |                                                          |
   | 7      | Call awarded and delivered                               |
   |        |                                                          |
   | 16     | Normal call clearing                                     |
   |        |                                                          |
   | 17     | User busy                                                |
   |        |                                                          |
   | 18     | No user response                                         |
   |        |                                                          |
   | 19     | No answer                                                |
   |        |                                                          |
   | 21     | Call rejected                                            |
   |        |                                                          |
   | 22     | Number changed                                           |
   |        |                                                          |
   | 27     | Destination out of order                                 |
   |        |                                                          |
   | 28     | Invalid number format/incomplete number                  |
   |        |                                                          |
   | 29     | Facility rejected                                        |
   |        |                                                          |
   | 30     | Response to status enquiry                               |
   |        |                                                          |
   | 31     | Normal, unspecified                                      |
   |        |                                                          |
   | 34     | No circuit/channel available                             |
   |        |                                                          |
   | 38     | Network out of order                                     |
   |        |                                                          |
   | 41     | Temporary failure                                        |
   |        |                                                          |
   | 42     | Switch congestion                                        |
   |        |                                                          |
   | 43     | Access information discarded                             |
   |        |                                                          |
   | 44     | Requested channel not available                          |
   |        |                                                          |
   | 45     | Preempted (causes.h only)                                |

Top      Up      ToC       Page 81 
   |        |                                                          |
   | 47     | Resource unavailable, unspecified (Q.931 only)           |
   |        |                                                          |
   | 50     | Facility not subscribed (causes.h only)                  |
   |        |                                                          |
   | 52     | Outgoing call barred (causes.h only)                     |
   |        |                                                          |
   | 54     | Incoming call barred (causes.h only)                     |
   |        |                                                          |
   | 57     | Bearer capability not authorized                         |
   |        |                                                          |
   | 58     | Bearer capability not available                          |
   |        |                                                          |
   | 63     | Service or option not available (Q.931 only)             |
   |        |                                                          |
   | 65     | Bearer capability not implemented                        |
   |        |                                                          |
   | 66     | Channel type not implemented                             |
   |        |                                                          |
   | 69     | Facility not implemented                                 |
   |        |                                                          |
   | 70     | Only restricted digital information bearer capability is |
   |        | available (Q.931 only)                                   |
   |        |                                                          |
   | 79     | Service or option not available (Q.931 only)             |
   |        |                                                          |
   | 81     | Invalid call reference                                   |
   |        |                                                          |
   | 82     | Identified channel does not exist (Q.931 only)           |
   |        |                                                          |
   | 83     | A suspended call exists, but this call identity does not |
   |        | (Q.931 only)                                             |
   |        |                                                          |
   | 84     | Call identity in use (Q.931 only)                        |
   |        |                                                          |
   | 85     | No call suspended (Q.931 only)                           |
   |        |                                                          |
   | 86     | Call has been cleared (Q.931 only)                       |
   |        |                                                          |
   | 88     | Incompatible destination                                 |
   |        |                                                          |
   | 91     | Invalid transit network selection (Q.931 only)           |
   |        |                                                          |
   | 95     | Invalid message, unspecified                             |
   |        |                                                          |
   | 96     | Mandatory information element missing (Q.931 only)       |
   |        |                                                          |
   | 97     | Message type nonexistent/not implemented                 |

Top      Up      ToC       Page 82 
   |        |                                                          |
   | 98     | Message not compatible with call state                   |
   |        |                                                          |
   | 99     | Information element nonexistent                          |
   |        |                                                          |
   | 100    | Invalid information element contents                     |
   |        |                                                          |
   | 101    | Message not compatible with call state                   |
   |        |                                                          |
   | 102    | Recovery on timer expiration                             |
   |        |                                                          |
   | 103    | Mandatory information element length error (causes.h     |
   |        | only)                                                    |
   |        |                                                          |
   | 111    | Protocol error, unspecified                              |
   |        |                                                          |
   | 127    | Internetworking, unspecified                             |
   +--------+----------------------------------------------------------+

   Refer to the IAX Cause Codes IANA Registry for any additional values.

8.6.34.  ENCRYPTION

   The purpose of the ENCRYPTION information element is to indicate what
   encryption methods are accepted for an IAX peer.  The data field is a
   2-octet bitmask specifying which encryption methods from the table
   below are accepted.

   The ENCRYPTION information element MAY be sent with IAX NEW and
   AUTHREQ messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x2b     |      0x01     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Encryption Methods       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following table lists valid native encryption methods:

                         +--------+-------------+
                         | METHOD | DESCRIPTION |
                         +--------+-------------+
                         | 0x0001 | AES-128     |
                         +--------+-------------+

Top      Up      ToC       Page 83 
   Refer to the IAX Encryption Methods IANA Registry for any additional
   values.

8.6.35.  CODEC PREFS

   The purpose of the CODEC PREFS information element is to indicate the
   CODEC preferences of the calling peer.  The data field consists of a
   list of CODECs in the peer's order of preference as UTF-8-encoded
   data.

   The CODEC PREFS information element MAY be sent with IAX NEW
   messages.

   If the CODEC PREFS information element is absent, CODEC negotiation
   takes place via the CAPABILITY and FORMAT information elements.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x2d     |  Data Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   :       CODEC Prefs Data        :
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.36.  RR JITTER

   The purpose of the Receiver Report (RR) JITTER information element is
   to indicate the received jitter on a call, per [RFC3550].  The data
   field is 4 octets long and carries the current measured jitter.

   The RR JITTER information element MAY be sent with IAX PONG messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x2e     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Received Jitter       |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 84 
8.6.37.  RR LOSS

   The purpose of the RR LOSS information element is to indicate the
   number of lost frames on a call, per [RFC3550].  The data field is 4
   octets long and carries the percentage of frames lost in the first
   octet, and the count of lost frames in the next 3 octets.

   The RR LOSS information element MAY be sent with IAX PONG messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x2f     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Loss Percent |               |
   +-+-+-+-+-+-+-+-+  Loss Count   |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.38.  RR PKTS

   The purpose of the RR PKTS information element is to indicate the
   total number of frames received on a call, per [RFC3550].  The data
   field is 4 octets long and carries the count of frames received.

   The RR PKTS information element MAY be sent with IAX PONG messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x30     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Frames Received Count      |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.39.  RR DELAY

   The purpose of the RR DELAY information element is to indicate the
   maximum playout delay for a call, per [RFC3550].  The data field is 2
   octets long and specifies the number of milliseconds a frame may be
   delayed before it MUST be discarded.

   The RR DELAY information element MAY be sent with IAX PONG messages.

Top      Up      ToC       Page 85 
                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x31     |      0x02     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Maximum Playout Delay      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.40.  RR DROPPED

   The purpose of the RR DROPPED information element is to indicate the
   total number of dropped frames for a call, per [RFC3550].  The data
   field is 4 octets long and carries the number of frames dropped.

   The RR DROPPED information element MAY be sent with IAX PONG
   messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x32     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Total Frames Dropped     |
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.6.41.  RR OOO

   The purpose of the RR OOO information element is to indicate the
   number of frames received out of order for a call, per [RFC3550].
   The data field is 4 octets long and carries the number of frames
   received out of order.

   The RR OOO information element MAY be sent with IAX PONG messages.

                        1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x33     |      0x04     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Frames Received       |
   |          Out of Order         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 86 
8.6.42.  OSPTOKEN

   The purpose of the OSPTOKEN information element is to carry European
   Telecommunications Standards Institute (ETSI) Technical Specification
   101 321 [OSP] (also referred to as the Open Settlement Protocol or
   OSP) tokens.  The OSP tokens will be used to provide authorization,
   authentication and account support for IAX by using the OSP protocol.
   The first octet of the data field is the OSP token block index
   starting from 0.

   The OSPTOKEN information element MAY only be sent with IAX NEW
   messages.  If the token is not supported by the receiver, it is
   ignored.

                                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |      0x34     |  Data Length  |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |  Block Index  |               |
              +-+-+-+-+-+-+-+-+               +
              |        OSP Token Block        |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.7.  Media Formats

   Media Format Values

   +------------+-----------------+------------------------------------+
   | SUBCLASS   | DESCRIPTION     | LENGTH CALCULATION                 |
   +------------+-----------------+------------------------------------+
   | 0x00000001 | G.723.1         | 4-, 20-, and 24-byte frames of 240 |
   |            |                 | samples                            |
   |            |                 |                                    |
   | 0x00000002 | GSM Full Rate   | 33-byte chunks of 160 samples or   |
   |            |                 | 65-byte chunks of 320 samples      |
   |            |                 |                                    |
   | 0x00000004 | G.711 mu-law    | 1 byte per sample                  |
   |            |                 |                                    |
   | 0x00000008 | G.711 a-law     | 1 byte per sample                  |
   |            |                 |                                    |
   | 0x00000010 | G.726           |                                    |
   |            |                 |                                    |
   | 0x00000020 | IMA ADPCM       | 1 byte per 2 samples               |
   |            |                 |                                    |
   | 0x00000040 | 16-bit linear   | 2 bytes per sample                 |
   |            | little-endian   |                                    |
   |            |                 |                                    |

Top      Up      ToC       Page 87 
   | 0x00000080 | LPC10           | Variable size frame of 172 samples |
   |            |                 |                                    |
   | 0x00000100 | G.729           | 20-byte chunks of 172 samples      |
   |            |                 |                                    |
   | 0x00000200 | Speex           | Variable                           |
   |            |                 |                                    |
   | 0x00000400 | ILBC            | 50 bytes per 240 samples           |
   |            |                 |                                    |
   | 0x00000800 | G.726 AAL2      |                                    |
   |            |                 |                                    |
   | 0x00001000 | G.722           | 16 kHz ADPCM                       |
   |            |                 |                                    |
   | 0x00002000 | AMR             | Variable                           |
   |            |                 |                                    |
   | 0x00010000 | JPEG            |                                    |
   |            |                 |                                    |
   | 0x00020000 | PNG             |                                    |
   |            |                 |                                    |
   | 0x00040000 | H.261           |                                    |
   |            |                 |                                    |
   | 0x00080000 | H.263           |                                    |
   |            |                 |                                    |
   | 0x00100000 | H.263p          |                                    |
   |            |                 |                                    |
   | 0x00200000 | H.264           |                                    |
   +------------+-----------------+------------------------------------+

   Refer to the IANA Registry for any additional IAX Media Format
   values.



(page 87 continued on part 5)

Next RFC Part