tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5456

Informational
Pages: 101
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: ~iax

IAX: Inter-Asterisk eXchange Version 2

Part 1 of 5, p. 1 to 11
None       Next RFC Part

 


Top       ToC       Page 1 
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.

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

Top       Page 3 
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

Top      ToC       Page 4 
   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

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
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.

Top      ToC       Page 9 
         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.

Top      ToC       Page 10 
      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)

Top      ToC       Page 11 
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.



(page 11 continued on part 2)

Next RFC Part