GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5456

Independent Submission M. Spencer Request for Comments: 5456 Digium, Inc. Category: Informational B. Capouch ISSN: 2070-1721 Saint Joseph's College

                                                           E. Guy, Ed.
                                                              Truphone
                                                             F. Miller
                                                  Cornfed Systems, LLC
                                                            K. Shumard
                                                         February 2010
               IAX: Inter-Asterisk eXchange Version 2

Abstract

 This document describes IAX, the Inter-Asterisk eXchange protocol, an
 application-layer control and media protocol for creating, modifying,
 and terminating multimedia sessions over Internet Protocol (IP)
 networks.  IAX was developed by the open source community for the
 Asterisk Private Branch Exchange (PBX) and is targeted primarily at
 Voice over Internet Protocol (VoIP) call control, but it can be used
 with streaming video or any other type of multimedia.
 IAX is an "all in one" protocol for handling multimedia in IP
 networks.  It combines both control and media services in the same
 protocol.  In addition, IAX uses a single UDP data stream on a static
 port greatly simplifying Network Address Translation (NAT) gateway
 traversal, eliminating the need for other protocols to work around
 NAT, and simplifying network and firewall management.  IAX employs a
 compact encoding that decreases bandwidth usage and is well suited
 for Internet telephony service.  In addition, its open nature permits
 new payload type additions needed to support additional services.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.

Spencer, et al. Informational [Page 1] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5456.

IESG Note

 This RFC is not a candidate for any level of Internet Standard.  The
 IETF disclaims any knowledge of the fitness of this RFC for any
 purpose and in particular notes that the decision to publish is not
 based on IETF review for such things as security, congestion control,
 or inappropriate interaction with deployed protocols.  The RFC Editor
 has chosen to publish this document at its discretion.  Readers of
 this document should exercise caution in evaluating its value for
 implementation and deployment.  See RFC 3932 for more information.
 The IESG thinks that this work is related to IETF work done in SIP,
 MMUSIC, and AVT WGs, but this does not prevent publishing.

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Spencer, et al. Informational [Page 2] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

Table of Contents

 1. Introduction ....................................................4
    1.1. Basic Properties ...........................................4
    1.2. Drawbacks ..................................................5
 2. IAX Terminology .................................................6
 3. Overview of IAX Protocol ........................................6
 4. Naming Conventions ..............................................8
 5. IAX Uniform Resource Identifiers ................................8
    5.1. IAX URI Scheme Registration ................................8
    5.2. URI Comparison ............................................11
 6. Peer Behavior and Related Messages .............................11
    6.1. Registration (OPTIONAL) ...................................12
    6.2. Call Leg Management .......................................18
    6.3. Call Control ..............................................24
    6.4. Mid-Call Link Operations ..................................26
    6.5. Call Path Optimization ....................................28
    6.6. Call Tear Down ............................................33
    6.7. Network Monitoring ........................................33
    6.8. Digit Dialing .............................................34
    6.9. Miscellaneous .............................................36
    6.10. Media Messages ...........................................38
 7. Message Transport ..............................................39
    7.1. Trunking ..................................................40
    7.2. Timers ....................................................41
    7.3. NAT Considerations ........................................41
    7.4. Encryption ................................................42
 8. Message Encoding ...............................................42
    8.1. Frame Structure ...........................................42
    8.2. Frame Types ...............................................52
    8.3. Control Frames Subclasses .................................55
    8.4. IAX Frames ................................................56
    8.5. HTML Command Subclasses ...................................58
    8.6. Information Elements ......................................58
    8.7. Media Formats .............................................86
 9. Example Message Flows ..........................................87
    9.1. Ping/Pong .................................................88
    9.2. Lagrq/Lagrp ...............................................88
    9.3. Registration ..............................................89
    9.4. Registration Release ......................................89
    9.5. Call Path Optimization ....................................90
    9.6. IAX Media Call ............................................91
    9.7. IAX Media Call via an IAX Device ..........................93
 10. Security Considerations .......................................94
 11. IANA Considerations ...........................................96
 12. Implementation Notes ..........................................96
 13. Acknowledgments ...............................................97

Spencer, et al. Informational [Page 3] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 14. References ....................................................97
    14.1. Normative References .....................................97
    14.2. Informative References ...................................99

1. Introduction

 Numerous protocols have been specified by the Internet community to
 support control or signaling of multimedia sessions, for instance,
 SIP [RFC3261], Media Gateway Control Protocol (MGCP) [RFC3435], and
 MEGACO/H.248 [RFC3525] (which has been obsoleted and made historic by
 [RFC5125]).  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 used to carry the actual stream.  SIP commonly uses Session
 Description Protocol (SDP) [RFC4566] to specify Real-Time Transport
 Protocol (RTP) [RFC3550] streams.  This method allows for great
 flexibility, but again leads to more overhead.  Furthermore,
 multimedia solutions that use different, perhaps dynamic, network
 addresses for signaling and media transmission frequently suffer from
 Network Address Translation (NAT) traversal and security challenges.
 IAX is the Inter-Asterisk eXchange protocol, which facilitates VoIP
 connections between servers, and between servers and clients that
 also use the IAX protocol.  IAX was created through an open source
 methodology rather than through a traditional, standards-based
 methodology.  It is an open protocol originally used by Asterisk, a
 dual-licensed open source and commercial PBX server from Digium.
 Independent IAX implementations may be open, proprietary, or licensed
 in anyway the author seems fit without royalty to the protocol
 creators.

1.1. Basic Properties

 IAX is a robust and full-featured, yet, simple protocol.  It 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 more efficient for VoIP than protocols
 that 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 less bandwidth than more
 general approaches.  IAX is a binary protocol, designed to reduce
 overhead, especially in regards to voice streams.  Bandwidth
 efficiency, in some places, is sacrificed in exchange for bandwidth
 efficiency for individual voice calls.  For example, when

Spencer, et al. Informational [Page 4] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 transmitting a voice stream compressed to 8 kbit/s with a 20 ms
 packetization, each data packet consists of 20 bytes.  IAX adds 20%
 overhead, 4 bytes, on the majority of voice packets while RTP adds
 60% overhead with 12 additional bytes per voice packet.
 In addition to efficiency, IAX's single static UDP port approach
 makes IAX traffic easy for network managers to shape, prioritize, and
 pass through firewalls.  IAX's basic structure is that it multiplexes
 signaling and multiple media streams over a single UDP stream between
 two computers.  IAX also uses the same UDP port for both its
 signaling and media messages, and because all communications
 regarding a call are done over a the same point-to-point path, NAT
 traversal is much simpler for IAX than for other commonly deployed
 protocols.

1.2. Drawbacks

 While IAX is very effective, addressing many of today's
 communications needs, it does have a few limitations.  For instance,
 IAX uses a point-to-point codec negotiation mechanism that limits
 extensibility because every IAX node in a call path must support
 every used codec to some degree.  In addition, the codec definition
 is controlled by an internally defined 32-bit mask, so the codecs
 must be defined in the protocol, and the maximum number of
 simultaneous codecs is, therefore, limited.
 One of IAX's design strengths also presents a potential problem.  The
 use of a single, well-known, port makes the protocol an easier target
 for denial-of-service attacks.  Real-time systems like VoIP are
 particularly sensitive to these attacks.
 The protocol is typically deployed with all signaling and media going
 to a centralized server.  While this combined path approach provides
 a great deal of control, it limits the overall system scalability.
 IAX now provides the ability to split the media from the signaling
 stream, which overcomes this limitation of earlier IAX versions.
 Most IAX drawbacks are due to implementation issues rather than
 protocol issues.  Threading presents a series of problems.  Many
 implementations have a limited number of threads available to process
 IAX traffic and can become overwhelmed by high use or denial-of-
 service attacks.  Newer implementations have additional controls to
 minimize the impact of these challenges.

Spencer, et al. Informational [Page 5] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

2. IAX Terminology

 The key words "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].
 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 that 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].

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

Spencer, et al. Informational [Page 6] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 calls using Internet Protocol.  This document describes Version 2 of
 IAX; Version 1, although somewhat similar in design, utilized a
 different port and was not widely deployed.
 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 [RFC3261].
 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 (Integrated Services Digital Network).  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 allowing multiple
 security methods for peer registration.  IAX also specifies a generic
 framework for native encryption.

Spencer, et al. Informational [Page 7] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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].  However, this is not required.
 Username:  A username is a string used for identification purposes.

5. IAX Uniform Resource Identifiers

5.1. IAX URI Scheme Registration

 This section registers IAX according to the guidelines in [RFC4395].
 URI scheme name:
    iax.
 Status:
    Permanent.
 URI scheme syntax:
    The "iax:" scheme follows the guidelines in [RFC3986].
    The general form is as follows:
       iax:[username@]host[:port][/number[?context]]
       where these tokens have the following meanings:
       iax:  The literal 'iax:'.
       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.  An IPv6 address must be enclosed within brackets
          (i.e., '[2001:db8::1]') as defined in [RFC3986].  Using the
          fully-qualified domain name form is RECOMMENDED whenever
          possible.

Spencer, et al. Informational [Page 8] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

       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.
    Examples
       iax:example.com/alice
       iax:example.com:4569/alice
       iax:example.com:4570/alice?friends
       iax:192.0.2.4:4569/alice?friends
       iax:[2001:db8::1]:4569/alice?friends
       iax:example.com/12022561414
       iax:johnQ@example.com/12022561414
    ABNF
       Formal syntax is defined using ABNF [RFC5234].  Certain values
       are included by reference from [RFC3986]:
          iax-uri     = "iax:" [ userinfo "@" ] host [ ":" port ]
                        [ "/" number [ "?" context ] ]
          userinfo    = <as specified in RFC 3986>
          host        = <as specified in RFC 3986>
          port        = <as specified in RFC 3986>
          number      = *(unreserved / sub-delims / pct-encoded )
          context     = *(unreserved / sub-delims / pct-encoded )
          unreserved  = <as specified in RFC 3986>
          sub-delims  = <as specified in RFC 3986>
          pct-encoded = <as specified in RFC 3986>
 URI Scheme Semantics:
    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 IAX.  An IAX URI contains enough information to
    initiate an IAX-based call with that resource.

