Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 7, 2006.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document describes the Inter-Asterisk eXchange protocol, Version 2, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX is targeted primarily at the control of Voice over Internet Protocol (VoIP) calls, but can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in Internet Protocol (IP) networks. It combines both control and media services in the same protocol. IAX's compact encoding decreases bandwidth usage and since IAX uses a single, static, UDP port, it facilitates native support for Network Address Translation (NAT) transparency. IAX is well suited for Internet telephony service, but, is open enough to support additional services.

Table of Contents

1.  Introduction
2.  IAX Terminology
3.  Overview of IAX Protocol
4.  Naming Conventions
5.  IAX Uniform Resource Indicators
    5.1.  IAX2 URI Components
    5.2.  Example IAX2 URIs
    5.3.  URI Comparison
6.  Peer Behavior and Messages
    6.1.  Registration (OPTIONAL)
        6.1.1.  Overview
        6.1.2.  REGREQ Request Message
        6.1.3.  REGAUTH Response Message
        6.1.4.  REGACK Response Message
        6.1.5.  REGREJ Response Message
        6.1.6.  REGREL Request Message
    6.2.  Call Leg Management
        6.2.1.  Overview
        6.2.2.  NEW Request Message
        6.2.3.  ACCEPT Response Message
        6.2.4.  REJECT Response Message
        6.2.5.  HANGUP Request Message
        6.2.6.  AUTHREP Response Message
        6.2.7.  AUTHREQ Response Message
    6.3.  Call Control
        6.3.1.  Overview
        6.3.2.  PROCEEDING Response Message
        6.3.3.  RINGING Response Message
        6.3.4.  ANSWER Response Message
    6.4.  Mid-Call Link Operations
        6.4.1.  FLASH Request Message
        6.4.2.  HOLD Request Message
        6.4.3.  UNHOLD Request Message
        6.4.4.  QUELCH Request Message
        6.4.5.  UNQUELCH Request Message
        6.4.6.  TRANSFER Request Message
    6.5.  Call Path Optimization
        6.5.1.  TXREQ Request Message
        6.5.2.  TXCNT Response Message
        6.5.3.  TXACC Response Message
        6.5.4.  TXREADY Response Message
        6.5.5.  TXREL Response Message
        6.5.6.  TXREJ Response Message
    6.6.  Call Tear Down
    6.7.  Network Monitoring
        6.7.1.  POKE Request Message
        6.7.2.  PING Request Message
        6.7.3.  PONG Response Message
        6.7.4.  LAGRQ Request Message
        6.7.5.  LAGRP Response Message
    6.8.  Digit Dialing
        6.8.1.  DPREQ Request Message
        6.8.2.  DPREP Response Message
        6.8.3.  DIAL Request Message
    6.9.  Firmware Download
        6.9.1.  FWDOWNL Request Message
        6.9.2.  FWDATA Response Message
    6.10.  Provisioning
        6.10.1.  PROVISION Request Message
    6.11.  Miscellaneous
        6.11.1.  ACK Response Message
        6.11.2.  INVAL Response Message
        6.11.3.  VNAK Response Message
        6.11.4.  MWI Request Message
        6.11.5.  UNSUPPORT Response Message
    6.12.  Media Messages
        6.12.1.  DTMF Media Message
        6.12.2.  Voice Media Message
        6.12.3.  Video Media Message
        6.12.4.  Text Media Message
        6.12.5.  Image Media Message
        6.12.6.  HTML Media Message
        6.12.7.  Comfort Noise Media Message
7.  Message Transport
    7.1.  Trunking
    7.2.  Timers
        7.2.1.  Retransmission Timer
        7.2.2.  Registration Period Timer
    7.3.  NAT Considerations
    7.4.  Encryption
8.  Message Encoding
    8.1.  Full Frames
    8.2.  Mini frames
    8.3.  Meta frames
        8.3.1.  Meta Video Frames
        8.3.2.  Meta Trunk Frames
    8.4.  Frame Types
        8.4.1.  DTMF Frame
        8.4.2.  Voice Frame
        8.4.3.  Video Frame
        8.4.4.  Control Frame
        8.4.5.  Null Frame
        8.4.6.  IAX Frame
        8.4.7.  Text Frame
        8.4.8.  Image Frame
        8.4.9.  HTML Frame
        8.4.10.  Comfort Noise Frame
        8.4.11.  Control Frames
        8.4.12.  IAX Frames
    8.5.  HTML Command Subclasses
    8.6.  Information Elements
        8.6.1.  CALLED NUMBER
        8.6.2.  CALLING NUMBER
        8.6.3.  CALLING ANI
        8.6.4.  CALLING NAME
        8.6.5.  CALLED CONTEXT
        8.6.6.  USERNAME
        8.6.7.  PASSWORD
        8.6.8.  CAPABILITY
        8.6.9.  FORMAT
        8.6.10.  LANGUAGE
        8.6.11.  VERSION
        8.6.12.  ADSICPE
        8.6.13.  DNID
        8.6.14.  AUTHMETHODS
        8.6.15.  CHALLENGE
        8.6.16.  MD5 RESULT
        8.6.17.  RSA RESULT
        8.6.18.  APPARENT ADDR
        8.6.19.  REFRESH
        8.6.20.  DPSTATUS
        8.6.21.  CALLNO
        8.6.22.  CAUSE
        8.6.23.  IAX UNKNOWN
        8.6.24.  MSGCOUNT
        8.6.25.  AUTOANSWER
        8.6.26.  MUSICONHOLD
        8.6.27.  TRANSFERID
        8.6.28.  RDNIS
        8.6.29.  PROVISIONING
        8.6.30.  AESPROVISIONING
        8.6.31.  DATETIME
        8.6.32.  DEVICETYPE
        8.6.33.  SERVICEIDENT
        8.6.34.  FIRMWAREVER
        8.6.35.  FWBLOCKDESC
        8.6.36.  FWBLOCKDATA
        8.6.37.  PROVVER
        8.6.38.  CALLINGPRES
        8.6.39.  CALLINGTON
        8.6.40.  CALLINGTNS
        8.6.41.  SAMPLINGRATE
        8.6.42.  CAUSECODE
        8.6.43.  ENCRYPTION
        8.6.44.  ENCKEY
        8.6.45.  CODEC PREFS
        8.6.46.  RR JITTER
        8.6.47.  RR LOSS
        8.6.48.  RR PKTS
        8.6.49.  RR DELAY
        8.6.50.  RR DROPPED
        8.6.51.  RR OOO
    8.7.  Media Formats
