RFC 5456
IAX: Inter-Asterisk eXchange Version 2
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.
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.
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=============================> | | | |________________________________________|
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 | | |________________________________________|
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============================> | | | | |
| <-----------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.
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------> | | <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------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.
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.
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
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.
[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>.
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>.
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
Kenneth C. Shumard 3818 N Lakegrove Way Boise, ID 83713 US Phone: +1 208 724 7801 EMail: kshumard@gmail.com