Spencer, et al. Informational [Page 9] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

    IAX URIs are associated with server resources to which calls may
    be routed.  For instance, an IAX URI may represent an appearance
    on a phone, a voice-mail box on a messaging service, an
    interactive program, a Public Switched Telephone Network (PSTN)
    address or gateway, or any group of the above.
    The IAX URI scheme translates into a location that may be used by
    the IAX protocol to establish a new call using the URI scheme
    components described in the previous section.  This new call
    function is the only defined operation.
 Encoding considerations:
    IAX URI scheme encoding conforms to the encoding rules established
    for URIs in [RFC3986].
 Applications/protocols that use this URI scheme name:
    The scheme is used by ENUM Dynamic Delegation Discovery System
    (DDDS) services to specify resources that support the IAX
    protocol.  The IAX protocol provides application-layer control and
    media protocol for creating, modifying, and terminating multimedia
    sessions over Internet Protocol (IP) networks.
 Interoperability considerations:
    None.
 Security considerations:
    The IAX URI Scheme does not introduce any new security concerns
    except that it provides a uniform syntax for describing IAX
    resources and that, when published, these addresses are subject to
    various denial-of-service attacks.
 Contact:
    Ed Guy, edguy@emcsw.com, +1.973.437.4519.
 Author/Change controller
    Not Applicable.
 References:
    RFC 5456 (this document)

Spencer, et al. Informational [Page 10] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

5.2. URI Comparison

 Some operations in this specification require determining whether two
 IAX URIs are equivalent.  IAX URIs are compared for equality
 according to the following rules:
 All components of the URI MUST be identical except:
    The port, if omitted, is considered to be the same as the default,
    4569.
    All URI components, except the username field, are case
    insensitive, and MUST be normalized to lower case as per Section
    6.2.2.1 of [RFC3986] before comparison.
 The URIs within each of the following sets are equivalent:
 iax:atlanta.com/alice
 iax:AtLaNtA.com/ALicE
 iax:atlanta.com:4569/alice
 iax:alice@atlanta.com/alice
 iax:alice@AtLaNtA.com:4569/ALicE
 The URIs within the following set are not equivalent:
 iax:ALICE@atlanta.com/alice
 iax:alice@atlanta.com/alice
 NOTE: A host in domain form and in IP address form are NOT considered
 identical even if the host name resolves to an address record that
 matches the given IP address.

6. Peer Behavior and Related 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, 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 MUST NOT have any "Information
 Elements".

Spencer, et al. Informational [Page 11] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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)
    Miscellaneous
    Media Messages
 Each of these behavior topics and the messages involved are described
 in the sections that 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, [RFC3761] or configured using
 the IAX protocol.  IAX provides a facility for one peer to register
 its address and credentials with another so that callers can reach
 the registrant.  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.  MD5 Message-
 Digest authentication [RFC1321] uses an MD5 sum arrangement, but
 still requires that both ends have plaintext access to the secret.
 (See Section 8.6.15.)  Rivest, Shamir, and Adleman's (RSA) algorithm
 [RFC3447] allows unidirectional secret knowledge through public/
 private key pairs.  IAX Private keys SHOULD always be Triple Data
 Encryption Standard (3DES) encrypted [RFC1851].  (See
 Section 8.6.16.)

Spencer, et al. Informational [Page 12] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                       ________________
                      |                |
                      |  Unregistered  |<--------------------------\
                      |________________|                           |
                              |                                    |
                /Init         |                                    |
                ------------  |                                    |
                snd REGREQ    |    +--------+                      |
                              |    |        | rec REGAUTH          |
                       _______V____V___     | -----------          |
                      |                |    | snd REGREQ           |
                      |   Reg Sent     +----+                      |
                      |________________+----------+                |
                              |    ^              | rec REGAUTH    |
                 rec REGACK   |    |              | /No Credentials|
                ------------  |    | REG timeout  | -------------- |
                 snd ack      |    | -------      | snd ack        |
                              |    | REGREQ     __V___             |
                       _______V____|___        |      |            |
                      |                |       |  No  |            |
                      |   Registered   |       | Auth |            |
                      |________________|       |______|            |
                              |                   ^                |
                              |                   | rec REGAUTH    |
                              | release           | /No Credentials|
                              | -------           | -------------- |
                +-------+     | snd REGREL        | snd ack        |
   rec REGAUTH  |       |     |                   |                |
   -----------  |      _V_____V________           |                |
   snd REGREL   |     |                |----------+                |
                +-----+   Releasing    |---------------------------+
                      |________________|      rec ACK
                                              -------
                                                 x
                   __________
  rec  REGREJ     |          |
  ----------   *->| Rejected |
  snd   ack       |__________|
                  Figure 1: Registrant State Diagram
 Registration, illustrated in Figure 1, is performed by a registrant
 that sends a username and a registration 'refresh' period to the
 registrar.  This is accomplished with a REGREQ message.  If
 authentication is required, the registrar responds with the REGAUTH
 message that indicates the types of authentication supported by the

Spencer, et al. Informational [Page 13] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 registrar.  In response, the registrant resends a REGREQ with one of
 the supported authentications.  If the registrant cannot
 authenticate, no further action is necessary.  If accepted, the
 registrar 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.  This time period begins when the registrar sends
 a REGACK message.  A registrant may extend that time period by
 repeating the registration process.  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 9.3 and 9.4 for example call flows.

6.1.2. REGREQ Registration Request Message

 The REGREQ 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 an 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.
 Upon receipt of a REGREQ message that has credentials, a registrar
 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 or the registrar
 cannot validate the credentials, the registrar MUST respond with a
 REGREJ message.  If credentials are not provided, the registrar MUST
 respond with a REGAUTH message that indicates the available
 authentication methods.
 Registrants MUST implement this message and registrars MUST be able
 to process it.
 The following table specifies IEs for this message:

Spencer, et al. Informational [Page 14] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

      +------------+----------------+-------------+-------------+
      | IE         | Section        | Status      | Comments    |
      +------------+----------------+-------------+-------------+
      | Username   | Section 8.6.6  | Required    |             |
      |            |                |             |             |
      | MD5 Result | Section 8.6.15 | Conditional | per REGAUTH |
      |            |                |             |             |
      | RSA Result | Section 8.6.16 | Conditional | per REGAUTH |
      |            |                |             |             |
      | Refresh    | Section 8.6.18 | Optional    |             |
      +------------+----------------+-------------+-------------+

6.1.3. REGAUTH Registration Authentication Response Message

 A REGAUTH is a response to a REGREQ or REGREL.  It is sent when a
 registrar 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 registrant MUST resend the
 REGREQ or REGREL message with one of the requested credentials, if it
 has the specified credentials.
 Registrars MUST implement this message and registrants MUST be able
 to process it.
 The following table specifies IEs for this message:
    +--------------+----------------+-------------+---------------+
    | IE           | Section        | Status      | Comments      |
    +--------------+----------------+-------------+---------------+
    | Username     | Section 8.6.6  | Required    |               |
    |              |                |             |               |
    | Auth Methods | Section 8.6.13 | Required    |               |
    |              |                |             |               |
    | Challenge    | Section 8.6.14 | Conditional | If RSA or MD5 |
    +--------------+----------------+-------------+---------------+

6.1.4. REGACK Registration Acknowledgment Message

 A REGACK is 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 MUST be
 assumed.  A REGACK MAY also include the 'username' and 'apparent

Spencer, et al. Informational [Page 15] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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:
      +------------------+----------------+----------+----------+
      | IE               | Section        | Status   | Comments |
      +------------------+----------------+----------+----------+
      | Username         | Section 8.6.6  | Required |          |
      |                  |                |          |          |
      | Date Time        | Section 8.6.28 | Required |          |
      |                  |                |          |          |
      | Apparent Address | Section 8.6.17 | Required |          |
      |                  |                |          |          |
      | Message Count    | Section 8.6.23 | Optional |          |
      |                  |                |          |          |
      | Calling Number   | Section 8.6.2  | Optional |          |
      |                  |                |          |          |
      | Calling Name     | Section 8.6.4  | Optional |          |
      |                  |                |          |          |
      | Refresh          | Section 8.6.18 | Optional |          |
      +------------------+----------------+----------+----------+

6.1.5. REGREJ Registration Rejection Message

 A REGREJ indicates that a registration request has been rejected.
 This rejection can occur for several reasons.  A REGREJ MUST include
 the 'causecode' and 'cause' IEs to specify why registration was
 rejected.
 Upon receipt of a REGREJ message, the registrant MUST consider
 registration process unsuccessful and no further interaction is
 required.  A peer MAY reinitiate the process at later time accounting
 for potential configuration changes on the registrar or registrant.
 Both registrants and registrars MUST be capable of sending and
 processing this message.
 The following table specifies IEs for this message:

Spencer, et al. Informational [Page 16] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

         +------------+----------------+----------+----------+
         | IE         | Section        | Status   | Comments |
         +------------+----------------+----------+----------+
         | Cause      | Section 8.6.21 | Required |          |
         |            |                |          |          |
         | Cause Code | Section 8.6.33 | Required |          |
         +------------+----------------+----------+----------+

6.1.6. REGREL Registration Release Request Message

 A REGREL is used by a registrant for 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 process it.
 The following table specifies IEs for this message:
 +----------+----------------+-------------+-------------------------+
 | IE       | Section        | Status      | Comments                |
 +----------+----------------+-------------+-------------------------+
 | Username | Section 8.6.6  | Required    |                         |
 |          |                |             |                         |
 | MD5      | Section 8.6.15 | Conditional | MD5 or RSA Result is    |
 | Result   |                |             | required                |
 |          |                |             |                         |
 | RSA      | Section 8.6.16 | Conditional |                         |
 | Result   |                |             |                         |
 |          |                |             |                         |
 | Cause    | Section 8.6.21 | Optional    |                         |
 |          |                |             |                         |
 | Cause    | Section 8.6.33 | Optional    |                         |
 | Code     |                |             |                         |
 +----------+----------------+-------------+-------------------------+

Spencer, et al. Informational [Page 17] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

6.2. Call Leg Management

                                        +--------+  HANGUP/ack
                                        |        |
                           _____________|__      |
                          |                |     |
               +--------->|    Initial     |<----+
               |          |________________|<---------------------+
               |                  |                               ^
               |       start call |                               |
               |       ---------- |                               |
               |       send NEW   |  +-------+                    |
               |                  |  |       |  rec AUTHREQ       |
               |             _____V__V__     |  -----------       |
               |            |           |    |  snd AUTHREP       |
               +------------|  Waiting  |----+                    |
       rec REJECT           |___________|------------------------>+
       ----------                  |                              |
         ack                       |              rec HANGUP      |
                                   |              ---------       |
                                   |              snd ack         |
                                   |                              |
                     rec ACCEPT    |                              |
                     ----------    |   +------+                   |
                     snd ack       |   |      | PROCEEDING / ack  |
                          _________V___V      | RINGING / ack     |
                         |              |     |                   |
                         |     Linked   |-----+                   |
                         |______________|------------------------>+
                                  |               rec HANGUP      |
                     rec ANSWER   |               ----------      |
                     -----------  |               snd ack         |
                     snd ack      |                               |
                                  |                               |
                                  |               rec HANGUP      |
                           _______V________       ---------       |
                          |                |      snd ack         |
                          |      UP        |--------------------->+
                          |________________|--------------------->+
                                                  finish
                                                  ------
                                                  snd HANGUP
               Figure 2: Call Origination State Diagram