9.  Example Message Flows
    9.1.  Ping/Pong
    9.2.  Lagrq/Lagrp
    9.3.  Registration
    9.4.  Registration
    9.5.  Provisioning
    9.6.  Firmware Download
    9.7.  Call Path Optimization
    9.8.  IAX Media Call
    9.9.  IAX Media Call via an IAX Device
10.  Security Considerations
11.  IANA Considerations
12.  Implementation Notes
13.  Acknowledgments
14.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Introduction

Numerous protocols have been specified by the Internet community to support control or signaling of multimedia sessions. In general, these protocols are designed to offer full support for many types of media transmission. This flexible approach adds some overhead to the protocol headers, but allows for the protocol use well beyond the current application. Typically, these protocols reference, but do not specify the media transmission protocol to be used to carry the actual stream. This method allows for greater flexibility, but again leads to more overhead. Furthermore, multimedia solutions which use different, perhaps dynamic, network addresses for signaling and media transmission frequently suffer from Network Address Translation (NAT) traversal and security challenges.

IAX is general enough that it can handle most common types of media streams. However, the protocol is highly optimized for VoIP calls where low overhead and low bandwidth consumption are priorities. This pragmatic aspect makes IAX much more efficient for VoIP than protocols which consider possibilities far beyond current needs and specify many more details than are strictly necessary to describe or transport a point-to-point call. Furthermore, because IAX is designed to be lightweight and VoIP-friendly, it consumes comparatively less bandwidth. Because IAX uses the same UDP port for both its signaling and media messages, and because all communications regarding the call are done over a the same point-to-point path, NAT traversal is much simpler for IAX than for other commonly deployed protocols.

2. IAX Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Additionally, this document uses the following terminology:

Peer:

A host or device that implements the IAX protocol.

Call:

A call is a relationship between two or more parties (i.e., resources such as devices, user agents, or programs) that exists for some time for the purpose of exchanging real-time media. In the context of this document, a call is an end to end relationship where at least the one leg of call path is implemented using the IAX protocol.

Calling Party:

A device or program that initiates a call.

Called Party:

A device or program to which a call is directed.

Context:

A context is a named partition of a Dialplan.

Dialplan:

A Dialplan is a set of rules for associating provided names and numbers with a particular called party.

Frame:

The atomic communication unit between two IAX peers. All IAX messages are carried within frames.

Information Element (IE):

A discrete data unit appended to an IAX frame which specifies user or call-specific data.

Registrant:

A registrant is a peer that makes REGISTER requests in order to advertise the address of a resource, i.e., a device or program to which a call may be directed.

Registrar:

A registrar is a peer that processes REGISTER requests and places the information it receives in those requests into the location service. [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

3. Overview of IAX Protocol

IAX is a peer-to-peer, VoIP-oriented, protocol. IAX includes both control and media functions. It can register locations, create, modify, terminate multimedia sessions, and carry the actual media streams specified by the sessions it manages. The protocol is designed and optimized for describing and transporting multimedia calls using Internet Protocol.

The basic design approach for IAX multiplexes signaling and multiple media streams over a single UDP association between two hosts. This is accomplished by using the same "well-known" UDP port, 4569, for all types of IAX traffic. IAX's unified signaling and media paths achieve NAT transparency, which is an advantage of IAX over alternative media transport protocols such as SIP.

IAX is coded as a binary protocol. One major benefit of using a binary protocol is bandwidth efficiency because the quality of voice calls is frequently related to the amount of bandwidth consumed. This is one way the protocol is specifically optimized to make efficient use of bandwidth for individual voice calls. The bandwidth efficiency for other stream types is sacrificed for the sake of individual voice calls. Other benefits of a binary protocol are robustness against buffer overrun attacks and compact implementation capability, which reduces interoperability issues related to parsing.

The atomic communication unit in IAX is the "Frame". There are multiple classes of Frames, each of which is described below. In general, "Full Frames" carry signaling/control data, while "Mini Frames" carry media stream data. Full Frames enclose optional 'Information Elements' (IEs). IEs describe various types of user- or call-specific data. "Meta Frames" are used for call trunking or video stream transmission.

An IAX-based call may consist of many call legs, or segments. Each call leg may be implemented using different protocols, e.g., SIP to IAX to ISDN. IAX is responsible for setting up one or more legs of a complete call path, not necessarily the end-to-end call.

IAX is an optimized peer-to-peer protocol.  If two adjacent call legs utilize the IAX protocol and if the intermediate peer determines that it does not need to remain in the call path, it can supervise a calling path change such that it removes itself from the path. This supervision is complete, a call path is not changed until all peers in the optimized call path confirm they can properly communicate

IAX supports security features by allowing multiple methods of user authentication and authorization, as well as during peer registration. IAX also specifies a generic framework for native encryption.

4. Naming Conventions

Call Identifier:

A call leg is marked with two unique integers, one assigned by each peer involved in creating the call leg.

Number:

The Calling and Called Numbers are a set of digits and letters identifying a call originator and the desired terminating resource. The term 'Number' is historic and has been expanded to include letters. A peer is responsible for defining its own dialplan. A peer MAY define its dialplan according to ITU-T Recommendation E.164. [E164] (ITU-T, “The International Public Telecommunication Number Plan,” May 1997.) However, this is not required.

Username:

A username is a string used for identification purposes.

5. IAX Uniform Resource Indicators

An IAX URI identifies a communications resource capable of communicating using the IAX Version 2 protocol defined in this document. Within this document, we refer to IAX Version 2 protocol URI as IAX2.  An IAX2 URI contains enough information to initiate an IAX2-based call with that resource.

IAX2 URIs are associated with server resources to which calls may be routed. For instance, an IAX2 URI may represent an appearance on a phone, a voice-mail box on a messaging service, an interactive program, a PSTN address or gateway, or any group of the above.

5.1. IAX2 URI Components

The "iax2:" scheme follows the guidelines in [RFC2526] (Johnson, D. and S. Deering, “Reserved IPv6 Subnet Anycast Addresses,” March 1999.).

The form is as follows:

iax2:[username@]host[:port][/number[?context]]

where these tokens have the following meanings:

iax2:

The literal 'iax2:'.

username:

A string used for identification purposes.

host:

The domain of the resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible.

port:

The numeric UDP port number.

number:

The name or number identifying the resource on that host.

context:

The name of the host partition in which the service is identified or processed.

5.2. Example IAX2 URIs

iax2:atlanta.com/alice
iax2:atlanta.com:4569/alice
iax2:atlanta.com:4570/alice?friends
iax2:192.0.2.4:4569/alice?friends
iax2:whitehouse.gov/12022561414
iax2:johnQ@whitehouse.gov/12022561414

5.3. URI Comparison

Some operations in this specification require determining whether two IAX2 URIs are equivalent. IAX2 URIs are compared for equality according to the following rules:

All components of the URI MUST be identical except:

A host in domain form and in IP address form are considered identical if and only if the host name resolves to exactly one address record and that address record matches the given IP address.

The port, if omitted, is considered to be the same as the default, 4569.

Only the user and password fields are case sensitive.

The URIs within each of the following sets are equivalent:
iax2:atlanta.com/alice
iax2:AtLaNtA.com/ALicE
iax2:atlanta.com:4569/alice

iax2:atlanta.com:4569/alice
iax2:192.168.1.1/alice (if atlanta.com resolves to 192.168.1.1)

The URIs within each of the following sets are not equivalent:
iax2:ALICE@atlanta.com/alice
iax2:alice@atlanta.com/alice

6. Peer Behavior and Messages

Messages are divided into two categories: reliable and non-guaranteed. The reliable messages are referred to as "Full Frames." In addition to a message type indicator and facilities to ensure reliability, see Section 7 (Message Transport), they include the full call identifier. It consists of each of peer's identifiers for the call. Additional attributes, "Information Elements" or "IEs", MAY be associated with the Full Frame messages.

The non-guaranteed messages are referred to as "Mini-Frames" and "Meta Frames" and these more compact messages only have the originating peer's call identifier and may not have any "Information Elements."

Peer behavior is presented in several partitions divided by the following functional areas:

Registration (OPTIONAL)

Call Link Management

Call Path Optimization (OPTIONAL)

Mid-Call Behavior

Call Tear Down

Network Monitoring

Digit Dialing (OPTIONAL)

Firmware Download(OPTIONAL)

Provisioning (OPTIONAL)

Miscellaneous

Media Messages

Each of these behavior topics and the messages involved are described in the sections which follow.

6.1. Registration (OPTIONAL)

6.1.1. Overview

In order for one IAX peer to be reachable by another IAX peer, the calling peer needs the network address of the receiving peer. This address may be manually provisioned, determined through a shared directory, e.g. an ENUM-like service, or configured using the IAX protocol. IAX provides a facility for one peer to register its address and credentials with another so that others may locate it. The IAX registration facility is optional. If implemented, the IAX registration protocol MAY be done in parts, e.g., an analog telephone adapter MAY only implement the registrant portion of the protocol.

IAX allows user authentication via multiple methods. The least secure is plaintext, which sends passwords in clear text between two peers and requires that each peer have access to a shared secret. MD5 uses a challenge/response md5 sum arrangement, but still requires that both ends have plaintext access to the secret. RSA allows unidirectional secret knowledge through public/private key pairs. IAX Private keys SHOULD always be 3DES encrypted.

Registration is performed by a registrant peer that sends a username to the registrar peer. This is accomplished with a REGREQ message. If authentication is required, the registrar responds with the REGAUTH message which indicates the types of authentication supported by the registrar peer. In response, the requesting peer resends a REGREQ with one of the supported authentications. If accepted, the registrar peer sends a REGACK message which MUST indicate the 'apparent address' and SHOULD indicate the 'refresh'/expire time. If no 'refresh' is sent a default registration expiration of 60 seconds MUST be assumed by both peers. At any time during this exchange, the registrar may send a REGREJ message to indicate a failure.

A registration has a specified time period associated with it for which it is valid. Before this time period expires, a peer may re register by sending another REGREQ message and performing the messaging described above. A registrant MAY also force an expiration in the registrar by sending the REGREL message. This message may be challenged with REGAUTH or if sufficient credentials were included, it will be accepted with REGACK. In response to a REGAUTH, a REGREL message SHOULD be resent using the specified credentials.

See sections Section 9.3 (Registration) and Section 9.4 (Registration) for example call flows.

6.1.2. REGREQ Request Message

A REGREQ is a registration request. It occurs independently of any media-carrying call. A REGREQ MUST include the 'username' IE and SHOULD include the 'refresh' IE. A REGREQ is used both for a literal initial registration request as well as for a reply to a REGAUTH. As a reply to a REGAUTH message, it MUST include credentials such as a response to a REGAUTH's challenge or the plaintext password for authentication.

Upon receipt of a REGREQ message which has credentials, a registrar peer MUST determine their validity. If valid, it MUST respond with a REGACK message indicating the time period for which this registration is valid. If the provided credentials are not valid, the peer MUST respond with a REJREJ message. If insufficient credentials are provided, the peer MUST respond with a REGAUTH message that indicates the available authentication methods.

Registrant peers MUST be able to send this message and registrar peers MUST be able to process it.

The following table specifies IEs for this message:

6.1.3. REGAUTH Response Message

A REGAUTH is a response to a REGREQ or REGREL. It is sent when a peer requires authentication to permit registration. A REGAUTH message MUST include the 'authentication methods' and 'username' IEs, and the 'MD5 challenge' or 'RSA challenge' IE if the authentication methods include MD5 or RSA.

Upon receipt of a REGAUTH message, the peer SHOULD resend the REGREQ or REGREL message with one of the requested credentials. If the authentication credentials are not approved by the registrar, registration should be considered unsuccessful and a REGREJ message MUST be sent.

Registrar peers SHOULD be able to send this message and registrants MUST be able to process it.

The following table specifies IEs for this message:

6.1.4. REGACK Response Message

A REGACK is an acknowledgment of successful registration, sent in response to a REGREQ. A REGACK typically includes the 'refresh' IE specifying the number of seconds before the registration will expire. If the 'refresh' IE is not included with a REGACK, a default registration expiration of 60 seconds SHOULD be assumed. A REGACK MAY also include the 'username' and 'apparent address' IEs to indicate how the peer identifies the registrant. IEs related to caller identification or the time the registration occurred MAY be sent as well.

Receipt of a REGACK message requires an ACK in response.

Registrars MUST be able to send this message and registrants MUST be able to process it.

The following table specifies IEs for this message:

6.1.5. REGREJ Response Message

A REGREJ indicates that registration has been rejected. It can occur for several reasons. A REGREJ SHOULD include the 'causecode' and 'cause' IEs to specify why registration was rejected.

Upon receipt of a REGREJ message, the peer SHOULD consider registration process unsuccessful and no further interaction is required. A peer MAY reinitiate the the process at later time accounting for potential configuration changes on the registrar.

Both registrants and registrars SHOULD be capable of sending and processing this message.

The following table specifies IEs for this message:

6.1.6. REGREL Request Message

A REGREL is a forced release of a prior registration. It MUST include the 'username' IE to identify the registrant to be released, and MAY include the 'causecode' and 'cause' IEs to specify why registration is being released.

Upon receipt of this message, a peer MUST authenticate the sender using the provided credentials or send a REGAUTH message requesting them. If authenticated it MUST immediately purge its registration of the specified registrant or send a REGREJ message if the registration is not found.

Registrants SHOULD be capable of sending this message and registrars MUST be able to receive it.

The following table specifies IEs for this message:

6.2. Call Leg Management

6.2.1. Overview

The IAX protocol can be used to setup 'links' or 'call legs' between two peers for the purposes of placing a call. The process starts when a peer sends a NEW message indicating the destination 'number' (or name) of a Called Party on the remote peer. The remote peer can respond with either a credentials challenge (AUTHREQ), a REJECT message, or an ACCEPT message. The AUTHREQ message indicates the permitted authentication schemes and SHOULD result in the sending of an AUTHREP message with the requested credentials. The REJECT message indicates the call cannot be established at this time. And ACCEPT indicates that the call leg between these two peers is established and that Higher level call signaling (Section 6.3 (Call Control)) MAY proceed.

Call Legs are labeled with a pair of identifiers. Each end of the call leg assigns the source or destination identifier during the call leg creation process.

6.2.2. NEW Request Message

A NEW message is sent to initiate a call. It is the first call-specific message sent to initiate an actual media exchange between two peers. 'NEW' messages are unique in that they do not require a destination call identifier in their header. This absence is because the remote peer's source call identifier is not created until after receipt of this frame. Before sending a NEW message, the local IAX peer MUST assign a source call identifier that is not currently being used for another call. A time-stamp MUST also be assigned for the call, beginning at 0 and incrementing each millisecond. Sequence numbers for a NEW message, described in the transport section, are both set to 0.

A NEW message MUST include the 'version' IE, and it MUST be the first IE. A NEW SHOULD generally include IEs to indicate routing on the remote peer, e.g., via the 'called number' IE or to indicate a peer partition or ruleset, the 'called context' IE. Caller identification and CODEC negotiation IEs MAY also be included.

Upon receipt of a NEW message, the peer examines the destination and MUST perform one of the following actions:

Send a REJECT response,

Challenge the caller with an AUTHREQ response,

Accept the call using an ACCEPT message, or

Abort the connection using a HANGUP message, although the REJECT message is preferred at this point in call.

If the call is accepted, the peer MUST progress the call and further respond with one of PROCEEDING, RINGING, BUSY or ANSWER depending on the status of the called party on the peer. See Section 6.3 (Call Control) for further detail.

The following table specifies IEs for this message:

6.2.3. ACCEPT Response Message

An ACCEPT response is issued when a NEW message is received, and authentication has taken place (if required). It acknowledges receipt of a NEW message and indicates that the call leg has been setup on the remote side, including assigning a CODEC. An ACCEPT message MUST include the 'format' IE to indicate to the remote peer its desired CODEC. The CODEC format MUST be one of the formats sent in the associated NEW command.

Upon receipt of an ACCEPT, an ACK MUST be sent and the CODEC for the call MAY be configured using the 'format' IE from the received ACCEPT. The call then waits for an ANSWER, HANGUP or other call control signal. (See Section 6.3 (Call Control).) If a subsequent ACCEPT message is received for a call which has already started, or has not sent a NEW message, the message MUST be ignored.

The following table specifies IEs for this message:

6.2.4. REJECT Response Message

A REJECT response is sent to indicate that a request has been denied. It MAY be due to an authentication failure, an invalid username or if a peer cannot provide a valid password or response to an issued challenge. It MAY also be used to notify a peer of a call setup failure, e.g., when IAX peers cannot negotiate a CODEC to use or when a firmware download request cannot be satisfied. Upon receipt of a REJECT message, the call leg is destroyed and no further action is required. (Note: REJECT messages require an explicit ACK.)

REJECT messages MAY include the 'causecode' and 'cause' IEs to indicate the rejection reason.

The following table specifies IEs for this message:

6.2.5. HANGUP Request Message

A HANGUP message indicates a call tear-down. It MAY include the 'causecode' and 'cause' IEs to indicate the reason for terminating the call. Upon receipt of a HANGUP message, an IAX peer MUST immediately respond with an ACK, and then destroy the call leg at its end. After a HANGUP message has been received for a call leg, any messages received which reference that call leg (i.e., have the same source/destination call identifiers) MUST be answered with an INVAL message. This indicates that the received message is invalid because the call no longer exists.

The following table specifies IEs for this message:

6.2.6. AUTHREP Response Message

An AUTHREP is an authentication reply. It MUST include the appropriate challenge response or password IE, and is only sent in response to an AUTHREQ. An AUTHREP requires a response of either an ACCEPT or a REJECT.

Typical reasons for rejecting an AUTHREP include 'destination does not exist' and 'suitable bearer not found'.

The following table specifies IEs for this message:

6.2.7. AUTHREQ Response Message

The AUTHREQ message is used as an authentication request. It is sent in response to a NEW message if authentication is required for the call to be accepted. It MUST include the 'authentication methods' and 'username' IEs, and the 'challenge' IE if MD5 or RSA authentication is specified.

Upon receiving an AUTHREQ message, the receiver MUST respond with an AUTHREP or HANGUP message.

The following table specifies IEs for this message:

6.3. Call Control

6.3.1. Overview

IAX's call control messages provide end-to-end signaling functions common to other telephony control protocols. The messages include RINGING, ANSWER, BUSY, and PROCEEDING. These messages MUST only be sent after an IAX call leg has been ACCEPTed.

In response to an exchange starting with a NEW message, typically, the first call control message is RINGING, however, a PROCEEDING message MAY precede it or the call MAY proceed directly to the ANSWER message. If the call is answered, an ANSWER message will be sent. Other possibilities include a "BUSY" indication, or if the called party's service cannot be reached, the call will be town down using the link-level HANGUP and an appropriate cause code.

If the link was started with a DIAL message, the sequence is an optional PROCEEDING, then optional RINGING, then ANSWER or BUSY. Of course, a link level HANGUP MAY occur at any time.

Various extensions to IAX Control messages have been deployed for passing application-specific data over IAX control link. One such extensions is an application that controls ham radio transceivers. An IAX peer that receives a control message that is not understood MUST respond with the UNSUPPORT message.

The mandatory IAX control messages are explained below.

6.3.2. PROCEEDING Response Message

The PROCEEDING message SHOULD sent to a calling party when their call request is being processed by a further network element but has not yet reached the called party.

Upon receipt of a PROCEEDING message, the peer SHOULD perform protocol-specific actions to indicate this fact to the calling party, e.g., tones, an ISUP Proceeding message, etc. If the prior call leg is utilizing the IAX protocol, a PROCEEDING message MUST be sent to that peer. The processing of this message at an originating or transcoding peer is not specified, however, if possible, the status may be displayed to the calling party.

The PROCEEDING message does not require any IEs.

6.3.3. RINGING Response Message

This message is sent from a terminating party to indicate that that the called party's service has processed the call request and is being alerted to the call. A IAX2 RINGING message MUST be sent to an IAX2-based calling party when the peer determines that the called party is being alerted, e.g., when their phone is ringing.

Upon receipt of an IAX2 RINGING message, the peer MUST pass this indication to the calling party, unless the calling party has already received such indication. For an initiating peer, this is typically done by starting the ring-back tone, however, many implementations start ringback before ringing in order to meet user expectations. If the calling party is using the IAX2 protocol, a RINGING message MUST be passed to this caller.

The RINGING message does not require any IEs.

6.3.4. ANSWER Response Message

This message is sent from the called party to indicate that party has accepted the call request and is communicating with the calling party. Upon receipt of this message, any ring-back or other progress tones MUST be terminated and the communications channel MUST be opened.

The ANSWER message does not require any IEs.

6.4. Mid-Call Link Operations

6.4.1. FLASH Request Message

The FLASH message is sent to indicate a mid call feature. Its interpretation is system dependent and if it is not expected, it SHOULD be ignored. Typically, this message is only sent from Analog Telephone adapters when a brief circuit interruption is made during an answered call.

The FLASH message does not require any IEs.

6.4.2. HOLD Request Message

The HOLD message is sent to cause the remote system to stop transmitting audio on this channel, and optionally replace the audio with music or other sounds. If the remote system cannot perform this request, it SHOULD be ignored.

The HOLD message SHOULD only be sent in IAX2 calls which are started using the DIAL message.

The HOLD message does not require any IEs.

6.4.3. UNHOLD Request Message

The UNHOLD message is sent to cause the remote system to stop transmitting audio on this channel, and optionally replace the audio with music or other sounds. If the remote system cannot perform this request, it SHOULD be ignored.

The UNHOLD message SHOULD only be sent in IAX2 calls after the HOLD message.

The UNHOLD message does not require any IEs.

6.4.4. QUELCH Request Message

The QUELCH message is sent to cause the remote peer to squelch or stop transmitting audio on this channel. It MAY replace the audio sent to the further party with music or other sounds. If the remote system cannot perform this request, it SHOULD be ignored.

The QUELCH message MUST only be sent in IAX2 calls after an ACCEPT is sent or received; it SHOULD only be used on calls which are started using the NEW message.

The QUELCH message does not require any IEs.

6.4.5. UNQUELCH Request Message

The UNQUELCH message is sent to cause the remote system to resume transmitting audio on this channel. If it previously replaced the audio with music or other sounds, it MUST discontinue it immediately. If the remote system cannot perform this request, it SHOULD be ignored.

The UNQUELCH message SHOULD only be sent in IAX calls after the QUELCH message.

The UNQUELCH message does not require any IEs.

6.4.6. TRANSFER Request Message

The TRANSFER message causes the receiving peer to restart the call using another specified number. The receiving peer MUST be on the calling side of this call leg and the new call behavior is unspecified. After processing this message, a HANGUP message SHOULD be sent and the call leg torn down.

When sending a TRANSFER message, the new number to which the call is being transferred MUST be included in the CALLED_NUMBER IE and a CALLED_CONTEXT IE MAY be included. The call leg MUST not be used for anything else and MAY be torn down.

The following table specifies IEs for this message:

6.5. Call Path Optimization

If a peer is handling a call between two other IAX peers and the peer no longer has any need to monitor the progress, content, or duration of the call, it MAY remove itself from the call by directing the other two peers to communicate directly. This call path optimization, or "supervised transfer," is done in a manner that ensures the call will not be lost in the process; the initiating peer does not give up control of the process until it has confirmed the other two peers are communicating. Note: the parties involved in the call are not aware of this operation; it is purely a network operation.

When a peer initiates this procedure, both call legs MUST be in the UP state, i.e., they MUST have sent or received the ACCEPT message for that call leg. To start, it sends a TXREQ message with the addresses and information from the other remote peers to each its neighbors. If capable of performing this procedure, they begin transmitting all channel information to both the initiating peer and the new remote peer. They also send a TXCNT message indicating packet counts for the call leg to the new remote peer. Each TXCNT message is acknowledged with a TXACC message. The peers respond by sending a TXREADY message to the initiator indicating that they have confirmed the new communications path. When all remote peers have sent the initiator a TXREADY message, the transfer is successful and the initiator responds with a TXREL and has finished its involvement with the call. If during the transfer process, the two remote peers cannot communicate, they send a TXREJ message to the initiator. An example is shown in Section 9.7 (Call Path Optimization).

These messages are described in the sections which follow:

6.5.1. TXREQ Request Message

The TXREQ message is sent by a peer to initiate the transfer process. It MUST be sent to the adjacent peers involved in the call.

It MUST includes the following Information Elements:

The Apparent Address is the IP address data structure address for the other remote peer. The Call Number IE is The callid used by the other remote peer and the Transfer ID is a unique number assigned by the initiator.

Upon receipt of a TXREQ message for a valid call from the proper remote peer, a peer MUST respond by attempting to communicate with the newly specified remote peer. This task is accomplished by sending a TXCNT message directly to the peer at the address specified in the Apparent Address parameter.

6.5.2. TXCNT Response Message

The TXCNT message is used to verify connectivity with a potential replacement peer for a call. It MUST include the TRANSFERID IE. Upon receipt on a message of this type, and if the peer has previously received a TXREQ for this call leg, the peer MUST respond with a TXACC message.

If the TXCNT Message is not successfully transmitted or if a TXACC message is not received in response to it, the transfer process MUST be aborted by sending a TXREJ message to the initiating host.

It MUST includes the following Information Element:

6.5.3. TXACC Response Message

Like the TXCNT message, the TXACC message is used to verify connectivity with a potential replacement peer. It MUST include the TRANSFERID IE. Upon receipt on a message of this type if the peer is attempting to transfer this call leg, the peer stops sending call related media to the initiating peer and sends a TXREADY message to it.

It MUST includes the following Information Element:

6.5.4. TXREADY Response Message

The TXREADY message indicates that the sending peer has verified connectivity with the peer which it was instructed to transfer the call. It MUST include the TRANSFERID IE. When TXREADY messages are received from both remote peers, it MUST discontinue media transport and send a TXREL message to each peer.

It MUST includes the following Information Element:

6.5.5. TXREL Response Message

The TXREL message indicates that the transfer process has successfully completed. After sending and upon receipt of this message, no further interaction (other than an ACK, of course) is needed between the peers on this call-leg.

It MUST includes the following Information Element:

6.5.6. TXREJ Response Message

The TXREJ MAY be sent at anytime during the transfer process to indicate that the transfer cannot proceed. Upon receiving a TXREJ message, if the receiver is the initiating peer, it MUST form a TXREJ message and send it to the other remote peer.

The TXREJ message does not require any IEs.

6.6. Call Tear Down

The messages used to finish a call vary depending on the particular process the call is in at the time. The terminal messages for a call are:

HANGUP. See Section 6.2.5 (HANGUP Request Message).

REJECT. See Section 6.2.4 (REJECT Response Message).

TRANSFER. See Section 6.4.6 (TRANSFER Request Message).

TXREADY. See Section 6.5.4 (TXREADY Response Message).

These messages are discussed in their respective sections. Also, if the reliable transport procedures determines that messaging cannot be maintained, the call leg MUST be torn down without any other indications over the errant IAX call leg.

6.7. Network Monitoring

The IAX protocol has various tools to determine the network load. It uses the POKE message to monitor reachability of remote peer and the LAGRQ message to measure the quality of a current call leg including the jitter buffer delay.

6.7.1. POKE Request Message

A POKE message is sent to test connectivity of a remote IAX peer. It is similar to a PING message, except that it MUST be sent when there is no existing call to the remote endpoint. It MAY also be used to "qualify" a user to a remote peer, so that the remote peer can maintain awareness of the state of the user. A POKE MUST have 0 as its destination call number.

Upon receiving a POKE message, the peer MUST respond with a PONG message.

This message does not require any IEs.

6.7.2. PING Request Message

A PING message is sent to test connectivity of the remote IAX endpoint on an existing call. Transmission of a PING MAY occur when a peer-defined number of seconds have passed without receiving an incoming media frame on a call, or by default every 20 seconds. Receipt of a PING requires an acknowledging PONG be sent.

This message does not require any IEs.

6.7.3. PONG Response Message

A PONG message is a response to a PING or a POKE. It acknowledges the connection. The receiver uses the time-stamp of the received PING or POKE and its times to determine the Round Trip Time of the connection. Several receiver report IEs MAY be included with a PONG, including received jitter, received frames, delay, and dropped frames. Receipt of a PONG requires an ACK.

This message does not require any IEs.

6.7.4. LAGRQ Request Message

A LAGRQ is a lag request. It is sent to determine the lag between two IAX endpoints, including the amount of time used to process a frame through a jitterbuffer (if any). It requires a clock-based time-stamp, and MUST be answered with a LAGRP, which MUST echo the LAGRQ's time-stamp. The lag between the two peers can be computed on the peer sending the LAGRQ by comparing the time-stamp of the LAGRQ and the time the LAGRP was received.

This message does not require any IEs.

6.7.5. LAGRP Response Message

A LAGRP is a lag reply, sent in response to a LAGRQ message. It MUST send the same time-stamp it received in the LAGRQ after passing the received frame through any jitter buffer the peer has configured.

This message does not require any IEs.

6.8. Digit Dialing

Digit Dialing support is an optional portion of the IAX protocol designed to support devices that do not maintain their own dial plans, for instance, analog telephone adapters, or ATAs. The dialing portion of the IAX2 protocol MAY be implemented for the client/phone-side, server side or not all. The exchanges work as a series of Dialing Plan requests (DPREQ) each followed by a response (DPREP) indicating if additional digits SHOULD be collected before sending the call. The sections that follow describe these messages and the rules associated with them.

6.8.1. DPREQ Request Message

A DPREQ is a request for the server to analyze the passed called number and determine if there is a valid dialing pattern on the remote peer. It MUST include the 'called number' IE to specify what extension is being queried. This command is used in the case where a local peer does not handle its own dialplan/extension switching. The local peer can inquire (as a user dials) how the remote peer perceives the 'called number'. If a DPREP is received indicating that the number is valid, a DIAL MAY be sent.

This message MAY be sent by the client and MUST be implemented on servers which provide IAX2 dialing support.

It MUST includes the following Information Element:

6.8.2. DPREP Response Message

A DPREP is a reply to a DPREQ, containing the status of the dialplan entry requested in the 'called number' IE of the DPREQ. It MUST include the 'called number', 'dpstatus', and 'refresh' IEs. The called number is the same one received in the 'called number' IE of the DPREQ. The 'dpstatus' IE contains the status of the dialplan entry referenced by the received called number. The status indicates whether the called number exists, can exist, needs more digits, or is invalid. More information can be found in Section 8.6 (Information Elements) under the DPSTATUS information element. The 'refresh' IE specifies the number of minutes the 'dpstatus' is valid. If the 'refresh' IE is not present, a default 10 minutes period is assumed.

The sending of this message MUST be implemented by servers which support IAX2 dialing. Clients which support IAX2 dialing MUST be capable of receiving such messages.

It MUST includes the following Information Elements:

6.8.3. DIAL Request Message

The DIAL message is used with IAX peers that do not maintain their own dialplan/extension routing. Once an extension is validated by one or more DPREQ/DPREP exchanges, the number MAY be dialed in a DIAL message, using the 'called number' IE to specify the extension it is attempting to reach. The remote peer then handles the remaining aspects of call setup, including ringing the extension and notifying the local peer when it has been answered following the same requirements as the NEW command (Section 6.2.2 (NEW Request Message)).

The following table specifies the IEs used by this message:

6.9. Firmware Download

The IAX protocol can download firmware to devices which request it. This is an optional portion of the protocol designed such that an embedded device can retrieve binary images from a 'server' peer. Note Well: There is no security on firmware downloads.

6.9.1. FWDOWNL Request Message

An FWDOWNL message is a request made by an IAX device to download a firmware binary using the IAX protocol. The FWDOWNL message MUST include the device type and the block IEs. If the recipient is capable of transmitting a firmware image, it does so with a FWDATA message which includes the 'fwblockdesc' (Section 8.6.35 (FWBLOCKDESC) and 'fwblockdata' (target='ie.fwblockdata' />) IEs.

On receiving this message, the server MUST determine if it has the firmware for the specified device and respond with a FWDATA message containing the data block of firmware that was requested. If the firmware is not available or the offset is invalid, it MUST respond with a REJECT message. (See Section 6.2.4 (REJECT Response Message).)

The following table specifies IEs used by this message

6.9.2. FWDATA Response Message

An FWDATA message is sent in response to an FWDOWNL message. It carries a block of a firmware and IEs that identify which block is being carried. The 'fwblockdata' and 'fwblockdesc' IEs are used. If the FWDATA is the last of the transaction (that is, 'fwblockdata' is of length 0), an ACK is required upon receipt. Otherwise, an FWDOWNL requesting the next block to download in the 'fwblockdesc' IE is required.

The ordered set of firmware blocks is concatenated to make up the downloaded firmware.

The following table specifies IEs used by this message

6.10. Provisioning

The IAX protocol allows provisioning of peer devices. This is a useful way to specify configuration information to a device that does not maintain state. Provisioning generally allows for configuration of network information (e.g., server address, UDP port number to use, type of service setting, etc.), user information (e.g., username, password, etc.), and CODEC information (i.e., which CODECs the device MAY use when transmitting media to an IAX peer). Provisioning can be configured for a particular class or type of device using the 'device type' information element, or for one specific device using the 'service identifier' information element.

6.10.1. PROVISION Request Message

A PROVISION message is sent by a provisioning peer to a remote IAX device. It includes either the 'provisioning' or the 'AES provisioning' IE, which contains the data to be used to perform the actual provisioning of the device. The format is device specific.

The following table specifies IEs used by this message

6.11. Miscellaneous

6.11.1. ACK Response Message

An ACK acknowledges the receipt of an IAX message. An ACK is sent upon receipt of a full frame which does not have any other protocol-defined response. An ACK MUST have both a source call number and destination call number. It MUST also not change the sequence number counters, and MUST return the same time-stamp it received. This time-stamp allows the originating peer to determine to which message the ACK is responding. Receipt of an ACK requires no action.

An ACK MAY also be sent as an initial acknowledgment of an IAX message which requires some other protocol-defined message acknowledgment, as long as the required message is also sent within some peer-defined amount of time. This allows the acknowledging peer to delay transmission of the proper IAX message, which may add security against brute-force password attacks during authentication exchanges.

When the following messages are received, an ACK MUST be sent in return: NEW, HANGUP, REJECT, ACCEPT, PONG, AUTHREP, REGREL, REGACK, REGREJ, TXREL. ACKs SHOULD not be expected by any peer and their purpose is purely to force the transport layer to be up to date.

The ACK message does not requires any IEs.

6.11.2. INVAL Response Message

An INVAL is sent as a response to a received message that is not valid. This occurs when an IAX peer sends a message on a call after the remote peer has hungup its end. Upon receipt of an INVAL, a peer MUST destroy its side of a call.

The INVAL message does not requires any IEs.

6.11.3. VNAK Response Message

A VNAK is sent when a message is received out of order, particularly when a mini frame is received before the first full voice frame on a call. It is a request for retransmission of dropped messages. A message is considered out of sequence if the received iseqno is different than the expected iseqno. On receipt of a VNAK, a peer MUST retransmit all frames with a higher sequence number than the VNAK message's iseqno.

The VNAK message does not requires any IEs.

6.11.4. MWI Request Message

An MWI message is used to indicate to a remote peer that it has one or more messages waiting. It MAY include the 'msgcount' IE to specify how many messages are waiting.

The following table specifies IEs used by this message

6.11.5. UNSUPPORT Response Message

An UNSUPPORT message is sent in response to a message that is not supported by an IAX peer. This occurs when an IAX command with an unrecognized or unsupported subclass is received. No action is required upon receipt of this message, though the peer SHOULD be aware that the message referred to in the optionally included 'IAX unknown' IE is not supported by the remote peer.

The following table specifies IEs used by this message

6.12. Media Messages

The IAX protocol supports many types of media and these are transported through the same UDP port as the other messages. Voice and video are unique in that they utilize two different encodings which use two different procedures to support. Abbreviated 'Mini frames' are normally used for audio and video, however, each time the time-stamp is a multiple of 32,768 (0x8000 hex) a standard or 'Full Frame' MAY be sent. This approach facilitates efficiency and reliability by sending compressed messages without guaranteed delivery packets most of the time and periodically having reliable exchanges with the peer which invokes call tear down procedures if communication is no longer successful.

Upon receiving any media message, except the abbreviated audio and video mini frames, an ACK message MUST be sent. The content SHOULD be passed to the application or further to the next call leg. The data MAY be buffered before it is presented to the user.

6.12.1. DTMF Media Message

The message carries a single digit of DTMF (Dual Tone Multiple Frequency). Useful background information about DTMF can be found in [RFC2833] (Schulzrinne, H. and S. Petrack, “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals,” May 2000.), but, note that IAX does not use the RTP protocol.

6.12.2. Voice Media Message

The message carries voice data and indicates the CODEC used.

6.12.3. Video Media Message

The frame carries video data and indicates the video format of the data.

6.12.4. Text Media Message

The frame carries a text message.

6.12.5. Image Media Message

This message carries a single image. The image MUST fit in one message in this version of the protocol.

6.12.6. HTML Media Message

The HTML message class carries HTML and related data as well as status about the display of that HTML page. The subclass parameter indicates the HTML content type. It MAY be a URL, the start, middle or end of a data block.

If a peer receives an HTML message for a channel that does not support HTML, it MUST respond with an HTML message that has the HTML NOT SUPPORTED indication.

When a devices that supports HTML completes loading the page, it SHOULD send a LOAD COMPLETE message

6.12.7. Comfort Noise Media Message

This message indicates that comfort noise SHOULD be played. It has a parameter that indicates the level. The noise is to be locally generated.

7. Message Transport

IAX is sent over UDP and uses an application level protocol to provide reliable transport where needed.

With respect to transport, there are two messages formats: reliable or 'Full Frames' and unacknowledged 'Mini' or 'Meta' frames. All messages except certain voice and video messages are reliable. Reliable messages are transported by a scheme which maintains message counts and time stamps for both peers involved in the call. The counts are per call. Each peer maintains a timer for all reliable messages and MUST periodically retransmit those messages until they acknowledge or the retry limit is exceeded.

When starting a call, the outgoing and incoming messages sequence numbers MUST both be set to zero. Each reliable message that is sent increments the message count by one except the ACK, INVAL, TXCNT, TXACC, and VNAK messages which do not change the message count. The message includes the outgoing message count and the highest numbered incoming message which has been received. In addition, it contains a time-stamp which represents the number of milliseconds since the call started. Or, in the case of certain network timing messages, it contains a copy of the time-stamp sent to it. Timestamps MAY be approximate, but, MUST be in order.

When any message is received, the timestamps in MUST be checked to make sure that they are in order. If a message is received out of order, it MUST be ignored and a VNAK message sent to resynchronize the peers. And if the message is a reliable message, the incoming message counter MUST be used to acknowledge all the messages up to that sequence number which have been sent.

If no acknowledgment is received after a locally configured number of retries, default 4, the call leg SHOULD be considered unusable and the call MUST be torn down without any further interaction on this call leg.

7.1. Trunking

IAX allows multiple media exchanges between the same two peers to be multiplexed into a single trunk call coalescing media payload into a combined packet. This decreases bandwidth usage as there are fewer total packets being transmitted. Trunking MAY occur in one or both directions of an IAX exchange. A trunk consists of a trunk header and one or more trunked IAX calls. The trunk message contains a time-stamp specifying the time of transmission of the trunk frame. The audio data from the trunked calls are encapsulated in the trunk frame following the header. Each trunked call consists of two octets specifying the call's source number, two octets specifying the length in octets of the media data, and the media data itself. IAX permits transmitting the timestamps of each encapsulated mini frame as well, so that accurate timing information can be used for jitter buffers, etc. A flag in the meta command header specifies whether the encapsulated mini frames retain their original timestamps. If they do not retain them, they MUST assume the time-stamp in the trunk header upon being received by the trunk peer.

7.2. Timers

There are various timers in the the IAX protocol. There are other application level timers such as the call timers and ring timer which are beyond the scope of this document. This section describes the IAX timers and specifies their default values and behavior.

7.2.1. Retransmission Timer

The message retransmission procedures are described in section Section 7 (Message Transport). On each call, there is a timer for how long to wait for an acknowledgment of a message. This timer starts at twice the measured round trip time from the last PING/PONG command. If a retransmission is needed, it is exponentially increased until it meets a boundary value. The maximum retry time period boundary is 10 seconds.

7.2.2. Registration Period Timer

Registrations are valid for a specified time period. It is the client's responsibility to renew this registration before the time period expires. The registrations SHOULD be renewed at random intervals to prevent network congestion. A registrar MUST monitor this time period and invalidate the registration if the client/registrant has not renewed their registration before the timer elapses.

7.3. NAT Considerations

IAX is very well suited to operating behind NAT due to its single port approach. This approach eliminates any start of call media stream delays while the NAT gateway establishes a bidirectional port association. Deploying a single IAX server behind a NAT gateway requires little effort. If the server acts as a registrar, the IAX UDP port on the NAT gateway must be forwarded to the server. If the server acts as a registrant, the default, 60 second, REGREQ refresh timer should be sufficient to maintain a port association in the NAT gateway, however, a static port mapping is preferred.

If multiple servers are to be deployed behind a single NAT gateway, most NAT gateways require each IAX server to use different UDP ports. Of course, there may be NAT implementations which recognize when multiple devices utilize the same private port and and manage it appropriately.

7.4. Encryption

IAX supports call encryption using the symmetric key, Rijndael [AES] (U.S. Department of Commerce/N.I.S.T., “FIPS-197, Announcing the Advanced Encryption Standard,” November 2001.) block cipher (also called AES---Advanced Encryption Standard). Rijndael is a 128-bit block cipher utilizing a shared secret. IAX encrypts on a call-by-call basis starting with a plain-text NEW message indicating, in addition to the