tech-invite   World Map     

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

RFC 5456

 
 
 

IAX: Inter-Asterisk eXchange Version 2

Part 5 of 5, p. 87 to 101
Prev RFC Part

 


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

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

Top      Up      ToC       Page 89 
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=============================>  |
           |                                        |
           |________________________________________|

Top      Up      ToC       Page 90 
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
           |                                        |
           |________________________________________|

Top      Up      ToC       Page 91 
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============================>  |
           |                                        |
           |                                        |

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

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

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

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

Top      Up      ToC       Page 96 
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

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

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

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

Top      Up      ToC       Page 100 
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

Top      Up      ToC       Page 101 
   Kenneth C. Shumard
   3818 N Lakegrove Way
   Boise, ID  83713
   US

   Phone: +1 208 724 7801
   EMail: kshumard@gmail.com