Spencer, et al. Informational [Page 18] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                               +--------+ rec HANGUP/ack
                               |        |
                  _____________V__      | rec NEW(no Auth)/snd AUTHREQ
                 |                |     |
                 |    Initial     |-----+ rec NEW(not Auth)/snd REJECT
                 |                |
                 |________________|<--------------------+
                         |                              |
           rec NEW       |                              |
      (valid credentials)|                              |
           ----------    |   +------+                   |
           snd ACCEPT    |   |      | snd PROCEEDING    |
                _________V___V      | snd RINGING       |
               |              |     |                   |
               |     Linked   |-----+                   |
               |              |
               |______________|------------------------>+
                        |               rec HANGUP      |
            /answered   |               ----------      |
           -----------  |               snd ack         |
           snd ANSWER   |                               |
                        |               rec HANGUP      |
                 _______V________       ---------       |
                |                |       snd ack        |
                |      UP        |--------------------->+
                |________________|--------------------->+
                                        finish
                                        ------
                                        snd HANGUP
               Figure 3: Call Termination State Diagram

6.2.1. Overview

 The IAX protocol can be used to set up 'links' or 'call legs' between
 two peers for the purposes of placing a call.  The process,
 illustrated in Figure 2 and Figure 3, 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.  ACCEPT indicates that the call
 leg between these two peers is established and that higher-level call
 signaling (Section 6.3) MAY proceed.  After sending or receiving the

Spencer, et al. Informational [Page 19] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 ACCEPT message, the call leg is in the 'Linked' state and is used to
 pass call control messages until the call is completed.  Further
 detail on messages used for this process can be found in Section 6.3.
 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 compared to other Call
 Supervision messages 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 zero and incrementing by one each millisecond.  Sequence
 numbers for a NEW message, described in the transport section,
 (Section 7) are both set to 0.
 A NEW message MUST include the 'version' IE, and it MUST be the first
 IE; the order of other IEs is unspecified.  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 receiving 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 for
 further details.
 The following table specifies IEs for the NEW message:

Spencer, et al. Informational [Page 20] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 +--------------+----------------+-------------+---------------------+
 | IE           | Section        | Status      | Comments            |
 +--------------+----------------+-------------+---------------------+
 | Version      | Section 8.6.10 | Required    |                     |
 |              |                |             |                     |
 | Called       | Section 8.6.1  | Required    |                     |
 | Number       |                |             |                     |
 |              |                |             |                     |
 | Auto Answer  | Section 8.6.24 | Optional    |                     |
 |              |                |             |                     |
 | Codecs Prefs | Section 8.6.35 | Required    |                     |
 |              |                |             |                     |
 | Calling      | Section 8.6.29 | Required    |                     |
 | Presentation |                |             |                     |
 |              |                |             |                     |
 | Calling      | Section 8.6.2  | Optional    |                     |
 | Number       |                |             |                     |
 |              |                |             |                     |
 | Calling TON  | Section 8.6.30 | Required    |                     |
 |              |                |             |                     |
 | Calling TNS  | Section 8.6.31 | Required    |                     |
 |              |                |             |                     |
 | Calling Name | Section 8.6.4  | Optional    |                     |
 |              |                |             |                     |
 | ANI          | Section 8.6.3  | Optional    |                     |
 |              |                |             |                     |
 | Language     | Section 8.6.9  | Optional    |                     |
 |              |                |             |                     |
 | DNID         | Section 8.6.12 | Optional    |                     |
 |              |                |             |                     |
 | Called       | Section 8.6.5  | Conditional | 'Default' assumed   |
 | Context      |                |             | if IE excluded      |
 |              |                |             |                     |
 | Username     | Section 8.6.6  | Optional    |                     |
 |              |                |             |                     |
 | RSA Result   | Section 8.6.16 | Conditional | If challenged with  |
 |              |                |             | RSA                 |
 |              |                |             |                     |
 | MD5 Result   | Section 8.6.15 | Conditional | If challenged with  |
 |              |                |             | MD5                 |
 |              |                |             |                     |
 | Format       | Section 8.6.8  | Required    |                     |
 |              |                |             |                     |
 | Capability   | Section 8.6.7  | Conditional |                     |
 |              |                |             |                     |
 | ADSICPE      | Section 8.6.11 | Optional    |                     |
 |              |                |             |                     |
 | Date Time    | Section 8.6.28 | Optional    | Suggested           |

Spencer, et al. Informational [Page 21] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 |              |                |             |                     |
 | Encryption   | Section 8.6.34 | Optional    |                     |
 |              |                |             |                     |
 | OSP Token    | Section 8.6.42 | Optional    |                     |
 +--------------+----------------+-------------+---------------------+

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 set
 up on the terminating side, including assigning a CODEC.  An ACCEPT
 message MUST include the 'format' IE to indicate its desired CODEC to
 the originating peer.  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.)  If a subsequent ACCEPT message
 is received for a call that has already started, or has not sent a
 NEW message, the message MUST be ignored.
 The following table specifies IEs for this message:
           +--------+---------------+----------+----------+
           | IE     | Section       | Status   | Comments |
           +--------+---------------+----------+----------+
           | Format | Section 8.6.8 | Required |          |
           +--------+---------------+----------+----------+

6.2.4. REJECT Response Message

 A REJECT response is sent to indicate that a NEW, AUTHREP, DIAL, or
 ACCEPT 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.  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:

Spencer, et al. Informational [Page 22] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

         +------------+----------------+----------+----------+
         | IE         | Section        | Status   | Comments |
         +------------+----------------+----------+----------+
         | Cause      | Section 8.6.21 | Optional |          |
         |            |                |          |          |
         | Cause Code | Section 8.6.33 | Optional |          |
         +------------+----------------+----------+----------+

6.2.5. HANGUP Request Message

 A HANGUP message is sent by either peer and 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 that 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.
 After sending a HANGUP message, the sender MUST destroy the call and
 respond to subsequent messages regarding this call with an INVAL
 message.
 The following table specifies IEs for this message:
         +------------+----------------+----------+----------+
         | IE         | Section        | Status   | Comments |
         +------------+----------------+----------+----------+
         | Cause      | Section 8.6.21 | Optional |          |
         |            |                |          |          |
         | Cause Code | Section 8.6.33 | Optional |          |
         +------------+----------------+----------+----------+

6.2.6. AUTHREP Authentication Reply Message

 An AUTHREP 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:

Spencer, et al. Informational [Page 23] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

       +------------+----------------+-------------+----------+
       | IE         | Section        | Status      | Comments |
       +------------+----------------+-------------+----------+
       | RSA Result | Section 8.6.16 | Conditional | If RSA   |
       |            |                |             |          |
       | MD5 Result | Section 8.6.15 | Conditional | If MD5   |
       +------------+----------------+-------------+----------+

6.2.7. AUTHREQ Authentication Request Message

 The AUTHREQ message 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:
        +--------------+----------------+----------+----------+
        | IE           | Section        | Status   | Comments |
        +--------------+----------------+----------+----------+
        | Username     | Section 8.6.6  | Required |          |
        |              |                |          |          |
        | Auth Methods | Section 8.6.13 | Required |          |
        |              |                |          |          |
        | Challenge    | Section 8.6.14 | Required |          |
        +--------------+----------------+----------+----------+

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 torn down using
 the link-level HANGUP and an appropriate cause code.

Spencer, et al. Informational [Page 24] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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 private extensions to IAX Control messages have been deployed
 for passing application-specific data over the IAX control link.  One
 such extension 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 be 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 (ISDN User Part) 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 the
 called party's service has processed the call request and is being
 alerted to the call.  An IAX RINGING message MUST be sent to an IAX-
 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 IAX 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 ring-back before ringing in order to meet user expectations.
 If the calling party is using the IAX protocol, a RINGING message
 MUST be passed to this caller.
 The RINGING message does not require any IEs.

Spencer, et al. Informational [Page 25] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

6.3.4. ANSWER Response Message

 This message is sent from the called party to indicate that the 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 IAX calls that 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 resume
 transmitting audio on this channel.  If the remote system cannot
 perform this request, it SHOULD be ignored.
 The UNHOLD message SHOULD only be sent in IAX calls after the HOLD
 message.
 The UNHOLD message does not require any IEs.

Spencer, et al. Informational [Page 26] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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 IAX calls after an ACCEPT is
 sent or received; it SHOULD only be used on calls that 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:

Spencer, et al. Informational [Page 27] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 +-----------+---------------+----------+----------------------------+
 | IE        | Section       | Status   | Comments                   |
 +-----------+---------------+----------+----------------------------+
 | Called    | Section 8.6.1 | Required |                            |
 | Number    |               |          |                            |
 |           |               |          |                            |
 | Called    | Section 8.6.5 | Optional | Use this IE if context is  |
 | Context   |               |          | other than default.        |
 +-----------+---------------+----------+----------------------------+

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.

Spencer, et al. Informational [Page 28] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                               ________________
      rec  TXREJ              |                |     rec TXREL
      ----------   *--------->|      None      |<-----------------+
      snd  TXREJ              |________________|        ack       ^
      to other                  |           |                     |
                                |           V                     |
                                |                                 |
                                |           *   (From All)        |
                 /Init Transfer |           | rec TXREQ           |
                  ------------  |           | ---------           |
                    snd TXREQ   |           | snd TXCNT           |
                    to both     |           |                     |
                               _v___________v__                   |
                              |                |                  |
                              |     Begin      |----------------->+
                              |________________|                  |
                                |           |                     |
                      rec TXACC |           | rec TXREADY         |
                      --------- |           | ---------           |
                    snd TXREADY |           |     x               |
                                |           |                     |
                               _v___________v__                   |
                              |                |----------------->+
                    ----------|     Ready      |----------        |
                   |          |________________|          |       |
                   |                   |                  |       |
   /Both Legs Ready|   /Both Legs Ready|       rec TXMEDIA|       |
 and not media-only|    and media-only |                  |       |
     ------------  |    ------------   |       -----------|       |
     snd TXREL     |     snd TXMEDIA   |            x     |       |
                   |                   |                  |       |
               ____V____          _____V___            ___V_____  |
              |         |        |         |          |         | |
              | Release |        |  Media  |          | Media   | |
              |_________|        |_________|          |  Pass   | |
                                       |              |_________| |
                                       |                  |       |
                                       V                  V       |
  rec  TXCNT                           +------------------------->+
  ----------  (In any state)
  snd  TXACC
            Figure 4: Call Path Optimization State Diagram

