RFC 5456
IAX: Inter-Asterisk eXchange Version 2
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.
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 |
| 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.
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.
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.
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.
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
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:
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
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.
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 | +-+-+-+-+-+-+-+-+
+--------+----------------------------------------------------------+ | 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) |
| | | | 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 |
| | | | 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 | +--------+-------------+
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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | | | | | |
| 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)
