summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5456.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5456.txt')
-rw-r--r--doc/rfc/rfc5456.txt5659
1 files changed, 5659 insertions, 0 deletions
diff --git a/doc/rfc/rfc5456.txt b/doc/rfc/rfc5456.txt
new file mode 100644
index 0000000..36eddc0
--- /dev/null
+++ b/doc/rfc/rfc5456.txt
@@ -0,0 +1,5659 @@
+
+
+
+
+
+
+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]
+