Spencer, et al. Informational [Page 29] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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.5.
 These messages are described in the sections that follow.

6.5.1. TXREQ Transfer Request Message

 The TXREQ message is sent by a peer to initiate the transfer process.
 When sent, it MUST be sent to both adjacent peers involved in the
 call.
 It MUST include the following Information Elements:
      +------------------+----------------+----------+----------+
      | IE               | Section        | Status   | Comments |
      +------------------+----------------+----------+----------+
      | Apparent Address | Section 8.6.17 | Required |          |
      |                  |                |          |          |
      | Call Number      | Section 8.6.20 | Required |          |
      |                  |                |          |          |
      | Transfer ID      | Section 8.6.26 | Required |          |
      +------------------+----------------+----------+----------+
 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
 corresponding 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.

Spencer, et al. Informational [Page 30] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

6.5.2. TXCNT Transfer Connectivity 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 include the following Information Element:
 +----------+----------------+----------+----------------------------+
 | IE       | Section        | Status   | Comments                   |
 +----------+----------------+----------+----------------------------+
 | Transfer | Section 8.6.26 | Required | A unique number assigned   |
 | ID       |                |          | by the initiator.          |
 +----------+----------------+----------+----------------------------+

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 include the following Information Element:
 +----------+----------------+----------+----------------------------+
 | IE       | Section        | Status   | Comments                   |
 +----------+----------------+----------+----------------------------+
 | Transfer | Section 8.6.26 | Required | A unique number assigned   |
 | ID       |                |          | by the initiator.          |
 +----------+----------------+----------+----------------------------+

6.5.4. TXREADY Transfer Ready 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 include the following Information Element:

Spencer, et al. Informational [Page 31] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 +----------+----------------+----------+----------------------------+
 | IE       | Section        | Status   | Comments                   |
 +----------+----------------+----------+----------------------------+
 | Transfer | Section 8.6.26 | Required | A unique number assigned   |
 | ID       |                |          | by the initiator.          |
 +----------+----------------+----------+----------------------------+

6.5.5. TXREL Transfer Release 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.  The TXREL is also used to
 revert a split-media call (one where the media and signaling follow
 different paths) to a call where the media and signaling follow the
 same path.
 It MUST include the following Information Element:
        +-------------+----------------+----------+----------+
        | IE          | Section        | Status   | Comments |
        +-------------+----------------+----------+----------+
        | Call Number | Section 8.6.20 | Required |          |
        +-------------+----------------+----------+----------+

6.5.6. TXMEDIA Transfer Media Message

 The TXREL message indicates that the MEDIA transfer process has
 successfully completed.  After sending and upon processing of this
 message, Full Frames MUST continue to follow the original signaling
 path and media frames MUST follow the newly negotiated path.  This
 split-path process continues until the call ends with a HANGUP or
 peer receives a TXREL message for the call leg.  A peer MAY force the
 paths to rejoin by sending a TXREL message.
 It MUST include the following Information Element:
        +-------------+----------------+----------+----------+
        | IE          | Section        | Status   | Comments |
        +-------------+----------------+----------+----------+
        | Call Number | Section 8.6.20 | Required |          |
        +-------------+----------------+----------+----------+

Spencer, et al. Informational [Page 32] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

6.5.7. TXREJ Transfer Rejection 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.
    REJECT.  See Section 6.2.4.
    TRANSFER.  See Section 6.4.6.
    TXREADY.  See Section 6.5.4.
 These messages are discussed in their respective sections.  Also, if
 the reliable transport procedures determine 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.

Spencer, et al. Informational [Page 33] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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 Lag 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 jitter buffer (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 Lag 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 IAX protocol MAY be implemented for the client/
 phone-side, server-side or not all.  The exchanges work as a series

Spencer, et al. Informational [Page 34] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 of Dialing Plan requests (DPREQs) 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 Dial Plan 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 IAX dialing support.
 It MUST include the following Information Element:
        +-------------+----------------+----------+----------+
        | IE          | Section        | Status   | Comments |
        +-------------+----------------+----------+----------+
        | Call Number | Section 8.6.20 | Required |          |
        +-------------+----------------+----------+----------+

6.8.2. DPREP Dial Plan 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 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 IAX dialing.  Clients which support IAX dialing MUST be
 capable of receiving such messages.
 It MUST include the following Information Elements:

Spencer, et al. Informational [Page 35] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 +----------+----------------+----------+----------------------------+
 | IE       | Section        | Status   | Comments                   |
 +----------+----------------+----------+----------------------------+
 | Call     | Section 8.6.20 | Required |                            |
 | Number   |                |          |                            |
 |          |                |          |                            |
 | Dial     | Section 8.6.20 | Required | Indicates if number        |
 | Plan     |                |          | exists, is a partial       |
 | Status   |                |          | match, etc.                |
 |          |                |          |                            |
 | Dial     | Section 8.6.20 | Optional | Inclusion is strongly      |
 | Plan     |                |          | suggested.  The default is |
 | Refresh  |                |          | 10 minutes.                |
 +----------+----------------+----------+----------------------------+

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).
 The following table specifies the IEs used by this message:
 +-----------+---------------+----------+----------------------------+
 | IE        | Section       | Status   | Comments                   |
 +-----------+---------------+----------+----------------------------+
 | Called    | Section 8.6.1 | Required |                            |
 | Number    |               |          |                            |
 |           |               |          |                            |
 | Called    | Section 8.6.5 | Optional | Use this IE if context is  |
 | Context   |               |          | other than default.        |
 +-----------+---------------+----------+----------------------------+

6.9. Miscellaneous

6.9.1. ACK: Acknowledgement Message

 An ACK acknowledges the receipt of an IAX message.  An ACK is sent
 upon receipt of a Full Frame that 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

Spencer, et al. Informational [Page 36] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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 that 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.9.2. INVAL: Invalid 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 hung up 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.9.3. VNAK: Voice Negative Acknowledgement 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.9.4. MWI: Message Waiting Indicator 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:

Spencer, et al. Informational [Page 37] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

         +----------+----------------+----------+-----------+
         | IE       | Section        | Status   | Comments  |
         +----------+----------------+----------+-----------+
         | MSGCOUNT | Section 8.6.23 | Optional | Suggested |
         +----------+----------------+----------+-----------+

6.9.5. UNSUPPORT Unsupported 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:
          +---------+----------------+----------+-----------+
          | IE      | Section        | Status   | Comments  |
          +---------+----------------+----------+-----------+
          | UNKNOWN | Section 8.6.22 | Optional | Suggested |
          +---------+----------------+----------+-----------+

6.10. Media Messages

 The IAX protocol supports many types of media and these are
 transported through the same UDP port as other IAX messages.  Voice
 and video are unique in that they utilize two different encodings,
 each with different support procedures.  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' MUST be sent.  This approach facilitates efficiency and
 reliability by sending compressed packets, without guaranteed
 delivery, most of the time while periodically forcing reliable
 exchanges with the peer.  If communication fails, call tear-down
 procedures are invoked.
 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 an associated application, device, or call leg.  The
 data MAY be buffered before it is presented to the user.

6.10.1. DTMF Media Message

 The message carries a single digit of DTMF (Dual Tone Multi-
 Frequency).  Useful background information about DTMF can be found in
 [RFC4733] and [RFC4734], but, note that IAX does not use the RTP
 protocol.

Spencer, et al. Informational [Page 38] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

6.10.2. Voice Media Message

 The message carries voice data and indicates the CODEC used.

6.10.3. Video Media Message

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

6.10.4. Text Media Message

 The frame carries a text message in UTF-8 [RFC3629] format.

6.10.5. Image Media Message

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

6.10.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.  HTML data MUST be in the format described in
 [html401].
 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 device that supports HTML completes loading the page, it
 SHOULD send a LOAD COMPLETE message

6.10.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 message formats: reliable or
 'Full Frames' and unacknowledged 'Mini' or 'Meta' frames.  All
 messages except certain voice and video messages are reliable.
 Reliable messages are transported by a scheme that maintains message

Spencer, et al. Informational [Page 39] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 counts and time-stamps for both peers involved in the call.  The
 counts are per call.  Each peer maintains a timer for all reliable
 messages and MUST periodically retransmit those messages until they
 acknowledge or the retry limit is exceeded.
 When starting a call, the outgoing and incoming message sequence
 numbers MUST both be set to zero.  Each reliable message that is sent
 increments the message count by one except the ACK, INVAL, TXCNT,
 TXACC, and VNAK messages, which do not change the message count.  The
 message includes the outgoing message count and the highest numbered
 incoming message that has been received.  In addition, it contains a
 time-stamp that represents the number of milliseconds since the call
 started.  Or, in the case of certain network timing messages, it
 contains a copy of the time-stamp sent to it.  Time-stamps MAY be
 approximate, but, MUST be in order.
 When any message is received, the time-stamps MUST be checked to make
 sure that they are in order.  If a message is received out of order,
 it MUST be ignored and a VNAK message sent to resynchronize the
 peers.  If the message is a reliable message, the incoming message
 counter MUST be used to acknowledge all the messages up to that
 sequence number that have been sent.
 If no acknowledgment is received after a locally configured number of
 retries (default 4), the call leg SHOULD be considered unusable and
 the call MUST be torn down without any further interaction on this
 call leg.

7.1. Trunking

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

Spencer, et al. Informational [Page 40] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

7.2. Timers

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

7.2.1. Retransmission Timer

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

7.2.2. Registration Period Timer

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

7.3. NAT Considerations

 IAX is very well suited to operating behind NAT due to its single
 port approach.  This approach eliminates any start of call media
 stream delays while the NAT gateway establishes a bidirectional port
 association.  Deploying a single IAX server behind a NAT gateway
 requires little effort.  If the server acts as a registrar, the IAX
 UDP port on the NAT gateway must be forwarded to the server.  If the
 server acts as a registrant, the default, 60 second, REGREQ refresh
 timer should be sufficient to maintain a port association in the NAT
 gateway; however, a static port mapping is preferred.
 If multiple servers are to be deployed behind a single NAT gateway,
 most NAT gateways require each IAX server to use different UDP ports.
 Of course, there may be NAT implementations that recognize when
 multiple devices utilize the same private port and manage it
 appropriately.

Spencer, et al. Informational [Page 41] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

7.4. Encryption

 IAX supports call encryption using the symmetric key, Rijndael [AES]
 block cipher (also called AES -- Advanced Encryption Standard).
 Rijndael is a 128-bit block cipher utilizing a shared secret.  IAX
 encrypts on a call-by-call basis starting with a plaintext NEW
 message indicating, in addition to the other message parameters, that
 the call should be encrypted.  This indication is given by sending
 the ENCRYPTION IE (Section 8.6.34) in the NEW request message.  If
 the called host supports encryption, it will respond with a plaintext
 AUTHREQ message that also includes the ENCRYPTION IE.  All subsequent
 messages in the call MUST be encrypted.  If the called host does not
 support encryption, the AUTHREQ sent in response to the NEW must not
 include the ENCRYPTION IE and the calling host MUST either HANGUP the
 request or continue with the unencrypted call.
 The key to use in encrypting the messages is computed by taking the
 CHALLENGE IE Section 8.6.14 from the AUTHREQ and concatenating any
 one of the shared passwords then computing the 128-bit MD5 digest of
 this combination.  To decrypt, if there is more than one password for
 the peer, each must be tried until the message is successfully
 decoded.  The key remains constant for the duration of the call.
 Only the data portion of the messages are encoded.

8. Message Encoding

8.1. Frame Structure

 This section contains the specification for each type of frame that
 IAX defines.

8.1.1. Full Frames

 Full Frames can send signaling or media data.  Generally, Full Frames
 are used to control initiation, setup, and termination of an IAX
 call, but they can also be used to carry stream data (though this is
 generally not optimal).
 Full Frames are sent reliably, so all Full Frames require an
 immediate acknowledgment upon receipt.  This acknowledgment can be
 explicit via an 'ACK' message (see Section 8.4) or implicit based
 upon receipt of an appropriate response to the Full Frame issued.
 The standard Full Frame header length is 12 octets.

Spencer, et al. Informational [Page 42] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 Field descriptions:
 'F' bit
    This bit specifies whether or not the frame is a Full Frame.  If
    the 'F' bit is set to 1, the frame is a Full Frame.  If it is set
    to 0, it is not a Full Frame.
 Source call number
    This 15-bit value specifies the call number the transmitting
    client uses to identify this call.  The source call number for an
    active call MUST NOT be in use by another call on the same client.
    Call numbers MAY be reused once a call is no longer active, i.e.,
    either when there is positive acknowledgment that the call has
    been destroyed or when all possible timeouts for the call have
    expired.
 'R' bit
    This bit specifies whether or not the frame is being
    retransmitted.  If the 'R' bit is set to 0, the frame is being
    transmitted for the first time.  If it is set to 1, the frame is
    being retransmitted.  IAX does not specify a retransmit timeout;
    this is left to the implementor.
 Destination call number
    This 15-bit value specifies the call number the transmitting
    client uses to reference the call at the remote peer.  This number
    is the same as the remote peer's source call number.  The
    destination call number uniquely identifies a call on the remote
    peer.  The source call number uniquely identifies the call on the
    local peer.
 Time-stamp
    The time-stamp field contains a 32-bit time-stamp maintained by an
    IAX peer for a given call.  The time-stamp is an incrementally
    increasing representation of the number of milliseconds since the
    first transmission of the call.
 OSeqno
    The 8-bit OSeqno field is the outbound stream sequence number.
    Upon initialization of a call, its value is 0.  It increases
    incrementally as Full Frames are sent.  When the counter
    overflows, it silently resets to 0.

Spencer, et al. Informational [Page 43] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 ISeqno
    The 8-bit ISeqno field is the inbound stream sequence number.
    Upon initialization of a call, its value is 0.  It increases
    incrementally as Full Frames are received.  At any time, the
    ISeqno of a call represents the next expected inbound stream
    sequence number.  When the counter overflows, it silently resets
    to 0.
 Frametype
    The Frametype field identifies the type of message carried by the
    frame.  See Section 8.2 for more information.
 'C' bit
    This bit determines how the remaining 7 bits of the Subclass field
    are coded.  If the 'C' bit is set to 1, the Subclass value is
    interpreted as a power of 2.  If it is not set, the Subclass value
    is interpreted as a simple 7-bit unsigned integer.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|     Source Call Number      |R|   Destination Call Number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            time-stamp                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    OSeqno     |    ISeqno     |   Frame Type  |C|  Subclass   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                             Data                              :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 5: Full Frame Binary Format

8.1.2. Mini Frames

 Mini Frames are so named because their header is a minimal 4 octets.
 Mini Frames carry no control or signaling data; their sole purpose is
 to carry a media stream on an already-established IAX call.  They are
 sent unreliably.  This decision was made because VoIP calls typically
 can miss several frames without significant degradation in call
 quality while the incurred overhead in ensuring reliability increases
 bandwidth requirements and decreases throughput.  Further, because

Spencer, et al. Informational [Page 44] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 voice calls are typically sent in real time, lost frames are too old
 to be reintegrated into the audio stream by the time they can be
 retransmitted.
 Field descriptions:
 'F' bit
    Mini Frames MUST have the 'F' bit set to 0 to specify that they
    are not Full Frames.
 Source call number
    The source call number is the number that is used by the
    transmitting peer to identify the current call.
 time-stamp
    Mini frames carry a 16-bit time-stamp, which is the lower 16 bits
    of the transmitting peer's full 32-bit time-stamp for the call.
    The time-stamp allows synchronization of incoming frames so that
    they MAY be processed in chronological order instead of the
    (possibly different) order in which they are received.  The 16-bit
    time-stamp wraps after 65.536 seconds, at which point a full frame
    SHOULD be sent to notify the remote peer that its time-stamp has
    been reset.  A call MUST continue to send mini frames starting
    with time-stamp 0 even if acknowledgment of the resynchronization
    is not received.
 The F bit, source call number, and 16-bit time-stamp comprise the
 entire 4-octet header for a full frame.  Following this header is the
 actual stream data, of arbitrary length, up to the maximum supported
 by the network.
 Mini frames are implicitly defined to be of type 'voice frame'
 (frametype 2; see Section 8.2).  The subclass is implicitly defined
 by the most recent full voice frame of a call (i.e. the subclass for
 a voice frame specifies the CODEC used with the stream).  The first
 voice frame of a call SHOULD be sent using the CODEC agreed upon in
 the initial CODEC negotiation.  On-the-fly CODEC negotiation is
 permitted by sending a full voice frame specifying the new CODEC to
 use in the subclass field.

Spencer, et al. Informational [Page 45] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|     Source call number      |            time-stamp         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                             Data                              :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 6: Mini Frame Binary Format

8.1.3. Meta Frames

 Meta frames serve one of two purposes.  Meta video frames allow the
 transmission of video streams with an optimized header.  They are
 similar in purpose to mini voice frames.  Meta trunk frames are used
 for trunking multiple IAX media streams between two peers into one
 header, to further minimize bandwidth consumption.

8.1.3.1. Meta Video Frames

 Field descriptions:
 'F' bit
    Meta video frames MUST have the 'F' bit set to 0 to indicate that
    they are not full frames.
 Meta Indicator
    The meta indicator is a 15-bit field of all zeroes, used to
    indicate that the frame is a Meta Frame.  Meta Frames are
    identifiable because the first 16 bits will always be zero in any
    Meta Frame, whereas Full or Mini Frames will have either the 'F'
    bit set or some (nonzero) value for the source call number (or
    both).
 'V' bit
    The 'V' bit in a meta video frame is set to 1 to specify that the
    frame is a meta video frame.
 Source call number
    The call number that is used by the transmitting peer to identify
    this video call.

Spencer, et al. Informational [Page 46] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 time-stamp
    Meta video frames carry a 16-bit time-stamp, which is the lower 16
    bits of the transmitting peer's full 32-bit time-stamp for the
    call.  When this time-stamp wraps, a Full Frame SHOULD be sent to
    notify the remote peer that the time-stamp has been reset to 0.
 Following the time-stamp is the actual video stream data.  Meta video
 frames are implicitly defined to be of type 'video frame' (frametype
 3; see Section 8.2).  The video CODEC used is implicitly defined by
 the subclass of the most recent full video frame of a call.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|         Meta Indicator      |V|      Source Call Number     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |?|          time-stamp         |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                         Data                  |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 7: Meta Video Frame Binary Format

8.1.3.2. Meta Trunk Frames

 IAX natively supports two methods of trunking multiple media streams
 between two peers into a single association.  The first method sends
 a standard meta header, along with a single 32-bit time-stamp
 describing the transmission time of the trunk frame.  Following the
 time-stamp are one or more media frames consisting of the call number
 and the length in octets of the stream data included in the frame.
 The second method of trunking is very similar to the first.  It sends
 a standard meta header, including the 32-bit time-stamp describing
 the time of transmission of the trunk frame.  But the media frames
 included in the trunk are actually complete Mini Frames, including
 the 16-bit time-stamp for each call.  The first method uses slightly
 less bandwidth (2 fewer octets per call in the trunk), while the
 second method maintains the individual time-stamps for each call so
 that jitter buffering can use the actual time-stamps associated with
 a call instead of the (less accurate) time-stamp representing the
 entire trunk.  Either method is permissible for trunking.

Spencer, et al. Informational [Page 47] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 Field descriptions:
 'F' bit
    Meta trunk frames MUST have the 'F' bit set to 0 to indicate that
    they are not Full Frames.
 Meta Indicator
    The meta indicator is a 15-bit field of all zeroes, used to
    indicate that the frame is a Meta Frame.  Meta Frames are
    identifiable because the first 16 bits will always be zero in any
    Meta Frame, whereas Full or Mini Frames will have either the 'F'
    bit set or some (nonzero) value for the source call number (or
    both).
 'V' bit
    The 'V' bit in a meta trunk frame is set to 0 to specify that the
    frame is not a meta video frame.
 Meta Command
    This 7-bit field identifies whether or not the Meta Frame is a
    trunk.  A value of '1' indicates that the frame is a meta trunk
    frame.  All other values are reserved for future use.  See the
    IANA Registry for additional IAX Meta Command Assignments.
 Command Data
    This 8-bit field specifies flags for options that apply to a
    trunked call.  The least significant bit of the field is the
    'trunk time-stamps' flag.  A value of 0 indicates that the calls
    in the trunk do not include their individual time-stamps.  A value
    of 1 indicates that the calls do each include their own time-
    stamp.  All other bits are reserved for future use.
 time-stamp
    Meta trunk frames carry a 32-bit time-stamp, which represents the
    actual time of transmission of the trunk frame.  This is distinct
    from the time-stamps of the calls included in the trunk.
 Following the 32-bit time-stamp is one or more trunked calls.  If the
 'trunk time-stamps' flag is set to 0, each entry consists of 2 octets
 specifying the source call number of the call, 2 octets specifying
 the length in octets of the media data, and then the media data.  If
 the 'trunk time-stamps' flag is set to 1, each entry consists of 2

Spencer, et al. Informational [Page 48] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 octets specifying the length in octets of the media data, and then a
 Mini Frame (2 octets specifying source call number, 2 octets
 specifying 16-bit time-stamp, and the media data).  The following two
 diagrams help illustrate this structure.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|         Meta Indicator      |V|Meta Command | Cmd Data (0)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            time-stamp                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|      Source Call Number     |     Data Length (in octets)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                             Data                              :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 .
                                 .
                                 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|      Source Call Number     |     Data Length (in octets)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                             Data                              :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure 8: Meta Trunk Frame Binary Format (trunk time-stamps 0)

Spencer, et al. Informational [Page 49] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|         Meta Indicator      |V|Meta Command | Cmd Data (1)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            time-stamp                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Data Length (in octets)   |R|     Source Call Number      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           time-stamp          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                       Data                    |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 .
                                 .
                                 .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Data Length (in octets)   |R|     Source Call Number      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           time-stamp          |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                       Data                    |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure 9: Meta Trunk Frame Binary Format (trunk time-stamps 1)

8.1.4. Encrypted Frames

 All of the above frames may be encrypted.  The header call numbers
 are passed through in the clear, first 4 bytes for a Full Frame or 2
 bytes for a Mini Frame.  The remainder of the frame is padded with
 between 16 and 32 bytes of random data, then encrypted with AES each
 block being XOR'd with the previous block.  The padding is added at
 the front of the data.
 Figure 10 shows a padded Full Frame before encryption, and Figure 11
 shows the frame after encryption.  Other frame types follow the same
 procedure, except the cleartext portion is shorter, as described
 above.

Spencer, et al. Informational [Page 50] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|     Source Call Number      |R|   Destination Call Number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         12 Random bytes                       |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               28  Random bits                         |padding|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 : between 0 and 15 (as indicated by the padding field above)    :
 :                         Random bytes                          :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                    Remainder of Actual Frame                  :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 10: Full Frame before encryption
 Since AES requires a 16 byte block size, some padding is essential.
 This padding has been placed at the beginning of the payload because
 it makes it more difficult to take advantage of the predictability of
 the IAX frame header.  For example, the first encrypted Frame an IAX
 client sends within an incoming IAX call is entirely predictable: It
 is always an ACK - where even the time-stamp is guessable as it is
 the time the AUTHREP packet was sent.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|     Source Call Number      |R|   Destination Call Number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Encrypted data                        |
 |                Multiple of 16 bytes                           |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 11: Frame after encryption
 The same encryption rules apply to the Mini Frames, except that the
 initial unencrypted portion is only 2 bytes.

Spencer, et al. Informational [Page 51] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.2. Frame Types

 The IAX protocol specifies 10 types of possible frames for the
 "frametype" field of a Full Frame.  They are described in the
 following subsections.

8.2.1. DTMF Frame

 The frame carries a single digit of DTMF (Dual Tone Multi-Frequency).
 More information about DTMF can be found in RFC 4733 [RFC4733] and
 [RFC4734].
 For DTMF frames, the subclass is the actual DTMF digit carried by the
 frame.

8.2.2. Voice Frame

 The frame carries voice data.
 The subclass specifies the audio format of the data.  Predefined
 voice formats can be found in Section 8.7.

8.2.3. Video Frame

 The frame carries video data.
 The subclass specifies the video format of the data.  Predefined
 video formats can be found in Section 8.7.

8.2.4. Control Frame

 The frame carries session control data, i.e., it refers to control of
 a device connected to an IAX endpoint.
 The subclass is a value from Section 8.3 describing the device
 control signal.

8.2.5. Null Frame

 Frames with the Null value MUST NOT be transmitted.

8.2.6. IAX Frame

 The frame carries control data that provides IAX protocol-specific
 endpoint management.  This frametype is used to manage IAX protocol
 interactions that are generally independent of the type of endpoints.
 The subclass is a value from Section 8.4 describing an IAX event.

Spencer, et al. Informational [Page 52] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.2.7. Text Frame

 The frame carries a non-control text message in UTF-8 [RFC3629]
 format.
 All text frames have a subclass of 0.

8.2.8. Image Frame

 The frame carries a single image.
 The subclass describes the format of the image from Section 8.7.

8.2.9. HTML Frame

 The frame carries HTML data.
 The subclass is a value from the HTML Subclasses table in
 Section 8.5.

Spencer, et al. Informational [Page 53] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.2.10. Comfort Noise Frame

 The frame carries comfort noise.
 The subclass is the level of comfort noise in -dBov.
 The following table specifies valid Frame Type Values:
 +------+-------------+--------------------------+-------------------+
 | TYPE | Description | Subclass Description     | Data Description  |
 +------+-------------+--------------------------+-------------------+
 | 0x01 | DTMF        | 0-9, A-D, *, #           | Undefined         |
 |      |             |                          |                   |
 | 0x02 | Voice       | Audio Compression Format | Data              |
 |      |             |                          |                   |
 | 0x03 | Video       | Video Compression Format | Data              |
 |      |             |                          |                   |
 | 0x04 | Control     | See Control Frame Types  | Varies with       |
 |      |             |                          | subclass          |
 |      |             |                          |                   |
 | 0x05 | Null        | Undefined                | Undefined         |
 |      |             |                          |                   |
 | 0x06 | IAX Control | See IAX Protocol         | Information       |
 |      |             | Messages                 | Elements          |
 |      |             |                          |                   |
 | 0x07 | Text        | Always 0                 | Raw Text          |
 |      |             |                          |                   |
 | 0x08 | Image       | Image Compression Format | Raw image         |
 |      |             |                          |                   |
 | 0x09 | HTML        | See HTML Frame Types     | Message Specific  |
 |      |             |                          |                   |
 | 0x0A | Comfort     | Level in -dBov of        | None              |
 |      | Noise       | comfort noise            |                   |
 +------+-------------+--------------------------+-------------------+
 Refer to the IANA Registry for additional IAX Frame Type values.

Spencer, et al. Informational [Page 54] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.3. Control Frames Subclasses

 The following table specifies valid Control Frame Subclasses:
 +-------------+---------------+-------------------------------------+
 | VALUE       | Name          | Description                         |
 +-------------+---------------+-------------------------------------+
 | 0x01        | Hangup        | The call has been hungup at the     |
 |             |               | remote end                          |
 |             |               |                                     |
 | 0x02        | Reserved      | Reserved for future use             |
 |             |               |                                     |
 | 0x03        | Ringing       | Remote end is ringing (ring-back)   |
 |             |               |                                     |
 | 0x04        | Answer        | Remote end has answered             |
 |             |               |                                     |
 | 0x05        | Busy          | Remote end is busy                  |
 |             |               |                                     |
 | 0x06        | Reserved      | Reserved for future use             |
 |             |               |                                     |
 | 0x07        | Reserved      | Reserved for future use             |
 |             |               |                                     |
 | 0x08        | Congestion    | The call is congested               |
 |             |               |                                     |
 | 0x09        | Flash Hook    | Flash hook                          |
 |             |               |                                     |
 | 0x0a        | Reserved      | Reserved for future use             |
 |             |               |                                     |
 | 0x0b        | Option        | Device-specific options are being   |
 |             |               | transmitted                         |
 |             |               |                                     |
 | 0x0c        | Key Radio     | Key Radio                           |
 |             |               |                                     |
 | 0x0d        | Unkey Radio   | Unkey Radio                         |
 |             |               |                                     |
 | 0x0e        | Call Progress | Call is in progress                 |
 |             |               |                                     |
 | 0x0f        | Call          | Call is proceeding                  |
 |             | Proceeding    |                                     |
 |             |               |                                     |
 | 0x10        | Hold          | Call is placed on hold              |
 |             |               |                                     |
 | 0x11        | Unhold        | Call is taken off hold              |
 +-------------+---------------+-------------------------------------+
 Refer to the IANA Registry for additional IAX Control Frame Subclass
 values.

Spencer, et al. Informational [Page 55] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.4. IAX Frames

 Frames of type 'IAX' are used to provide management of IAX endpoints.
 They handle IAX signaling (e.g., call setup, maintenance, and tear-
 down).  They MAY also handle direct transmission of media data, but
 this is not optimal for VoIP calls.  They do not carry session-
 specific control (e.g., device state), as this is the purpose of
 Control Frames.  The IAX commands are listed and described below.
 The following table specifies all valid IAX Frame values:
    +------+-----------+-----------------------------------------+
    | Hex  | Name      | Description                             |
    +------+-----------+-----------------------------------------+
    | 0x01 | NEW       | Initiate a new call                     |
    |      |           |                                         |
    | 0x02 | PING      | Ping request                            |
    |      |           |                                         |
    | 0x03 | PONG      | Ping or poke reply                      |
    |      |           |                                         |
    | 0x04 | ACK       | Explicit acknowledgment                 |
    |      |           |                                         |
    | 0x05 | HANGUP    | Initiate call tear-down                 |
    |      |           |                                         |
    | 0x06 | REJECT    | Reject a call                           |
    |      |           |                                         |
    | 0x07 | ACCEPT    | Accept a call                           |
    |      |           |                                         |
    | 0x08 | AUTHREQ   | Authentication request                  |
    |      |           |                                         |
    | 0x09 | AUTHREP   | Authentication reply                    |
    |      |           |                                         |
    | 0x0a | INVAL     | Invalid message                         |
    |      |           |                                         |
    | 0x0b | LAGRQ     | Lag request                             |
    |      |           |                                         |
    | 0x0c | LAGRP     | Lag reply                               |
    |      |           |                                         |
    | 0x0d | REGREQ    | Registration request                    |
    |      |           |                                         |
    | 0x0e | REGAUTH   | Registration authentication             |
    |      |           |                                         |
    | 0x0f | REGACK    | Registration acknowledgement            |
    |      |           |                                         |
    | 0x10 | REGREJ    | Registration reject                     |
    |      |           |                                         |
    | 0x11 | REGREL    | Registration release                    |
    |      |           |                                         |

Spencer, et al. Informational [Page 56] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

    | 0x12 | VNAK      | Video/Voice retransmit request          |
    |      |           |                                         |
    | 0x13 | DPREQ     | Dialplan request                        |
    |      |           |                                         |
    | 0x14 | DPREP     | Dialplan reply                          |
    |      |           |                                         |
    | 0x15 | DIAL      | Dial                                    |
    |      |           |                                         |
    | 0x16 | TXREQ     | Transfer request                        |
    |      |           |                                         |
    | 0x17 | TXCNT     | Transfer connect                        |
    |      |           |                                         |
    | 0x18 | TXACC     | Transfer accept                         |
    |      |           |                                         |
    | 0x19 | TXREADY   | Transfer ready                          |
    |      |           |                                         |
    | 0x1a | TXREL     | Transfer release                        |
    |      |           |                                         |
    | 0x1b | TXREJ     | Transfer reject                         |
    |      |           |                                         |
    | 0x1c | QUELCH    | Halt audio/video [media] transmission   |
    |      |           |                                         |
    | 0x1d | UNQUELCH  | Resume audio/video [media] transmission |
    |      |           |                                         |
    | 0x1e | POKE      | Poke request                            |
    |      |           |                                         |
    | 0x1f | Reserved  | Reserved for future use                 |
    |      |           |                                         |
    | 0x20 | MWI       | Message waiting indication              |
    |      |           |                                         |
    | 0x21 | UNSUPPORT | Unsupported message                     |
    |      |           |                                         |
    | 0x22 | TRANSFER  | Remote transfer request                 |
    |      |           |                                         |
    | 0x23 | Reserved  | Reserved for future use                 |
    |      |           |                                         |
    | 0x24 | Reserved  | Reserved for future use                 |
    |      |           |                                         |
    | 0x25 | Reserved  | Reserved for future use                 |
    +------+-----------+-----------------------------------------+
 Refer to the IANA Registry for additional IAX Frame values.

Spencer, et al. Informational [Page 57] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

8.5. HTML Command Subclasses

 IAX HTML Command Subclasses:
                +--------+----------------------------+
                | NUMBER | DESCRIPTION                |
                +--------+----------------------------+
                | 0x01   | Sending a URL              |
                |        |                            |
                | 0x02   | Data frame                 |
                |        |                            |
                | 0x04   | Beginning frame            |
                |        |                            |
                | 0x08   | End frame                  |
                |        |                            |
                | 0x10   | Load is complete           |
                |        |                            |
                | 0x11   | Peer does not support HTML |
                |        |                            |
                | 0x12   | Link URL                   |
                |        |                            |
                | 0x13   | Unlink URL                 |
                |        |                            |
                | 0x14   | Reject Link URL            |
                +--------+----------------------------+
 Refer to the IANA Registry for additional IAX HTML Command Subclass
 values.

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.

Spencer, et al. Informational [Page 58] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

    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                      |

Spencer, et al. Informational [Page 59] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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

Spencer, et al. Informational [Page 60] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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.

Spencer, et al. Informational [Page 61] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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.

Spencer, et al. Informational [Page 62] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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.

Spencer, et al. Informational [Page 63] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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    :
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 64] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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.

Spencer, et al. Informational [Page 65] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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.

Spencer, et al. Informational [Page 66] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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.

Spencer, et al. Informational [Page 67] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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:

Spencer, et al. Informational [Page 68] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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)    |
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 69] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 70] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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.

Spencer, et al. Informational [Page 71] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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.

Spencer, et al. Informational [Page 72] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 73] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 74] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 75] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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.

Spencer, et al. Informational [Page 76] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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

Spencer, et al. Informational [Page 77] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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.

Spencer, et al. Informational [Page 78] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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  |
 +-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 79] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 +--------+----------------------------------------------------------+
 | 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)                                |

Spencer, et al. Informational [Page 80] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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

Spencer, et al. Informational [Page 81] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 |        |                                                          |
 | 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     |
                       +--------+-------------+

Spencer, et al. Informational [Page 82] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 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       |
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 83] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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.

Spencer, et al. Informational [Page 84] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

                      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         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Spencer, et al. Informational [Page 85] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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

Spencer, et al. Informational [Page 86] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

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

9. Example Message Flows

 This section includes call flow diagrams for some of the various
 types of IAX calls that can be made.  In each diagram, the '='
 character represents a Full Frame and the '-' character represents a
 Mini Frame.  Notes applicable to a generic call may be presented
 alongside each diagram.

Spencer, et al. Informational [Page 87] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

9.1. Ping/Pong

 PING->PONG
         Peer A                                Peer B
          ________________________________________
         |                                        |
    T    |                                        |
    i    |  ===PING============================>  |
    m    |                                        |
    e    |  <============================PONG===  |Has same time-stamp
         |                                        | as received PING.
    |    |  ===ACK=============================>  |Has same time-stamp
    |    |                                        | as received PONG
   \ /   |________________________________________| and original PING.

9.2. Lagrq/Lagrp

 LAGRQ->LAGRP
         Peer A                                Peer B
          ________________________________________
         |                                        |
    T    |                                        |
    i    |  ===LAGRQ===========================>  |
    m    |                                        |
    e    |  <===========================LAGRP===  |Same time-stamp as
         |                                        | received LAGRQ.
    |    |  ===ACK=============================>  |Same time-stamp as
    |    |                                        | received LAGRP and
   \ /   |________________________________________| original LAGRQ.

Spencer, et al. Informational [Page 88] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

9.3. Registration

 Registration of an IAX Peer
       Registrant  A                     Registrar B
          ________________________________________
         |                                        |
    T    |  ===REGREQ==========================>  |
    i    |                                        |
    m    |  <=========================REGAUTH===  |
    e    |                                        |
         |  ===REGREQ==========================>  |
    |    |                                        |
    |    |  <==========================REGACK===  |
  \ | /  |                                        |
   \|/   |  ===ACK=============================>  |
         |                                        |
         |________________________________________|

9.4. Registration Release

 Registration Release
       Registrant A                        Registrar B
          ________________________________________
         |                                        |
    T    |  ===REGREL==========================>  |
    i    |                                        |
    m    |  <=========================REGAUTH===  |
    e    |                                        |
         |  ===REGREL==========================>  |
    |    |                                        |
    |    |  <==========================REGACK===  |
  \ | /  |                                        |
   \|/   |  ===ACK=============================>  |
         |                                        |
         |________________________________________|

Spencer, et al. Informational [Page 89] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

9.5. Call Path Optimization

 IAX Transfer
         Peer L         Peer C                Peer R
          ________________________________________
         |                 |                      |
    T    |                 |                      |
         | <== TXREQ =====[*]== TXREQ =========>  |C requests transfer
    i    |                 |                      |
         | ========================== TXCNT  ==>  |L sends to R
    m    |                 |                      |
         | <========================= TXACC  ==== |R replies
    e    |                 |                      |R sends Media
         |                 |                      | to L
    |    |                 |                      |
    |    | = TXREADY ====> |                      |L tells C 'ready'
    |    |                 |                      | C stops media to L
    |    |                 |                      |
    |    | <== TXCNT ===========================  |L sends to R
    |    |                 |                      |
    |    | === TXACC ===========================> |R replies
   \ /   |                 |                      |
         |                 | <== TXREADY ======   |R tells C 'ready'
         |                 |                      | C stops media to R
         |                 |                      |
         | <== TXREL =====[*]== TXREL =========>  |C Releases
         |                                        |
         |________________________________________|

Spencer, et al. Informational [Page 90] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

9.6. IAX Media Call

 Complete end-to-end IAX media exchange
         Peer A                            Peer B
          ________________________________________
         |                                        |
         |  ====NEW============================>  |
    T    |  <=========================AUTHREQ===  |If authentication
         |                                        |   specified.
    i    |  ====AUTHREP========================>  |
    m    |  <==========================ACCEPT===  |
    e    |  ====ACK============================>  |
         |                                        |
    |    |  <=============Voice (Full Frame)===   |
    |    |  ====ACK===========================>   |
    |    |                                        |
    |    |  <---------Voice Mini Frame (ring)--   |
    |    |  <---------Voice Mini Frame (ring)--   |
    |    |                                        |
  \ | /  |  <=========================RINGING===  |
   \|/   |  ====ACK============================>  |
         |                                        |
         |  <---------Voice Mini Frame (ring)--   |
         |  <---------Voice Mini Frame (ring)--   |
         |                                        |
         |  <==========================ANSWER===  |
         |  ====ACK============================>  |
         |                                        |
         |  ====Voice (Full Frame)=============>  |
         |  <=============================ACK===  |
         |                                        |
         |                                        |
         |  <-----------Voice Mini Frames------>  |  exchange occurs
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <-----------Voice Mini Frames------>  |
         |                                        |
         |                                        |
         |  ====Voice (Full Frame)=============>  |  (note 1)
         |  <===ACK=============================  |  (note 2)
         |                                        |  (every 65536 ms)
         |  <=============Voice (Full Frame)====  |  (note 3)
         |  ====ACK============================>  |
         |                                        |
         |                                        |

Spencer, et al. Informational [Page 91] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

         |  <-----------Voice Mini Frames------>  |
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <-----------Voice Mini Frames------>  |
         |                                        |
         |                                        |
         |  ====HANGUP=========================>  |  Either can hangup
         |  <=============================ACK===  |
         |________________________________________|
 Note 1: Mini Frames carry the low 16 bits of the peer's
         32-bit time-stamp.
 Note 2: Full frames resync the 32-bit time-stamp when the 16-bit
         time-stamp overflows.
 Note 3: Each side has its own 32-bit time-stamp so each side needs
         to sync at 16-bit overflow.

Spencer, et al. Informational [Page 92] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

9.7. IAX Media Call via an IAX Device

 An IAX peer is not required to maintain a complete dialplan.  In the
 event that a user wishes to dial from an IAX peer that does not
 switch its own calls, the following call flow diagram may represent
 the transaction:
         Peer A (IAX Device)                 Peer B (Dialplan Server)
          ________________________________________
         |                                        |
         |  ====NEW============================>  |
    T    |  <=========================AUTHREQ===  |  If auth specified
    i    |  ====AUTHREP========================>  |
    m    |  <==========================ACCEPT===  |
    e    |  ====ACK============================>  |
         |                                        |
         |  ====DPREQ==========================>  |  (Note 1)
    |    |  <===========================DPREP===  |
    |    |                                        |
    |    |  ====DIAL===========================>  |
    |    |  <========================PROGRESS===  |
    |    |  ====ACK============================>  |
  \ | /  |  <==========================ANSWER===  |
   \|/   |  ====ACK============================>  |
         |                                        |
         |  ====Voice (Full Frame)=============>  |
         |  <=============================ACK===  |
         |  <=============Voice (Full Frame)====  |
         |  ====ACK============================>  |
         |                                        |
         |                                        |
         |  <-----------Voice Mini Frames------>  |  Media exchange
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <-----------Voice Mini Frames------>  |
         |                                        |
         |                                        |
         |  ====Voice (Full Frame)=============>  |  (note 2)
         |  <===ACK=============================  |  (note 3)
         |                                        |  (every 65536 ms)
         |  <=============Voice (Full Frame)====  |  (Note 4)
         |  ====ACK============================>  |
         |                                        |
         |                                        |
         |  <-----------Voice Mini Frames------>  |
         |  <---               .            --->  |

Spencer, et al. Informational [Page 93] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

         |  <---               .            --->  |
         |  <---               .            --->  |
         |  <-----------Voice Mini Frames------>  |
         |                                        |
         |                                        |
         |  ====HANGUP=========================>  |  Either can hangup
         |  <=============================ACK===  |
         |________________________________________|
 Note 1: There will be multiple DPREQ/DPREPs per call unless
         dialed number is 1 digit long.
 Note 2: Mini Frames carry the low 16 bits of the peer's
         32-bit time-stamp.
 Note 3: Full Frames resync the 32-bit time-stamp when the 16 bit
         time-stamp overflows.
 Note 4: Each side has its own 32-bit time-stamp so each side needs
         to sync at 16-bit overflow.

10. Security Considerations

 IAX is a binary protocol for setting up point-to-point call legs that
 include both media and signaling.  As such, it is simpler to secure
 than other more general purpose VoIP protocols; however, security
 remains a difficult task and various aspects of the protocol must be
 examined to identify risks.
 IAX registration is an area that requires careful attention.
 Previous protocol versions supported cleartext passwords; this
 feature has been eliminated.  The MD5 and RSA alternatives offer much
 higher security.  Although not specified by the IAX protocol, some
 implementations limit the number of registrants per account to one.
 A subsequent registrant with the same credentials would overwrite the
 prior and receive the calls destined for that user.  Theft of service
 is trivial once a malicious caller has the ability to authenticate.
 In addition, since distinct cause codes are returned to erroneous
 registration attempts, an attacker can distinguish between existent
 and nonexistent users in a registration system, thus resulting in a
 possible directory harvest attack.
 The IAX protocol protects against message replay by using a challenge
 response method.  The IAX registrar or server challenges each call or
 registration with an arbitrary MD5 or RSA challenge.  The response
 and subsequent authorization relies upon knowledge of a shared
 secret.  Since the server typically chooses a challenges using a
 random-number-based technique, the challenge set is large, making
 replay highly unlikely.

Spencer, et al. Informational [Page 94] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 Although operation in the following manner is not recommended, the
 IAX protocol does permit servers to forego the challenge process
 described above.  This open approach is inherently insecure and does
 nothing to prevent unauthorized usage.
 Call Encryption in IAX starts by utilizing static keys.  Once
 negotiated, the key may be changed for the remainder of the call.
 Once the initial key is compromised, all subsequent calls are subject
 to interception.  A more secure implementation would update the key
 frequently and as early as practical during each call.
 The IAX protocol is also susceptible to eavesdropping.  Call Detail,
 i.e., who is calling whom, is sent in unencrypted binary whether or
 not the call is to be encrypted.  Without encryption, call content,
 i.e., audio and video, may be easily intercepted.  However, this
 content is protected if the call is encrypted.
 Man-in-the-middle attacks are a threat to IAX if encryption is not
 used.  This form of attack permits message insertion, deletion, and
 modification such that a call may be redirected or the audio or video
 replaced in either or both directions for the complete or any portion
 of a call.  If encryption is used, the call is protected end to end.
 Note: an initial NEW message in an encrypted call is unencrypted and
 could be changed; however, this is limited to a denial-of-service
 (DoS) attack because subsequent messages containing the same address
 information are redelivered in an encrypted form.
 DoS attacks can take at least two forms in IAX.  One is simply
 overloading the peers with bogus requests.  A carefully implemented
 IAX peer would identify this situation and raise an alarm or take
 other protective action.
 Another form of DoS against an existing call is an engineered attack
 against an existing call.  Injecting media, causing excess processing
 by inserting out-of-order packets, and sending commands such as
 hangup or transfer.  These attacks require close monitoring of the
 binary channel to be successful as the message sequence numbers would
 need to be synchronized with the protocol exchange.
 Of course, providing lower-layer security with Datagram Transport
 Layer Security (DTLS) [RFC4347], or IPsec [RFC4301], would address
 many of these potential issues.
 Unicode [RFC3629] and stringprep [RFC3454] security considerations
 also apply.

Spencer, et al. Informational [Page 95] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

11. IANA Considerations

 In order to facilitate the orderly extension of the IAX protocol,
 several IANA registries have been created.  These registry requests
 are found in [RFC5457].  In addition, the "iax" URI scheme has been
 registered; see Section 5.  Also, IAX has been assigned a well-known
 UDP port number (4569).

12. Implementation Notes

 The original IAX implementation was in Asterisk, the open-source PBX,
 but [wikipedia] lists thirteen other publicly available
 implementations at the time of this writing.  Some of these
 implementations used draft versions of this specification.  Many
 others were developed using the Asterisk source code as the only
 specification.  While this approach is definitive, it is very
 difficult to determine the protocol's higher-level logic and optimize
 it for the particular programming language or application
 environment.  Interoperability of these implementations cannot be
 guaranteed.
 Aside from the trials and tribulations of reverse engineering the
 source code to create a new implementation, the key lessons learned
 involve the use of threads, support of international character sets,
 security, and improved controls to limit interference during DoS
 attacks.
 The current Asterisk implementation has a limited number of IAX
 worker threads and, as a result, its scalability is limited, but it
 can run on low end machines where threads may not be freely
 available.  Improving the threading model will undoubtedly improve
 performance.
 Internationalization and localization are issues that were not
 originally addressed by most implementations.  It was always on the
 IAX developers' road map, but never a priority.  While creating this
 document, we formalized support for UTF-8 encoding to better support
 internationalization and localization.
 With regards to security, many IAX implementations permit cleartext
 authentication.  This method is not secure and should not be used.
 Recently, some issues have been raised regarding server robustness
 when under a DoS attack.  IAX servers that support unauthenticated
 requests can receive the equivalent of a SYN attack.  To mitigate the
 impact of these attacks, various controls to limit the number of
 unauthenticated calls and the number of calls per user may be added

Spencer, et al. Informational [Page 96] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 to the implementation.  Other approaches, such as transferring the
 call to another, more protected port or using IP rate limiting when
 excessive failures are detected, are also suggested.
 Lastly, given the open nature of the protocol and implementations, it
 is very easy to extend.  This situation makes Postel's Robustness
 Principle, "Be conservative in what you do, be liberal in what you
 accept from others", essential to any successful IAX implementation.

13. Acknowledgments

 This work was supported by Internet Foundation Austria.  The authors
 would like to thank Birgit Arkesteijn, Marc Blanchet, Mohamed
 Boucadair, Steve Kann, Olle Johansson, Alexander Mayrhofer, Tim
 Panton, and Peter Saint-Andre for their extensive review and
 technical input.  We would also like to thank Jim Dalton, Christopher
 DeMarco, Frank Ellermann, Daniel Medeiros, Dimitri E. Prado, Leif
 Madson, and Tilghman Lesher for their support and suggestions.

14. References

14.1. Normative References

 [AES]        U.S. Department of Commerce/N.I.S.T., "FIPS-197,
              Announcing the Advanced Encryption Standard",
              November 2001.
 [E164]       ITU-T, "The International Public Telecommunication
              Number Plan",  Recommendation E.164, May 1997.
 [OSP]        European Telecommunications Standards Institute,
              "Telecommunications and Internet Protocol  Harmonization
              Over Networks (TIPHON) Release 4;  Open Settlement
              Protocol (OSP) for  Inter-Domain pricing, authorization
              and usage exchange", November 2003.
 [RFC1321]    Rivest, R., "The MD5 Message-Digest Algorithm",
              RFC 1321, April 1992.
 [RFC1851]    Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
              DES Transform", RFC 1851, September 1995.
 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Spencer, et al. Informational [Page 97] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 [RFC3261]    Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.
 [RFC3447]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.
 [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.
 [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, March 2003.
 [RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.
 [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.
 [RFC3986]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.
 [RFC4347]    Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.
 [RFC4647]    Phillips, A. and M. Davis, "Matching of Language Tags",
              BCP 47, RFC 4647, September 2006.
 [RFC5234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5646]    Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646, September
              2009.
 [html401]    Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
              Specification", World Wide Web Consortium
              Recommendation REC-html401-19991224, December 1999,
              <http://www.w3.org/TR/1999/REC-html401-19991224>.

Spencer, et al. Informational [Page 98] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

14.2. Informative References

 [PKCS]       RSA Laboratories, "PKCS #1 v2.0: RSA Cryptography
              Standard", October 1998.
 [RFC3174]    Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.
 [RFC3435]    Andreasen, F. and B. Foster, "Media Gateway Control
              Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
 [RFC3525]    Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
              "Gateway Control Protocol Version 1", RFC 3525,
              June 2003.
 [RFC3761]    Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.
 [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.
 [RFC4395]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35,
              RFC 4395, February 2006.
 [RFC4566]    Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.
 [RFC4733]    Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
              Digits, Telephony Tones, and Telephony Signals",
              RFC 4733, December 2006.
 [RFC4734]    Schulzrinne, H. and T. Taylor, "Definition of Events for
              Modem, Fax, and Text Telephony Signals", RFC 4734,
              December 2006.
 [RFC5125]    Taylor, T., "Reclassification of RFC 3525 to Historic",
              RFC 5125, February 2008.
 [RFC5457]    Guy, E., "IANA Considerations for IAX: Inter-Asterisk
              eXchange Version 2", RFC 5457, February 2010.
 [wikipedia]  Wikipedia, "Inter-Asterisk eXchange",
              <http://en.wikipedia.org/wiki/IAX>.

Spencer, et al. Informational [Page 99] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

Authors' Addresses

 Mark A. Spencer
 Digium, Inc.
 445 Jan Davis Drive NW
 Huntsville, AL  35806
 US
 Phone: +1 256 428 6000
 EMail: markster@digium.com
 URI:   http://www.digium.com/
 Brian Capouch
 Saint Joseph's College
 PO Box 909
 Rensselaer, IN  47978
 US
 Phone: +1 219 866 6114
 EMail: brianc@saintjoe.edu
 Ed Guy (editor)
 Truphone
 12 Williams Rd
 Chatham, NJ  07928
 US
 Phone: +1 973 437 4519
 EMail: edguy@emcsw.com
 URI:   http://www.truphone.com/
 Frank Miller
 Cornfed Systems, LLC
 3476 Dayton Street
 Denver, CO  80238
 US
 Phone: +1 410 404-8790
 EMail: mail@frankwmiller.net
 URI:   http://www.sipuseragent.net

Spencer, et al. Informational [Page 100] RFC 5456 IAX: Inter-Asterisk eXchange Version 2 February 2010

 Kenneth C. Shumard
 3818 N Lakegrove Way
 Boise, ID  83713
 US
 Phone: +1 208 724 7801
 EMail: kshumard@gmail.com

Spencer, et al. Informational [Page 101]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5456.txt · Last modified: 2010/02/27 02:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki