M. Spencer
Internet-Draft Digium, Inc.
Expires: May 5, 2006 B. Capouch
Saint Joseph's College
E. Guy
E-MC Software
F. Miller
Cornfed Systems, Inc.
K. Shumard
November 1, 2005
IAX: Inter-Asterisk eXchange Version 2
draft-guy-iax-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Spencer, et al. Expires May 5, 2006 [Page 1]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
This document describes the Inter-Asterisk eXchange protocol, Version
2, an application-layer control and media protocol for creating,
modifying, and terminating streaming media sessions over Internet
Protocol (IP) networks. IAX is targeted primarily at the control of
Voice Over Internet Protocol (VOIP) calls, but can be used with
streaming video or any other type of streaming media.
IAX is an "all in one" protocol for handling streaming media in
Internet Protocol (IP) networks. Specification of both control and
media services in the same protocol decreases bandwidth usage and
allows native support for Network Address Translation (NAT)
transparency. These characteristics make IAX well suited for
Internet telephony.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. IAX Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of IAX functionality . . . . . . . . . . . . . . . . 8
4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 9
5. IAX2 Uniform Resource Indicators . . . . . . . . . . . . . . . 10
5.1. IAX2 URI Components . . . . . . . . . . . . . . . . . . . 10
5.2. Example IAX2 URIs . . . . . . . . . . . . . . . . . . . . 10
5.3. URI Comparison . . . . . . . . . . . . . . . . . . . . . . 11
6. Peer Behavior and Messages . . . . . . . . . . . . . . . . . . 12
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. REGREQ . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. REGAUTH . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. REGACK . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.5. REGREJ . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.6. REGREL . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Call Leg Management . . . . . . . . . . . . . . . . . . . 15
6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. NEW . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. ACCEPT . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.4. REJECT . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.5. HANGUP . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.6. AUTHREP . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.7. AUTHREQ . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Call Control . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. PROCEEDING . . . . . . . . . . . . . . . . . . . . . . 18
6.3.3. RINGING . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.4. ANSWER . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.5. FLASH . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.6. HOLD . . . . . . . . . . . . . . . . . . . . . . . . . 19
Spencer, et al. Expires May 5, 2006 [Page 2]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.3.7. UNHOLD . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. MIDCALL Link Operations . . . . . . . . . . . . . . . . . 19
6.4.1. QUELCH . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.2. UNQUELCH . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.3. TRANSFER . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.4. Call Path Optimization . . . . . . . . . . . . . . . . 20
6.4.5. Call Tear Down . . . . . . . . . . . . . . . . . . . . 22
6.4.6. Network Monitoring . . . . . . . . . . . . . . . . . . 23
6.4.7. Digit Dialing . . . . . . . . . . . . . . . . . . . . 24
6.4.8. DIAL . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.5. Firmware Download . . . . . . . . . . . . . . . . . . . . 25
6.5.1. FWDOWNL . . . . . . . . . . . . . . . . . . . . . . . 25
6.5.2. FWDATA . . . . . . . . . . . . . . . . . . . . . . . . 25
6.6. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 25
6.6.1. PROVISION . . . . . . . . . . . . . . . . . . . . . . 26
6.7. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 26
6.7.1. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.7.2. INVAL . . . . . . . . . . . . . . . . . . . . . . . . 26
6.7.3. VNAK . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7.4. MWI . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7.5. UNSUPPORT . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Media Messages . . . . . . . . . . . . . . . . . . . . . . 27
6.8.1. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8.2. Voice . . . . . . . . . . . . . . . . . . . . . . . . 28
6.8.3. Video . . . . . . . . . . . . . . . . . . . . . . . . 28
6.8.4. Text Frame . . . . . . . . . . . . . . . . . . . . . . 28
6.8.5. Image Media . . . . . . . . . . . . . . . . . . . . . 28
6.8.6. HTML . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.8.7. Comfort Noise Frame . . . . . . . . . . . . . . . . . 28
7. Message Transport . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Trunking . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. Retransmission Timer . . . . . . . . . . . . . . . . . 30
7.2.2. Registration Period Timer . . . . . . . . . . . . . . 30
8. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Full Frames . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Mini frames . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. Meta frames . . . . . . . . . . . . . . . . . . . . . . . 34
8.3.1. Meta Video Frames . . . . . . . . . . . . . . . . . . 34
8.3.2. Meta Trunk Frames . . . . . . . . . . . . . . . . . . 36
8.4. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 38
8.4.1. DTMF Frame . . . . . . . . . . . . . . . . . . . . . . 38
8.4.2. Voice Frame . . . . . . . . . . . . . . . . . . . . . 39
8.4.3. Video Frame . . . . . . . . . . . . . . . . . . . . . 39
8.4.4. Control Frame . . . . . . . . . . . . . . . . . . . . 39
8.4.5. Null Frame . . . . . . . . . . . . . . . . . . . . . . 39
8.4.6. IAX Frame . . . . . . . . . . . . . . . . . . . . . . 39
8.4.7. Text Frame . . . . . . . . . . . . . . . . . . . . . . 39
Spencer, et al. Expires May 5, 2006 [Page 3]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.4.8. Image Frame . . . . . . . . . . . . . . . . . . . . . 39
8.4.9. HTML Frame . . . . . . . . . . . . . . . . . . . . . . 40
8.4.10. Comfort Noise Frame . . . . . . . . . . . . . . . . . 40
8.4.11. Control Frames . . . . . . . . . . . . . . . . . . . . 41
8.4.12. IAX Frames . . . . . . . . . . . . . . . . . . . . . . 42
8.5. HTML Command Subclasses . . . . . . . . . . . . . . . . . 44
8.6. Information Elements . . . . . . . . . . . . . . . . . . . 44
8.6.1. CALLED NUMBER . . . . . . . . . . . . . . . . . . . . 47
8.6.2. CALLING NUMBER . . . . . . . . . . . . . . . . . . . . 48
8.6.3. CALLING ANI . . . . . . . . . . . . . . . . . . . . . 48
8.6.4. CALLING NAME . . . . . . . . . . . . . . . . . . . . . 49
8.6.5. CALLED CONTEXT . . . . . . . . . . . . . . . . . . . . 49
8.6.6. USERNAME . . . . . . . . . . . . . . . . . . . . . . . 50
8.6.7. PASSWORD . . . . . . . . . . . . . . . . . . . . . . . 50
8.6.8. CAPABILITY . . . . . . . . . . . . . . . . . . . . . . 51
8.6.9. FORMAT . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6.10. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . 51
8.6.11. VERSION . . . . . . . . . . . . . . . . . . . . . . . 52
8.6.12. ADSICPE . . . . . . . . . . . . . . . . . . . . . . . 52
8.6.13. DNID . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.6.14. AUTHMETHODS . . . . . . . . . . . . . . . . . . . . . 53
8.6.15. CHALLENGE . . . . . . . . . . . . . . . . . . . . . . 54
8.6.16. MD5 RESULT . . . . . . . . . . . . . . . . . . . . . . 54
8.6.17. RSA RESULT . . . . . . . . . . . . . . . . . . . . . . 55
8.6.18. APPARENT ADDR . . . . . . . . . . . . . . . . . . . . 55
8.6.19. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 57
8.6.20. DPSTATUS . . . . . . . . . . . . . . . . . . . . . . . 57
8.6.21. CALLNO . . . . . . . . . . . . . . . . . . . . . . . . 58
8.6.22. CAUSE . . . . . . . . . . . . . . . . . . . . . . . . 58
8.6.23. IAX UNKNOWN . . . . . . . . . . . . . . . . . . . . . 59
8.6.24. MSGCOUNT . . . . . . . . . . . . . . . . . . . . . . . 59
8.6.25. AUTOANSWER . . . . . . . . . . . . . . . . . . . . . . 60
8.6.26. MUSICONHOLD . . . . . . . . . . . . . . . . . . . . . 60
8.6.27. TRANSFERID . . . . . . . . . . . . . . . . . . . . . . 61
8.6.28. RDNIS . . . . . . . . . . . . . . . . . . . . . . . . 61
8.6.29. PROVISIONING . . . . . . . . . . . . . . . . . . . . . 62
8.6.30. AESPROVISIONING . . . . . . . . . . . . . . . . . . . 62
8.6.31. DATETIME . . . . . . . . . . . . . . . . . . . . . . . 62
8.6.32. DEVICETYPE . . . . . . . . . . . . . . . . . . . . . . 63
8.6.33. SERVICEIDENT . . . . . . . . . . . . . . . . . . . . . 64
8.6.34. FIRMWAREVER . . . . . . . . . . . . . . . . . . . . . 64
8.6.35. FWBLOCKDESC . . . . . . . . . . . . . . . . . . . . . 65
8.6.36. FWBLOCKDATA . . . . . . . . . . . . . . . . . . . . . 65
8.6.37. PROVVER . . . . . . . . . . . . . . . . . . . . . . . 66
8.6.38. CALLINGPRES . . . . . . . . . . . . . . . . . . . . . 66
8.6.39. CALLINGTON . . . . . . . . . . . . . . . . . . . . . . 67
8.6.40. CALLINGTNS . . . . . . . . . . . . . . . . . . . . . . 68
8.6.41. SAMPLINGRATE . . . . . . . . . . . . . . . . . . . . . 69
Spencer, et al. Expires May 5, 2006 [Page 4]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.42. CAUSECODE . . . . . . . . . . . . . . . . . . . . . . 70
8.6.43. ENCRYPTION . . . . . . . . . . . . . . . . . . . . . . 72
8.6.44. ENCKEY . . . . . . . . . . . . . . . . . . . . . . . . 73
8.6.45. CODEC PREFS . . . . . . . . . . . . . . . . . . . . . 73
8.6.46. RR JITTER . . . . . . . . . . . . . . . . . . . . . . 74
8.6.47. RR LOSS . . . . . . . . . . . . . . . . . . . . . . . 74
8.6.48. RR PKTS . . . . . . . . . . . . . . . . . . . . . . . 75
8.6.49. RR DELAY . . . . . . . . . . . . . . . . . . . . . . . 75
8.6.50. RR DROPPED . . . . . . . . . . . . . . . . . . . . . . 75
8.6.51. RR OOO . . . . . . . . . . . . . . . . . . . . . . . . 76
8.7. Media Formats . . . . . . . . . . . . . . . . . . . . . . 77
9. Example Calls . . . . . . . . . . . . . . . . . . . . . . . . 78
9.1. Ping/Pong . . . . . . . . . . . . . . . . . . . . . . . . 78
9.2. Lagrq/Lagrp . . . . . . . . . . . . . . . . . . . . . . . 78
9.3. Registration . . . . . . . . . . . . . . . . . . . . . . . 79
9.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 79
9.5. Firmware Download . . . . . . . . . . . . . . . . . . . . 80
9.6. Call Path Optimization . . . . . . . . . . . . . . . . . . 81
9.7. IAX Media Call . . . . . . . . . . . . . . . . . . . . . . 81
9.8. IAX Media Call via an IAX Device . . . . . . . . . . . . . 83
10. Security Considerations . . . . . . . . . . . . . . . . . . . 85
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 87
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
Intellectual Property and Copyright Statements . . . . . . . . . . 90
Spencer, et al. Expires May 5, 2006 [Page 5]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1. Introduction
There are numerous protocols that specify control or signaling of
streaming media sessions. In general, these protocols are
generalized to offer full support for many distinct 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 do not specify the
media transmission protocol to be used to carry the actual stream.
This allows for greater flexibility, but again leads to more
overhead. Furthermore, streaming media solutions which use different
network addresses for signaling and media transmission frequently
suffer from Network Address Translation (NAT) traversal problems.
IAX 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 much more efficient for VOIP than
protocols which 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
comparatively less bandwidth. Because IAX uses the same UDP port for
both its signaling and media messages, and because all communications
regarding the call are done over a the same point-to-point path, NAT
traversal is much simpler for IAX than for other commonly deployed
protocols.
Spencer, et al. Expires May 5, 2006 [Page 6]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
2. IAX Terminology
The keywords "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 which implements the IAX protocol.
Call: A call is a relationship between two or more parties (i.e.,
resources such as devices or programs) that exists for some time
for the purpose of exchanging audio, video, or other real-time
media. In the context of this document, a call is implemented by
a series of devices or programs where at least the one leg of call
path is implemented using a collection of messages passing from
one IAX peer to another.
Calling Party: A device or program which 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 which specifies user- or call-specific data.
Registrant: A registrant is a peer that makes REGISTER requests in
order to advertize its service location.
Registrar: A registrar is a peer that processes REGISTER requests and
places the information it receives in those requests into the
location service. [RFC3261].
Spencer, et al. Expires May 5, 2006 [Page 7]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
3. Overview of IAX functionality
IAX is a peer-to-peer signaling and media protocol. It can register
locations, create, modify, and 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 Voice calls using Internet Protocol.
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.
IAX is 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 or control data, while Mini
Frames carry media stream data. Full Frames allow optional
'Information Elements' (IEs) to be appended. IEs can describe
various types of user- or call-specific data. Meta frames are used
for call trunking or video stream transmission.
IAX-based calls may extend beyond the peers involved in the IAX
messaging. IAX is responsible for setting up one or more legs of a
complete call path.
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 transfer such that it removes itself from the path.
This supervision is complete, a call is not transferred until all
peers in the transfer confirm they can properly communicate.
IAX provides for security by allowing multiple methods of user
authentication and authorization, as well as peer registration. IAX
also specifies a generic framework for native encryption.
Spencer, et al. Expires May 5, 2006 [Page 8]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
4. Naming Conventions
Call Identifier: A call leg is labeled 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. However, this is not required.
Username: A username is a string used for identification purposes.
Spencer, et al. Expires May 5, 2006 [Page 9]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
5. IAX2 Uniform Resource Indicators
An IAX2 URI identifies a communications resource capable of
communicating using the IAX Version 2 protocol defined herein. And,
an IAX2 URI contains enough information to initiate an IAX2-based
call with that resource.
IAX2 URIs are associated with server resources to which calls may be
routed. For instance, an IAX2 URI may represent an appearance on a
phone, a voice-mail box on a messaging service, an interactive
program, a PSTN address or gateway, or any group of the above.
5.1. IAX2 URI Components
The "iax2:" scheme follows the guidelines in [RFC2526].
The form is as follows:
iax2:[username[:password]@]host[:port][/number[@context]]
where these tokens have the following meanings:
iax2: The literal 'iax2:'.
username: A string used for identification purposes.
password: The password used to access this resource. While the
syntax allows this field to be present, its use is NOT
RECOMMENDED, because the passing of authentication information in
clear text (such as URIs) has proven to be a security risk in
almost every case where it has been used.
host: The domain of the resource. The host part contains either a
fully-qualified domain name or numeric IPv4 or Ipv6 address.
Using the fully-qualified domain name form is RECOMMENDED whenever
possible.
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.
5.2. Example IAX2 URIs
iax2:atlanta.com/alice
iax2:account:secretword@atlanta.com/alice
Spencer, et al. Expires May 5, 2006 [Page 10]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
iax2:atlanta.com:4569/alice
iax2:atlanta.com:4569/alice@friends
iax2:192.0.2.4:4569/alice@friends
iax2:whitehouse.gov/12022561414
5.3. URI Comparison
Some operations in this specification require determining whether two
IAX2 URIs are equivalent. IAX2 URIs are compared for equality
according to the following rules:
All components of the URI MUST be identical except:
A host in domain form and in IP address form are considered
identical if and only if the host name resolves to exactly one
address record and that address record matches the given IP
address.
The port, if omitted, is considered to be the same as the default,
4569.
Only the user and password fields are case sensitive.
The URIs within each of the following sets are equivalent:
iax2:atlanta.com/alice
iax2:AtLaNtA.com/ALicE
iax2:atlanta.com:4569/alice
iax2:atlanta.com:4569/alice
iax2:192.168.1.1/alice (if atlanta.com resolves to 192.168.1.1)
The URIs within each of the following sets are not equivalent:
iax2:ALICE@atlanta.com/alice
iax2:alice@atlanta.com/alice
Spencer, et al. Expires May 5, 2006 [Page 11]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6. Peer Behavior and Messages
Messages are divided into two categories: reliable and best effort.
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 best-effort messages are referred to as "Mini-Frames" and "Meta
Frames" and these more compact messages only have the originating
peer's call identifier and may not have any "Information Elements."
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)
Firmware Download(OPTIONAL)
Provisioning (OPTIONAL)
Miscellaneous
Media Messages
Each of these behavior topics and the messages involved are described
in the sections which follow.
6.1. Registration
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. IAX
Spencer, et al. Expires May 5, 2006 [Page 12]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
provides a facility for one peer to register its address and
credentials with another so that others may locate it. 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. The least
secure is plaintext, which sends passwords cleartext between two
peers and requires that each peer have access to a shared secret.
MD5 uses a challenge/response md5 sum arrangement, but still requires
that both ends have plaintext access to the secret. RSA allows
unidirectional secret knowledge through public/private key pairs.
Private keys SHOULD always be 3DES encrypted.
Registration is performed by a registrant peer that sends a username
to the registrar peer in which registration is desired. This is
accomplished with a REGREQ message. The registrar normally responds
with the REGAUTH message which indicates the types of authentication
that the peer supports. In response, the requesting peer resends a
REGREQ with one of the supported authentications. If accepted, the
registrar sends a REGACK message which MUST indicate the 'apparent
address' and SHOULD indicate the 'refresh' time. If no 'refresh' is
sent a default registration expiration of 60 seconds MUST be assumed.
At any time during this exchange, the registrar may send a REGREJ
messages to indicate failure.
A registration has a specified time period associated with it for
which it is valid. Before this time period expires, a peer may re
register by sending another REGREQ message and performing the
messaging described above. 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.
6.1.2. REGREQ
A REGREQ is a registration request. It occurs independently of any
media-carrying call. A REGREQ MUST include the 'username' and
'refresh' IEs. A REGREQ is used both for a literal 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 or the plaintext password for
authentication.
Upon receipt of a REGREQ message which has credentials, a peer MUST
determine their validity. If valid, it MUST respond with a REGACK
message indicating the time period for which this registration is
Spencer, et al. Expires May 5, 2006 [Page 13]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
valid. If the provided credentials are not valid, the peer MUST
respond with a REJREJ message. If insufficient credentials are
provided, the peer MUST respond with a REGAUTH message that indicates
the available authentication methods.
Registrants MUST be able to send this message and registrars MUST be
able to receive it.
6.1.3. REGAUTH
A REGAUTH is a response to a REGREQ or REGREL. It is sent when a
peer 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 peer SHOULD resend the REGREQ
or REGREL message with one of the requested credentials. If the
authentication credentials are not approved by the registrar,
registration should be considered unsuccessful and a REGREJ message
MUST be sent.
Registrars MUST be able to send this message and registrants MUST be
able to receive it.
6.1.4. REGACK
A REGACK is an acknowledgment of successful registration, 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 SHOULD be assumed. A REGACK
MAY also include the 'username' and 'apparent 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 receive it.
6.1.5. REGREJ
A REGREJ indicates that registration has been rejected. It can occur
for several reasons. A REGREJ SHOULD include the 'causecode' and
'cause' IEs to specify why registration was rejected.
Spencer, et al. Expires May 5, 2006 [Page 14]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Upon receipt of a REGREJ message, the peer SHOULD consider
registration process unsuccessful and no further interaction is
required. A peer MAY reinitiate the the process at later time
accounting for potential configuration changes on the registrar.
Both registrants and registrars SHOULD be capable of sending and
receiving this message.
6.1.6. REGREL
A REGREL is a forced release of 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 receive it.
6.2. Call Leg Management
6.2.1. Overview
The IAX2 protocol can be used to setup 'links' or 'call legs' between
two peers for the purposes of placing a call. The process starts
when a peer sends a NEW message indicating the 'number' (or name) of
a resource on 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. And ACCEPT indicates that the
call leg between these two peers is established and that Higher level
call signaling (Section 6.3) MAY proceed.
6.2.2. NEW
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 in that they do not require a
destination call number in their header. This absense is becuase the
remote peer's source call identifier is not created until after
receipt of this frame. Before sending a NEW message, the local IAX
Spencer, et al. Expires May 5, 2006 [Page 15]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
peer MUST assign a source call number that is not currently being
used for another call. A timestamp MUST also be assigned for the
call, beginning at 0 and incrementing each millisecond. Sequence
numbers for a NEW message, described in the transport section, are
both set to 0.
A NEW message MUST include the 'version' information element, and it
MUST be the first IE. A NEW SHOULD generally include IEs to indicate
routing to the remote peer, e.g., via the 'called number' or 'called
context' IEs. Caller identification and codec negotiation IEs MAY
also be included.
Upon receipt of of a NEW message, the 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.
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 Section 6.3
for further detail.
6.2.3. ACCEPT
An ACCEPT is issued when a NEW message is received, and
authentication has taken place (if so configured). It acknowledges
receipt of a NEW message and indicates that the call leg has been
setup on the remote side, including assigning a CODEC. An ACCEPT
message MUST include the 'format' information element to indicate to
the remote peer its desired CODEC. 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 which has already started, or has not sent a
NEW message, the message SHOULD be ignored. (However, the transport
layer ACK SHOULD still be performed.)
Spencer, et al. Expires May 5, 2006 [Page 16]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.2.4. REJECT
A REJECT is sent to indicate that a request has been denied. It MAY
be due to an authentication failure, an invalid username or a peer
cannot provide a valid password or response to an issued challenge.
It MAY also notify of call setup failure, e.g., when IAX peers cannot
negotiate a CODEC to use or when a firmware download request cannot
be satisfied. 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.
6.2.5. HANGUP
A HANGUP message 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 at its
end. After a HANGUP message has been received for a call, any
messages received which reference that call (i.e., have the same
source/destination call numbers) MUST be answered with an INVAL
message. This indicates that the received message is invalid because
the call no longer exists.
6.2.6. AUTHREP
An AUTHREP is an authentication reply. It 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'.
6.2.7. AUTHREQ
The AUTHREQ message is used as an authentication request. It 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.
Spencer, et al. Expires May 5, 2006 [Page 17]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.3. Call Control
6.3.1. Overview
IAX's call control messages provide high-level signaling functions
common to other telephony control protocols. The messages include
RINGING, ANSWER, BUSY, FLASH, PROCEEDING, HOLD, and UNHOLD. These
messages MUST only be sent after an IAX link 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 town down using
the link-level HANGUP and an appropriate cause code.
In 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 extensions to IAX Control messages have been deployed for
passing application-specific data over IAX control link. One such
extensions 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.
These mandatory IAX control messages are explained below.
6.3.2. PROCEEDING
The PROCEEDING message SHOULD sent to a calling party when their call
request is being processed by a further network element but has not
yet reached the ultimate service destination.
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 Proceeding message, etc. If the prior call leg
is utilizing the IAX2 protocol, a PROCEEDING message MUST be sent to
that peer.
6.3.3. RINGING
This message is sent from a terminating party to indicate that that
the called party's service has processed the call request and is
being alerted to the call. A IAX2 RINGING message MUST be sent to an
IAX2-based calling party when the peer determines that the called
party is being alerted, e.g., when their phone is ringing.
Spencer, et al. Expires May 5, 2006 [Page 18]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Upon receipt of an IAX2 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 ringback before ringing in order to meet user expectations. If
the calling party is using the IAX2 protocol, a RINGING message MUST
be passed to this caller.
6.3.4. ANSWER
This message is sent from the called party to indicate that 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.
6.3.5. FLASH
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.
6.3.6. HOLD
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 IAX2 calls which are started
using the DIAL message.
6.3.7. UNHOLD
The UNHOLD 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 UNHOLD message SHOULD only be sent in IAX2 calls after the HOLD
message.
6.4. MIDCALL Link Operations
Spencer, et al. Expires May 5, 2006 [Page 19]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.4.1. QUELCH
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 IAX2 calls after an ACCEPT is
sent or received; it SHOULD only be used on calls which are started
using the NEW message.
6.4.2. UNQUELCH
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.
6.4.3. TRANSFER
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.
6.4.4. 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 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.
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
Spencer, et al. Expires May 5, 2006 [Page 20]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.6.
These messages are described in the sections which follow:
6.4.4.1. TXREQ
The TXREQ message is sent by a peer to initiate the transfer process.
It MUST be sent to the adjacent peers involved in the call. It MUST
includes the following Information Elements:
APPARENT_ADDR: The IP address data structure address for the other
remote peer.
CALLNO: The callid used by the other remote peer.
TRANSFERID: A unique number assigned by the initiator.
Upon receipt of a TXREQ message for a valid call from the proper
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_ADDR parameter.
6.4.4.2. TXCNT
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.
Spencer, et al. Expires May 5, 2006 [Page 21]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.4.4.3. TXACC
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.
6.4.4.4. TXREADY
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.
6.4.4.5. TXREL
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.
6.4.4.6. TXREJ
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.
6.4.5. 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.3.
TXREADY. See Section 6.4.4.4.
These messages are discussed in their respective sections. Also, if
the reliable transport procedures determines that messaging cannot be
maintained, the call leg MUST be torn down without any other
Spencer, et al. Expires May 5, 2006 [Page 22]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
indications over the errant IAX call leg.
6.4.6. Network Monitoring
The IAX2 protocol has various tools to determine the the network
status. 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.4.6.1. POKE
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 SHOULD respond with a PONG
message.
6.4.6.2. PING
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.
6.4.6.3. PONG
A PONG message is a response to a PING or a POKE. It acknowledges
the connection. The receiver uses the timestamp 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.
6.4.6.4. LAGRQ
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 jitterbuffer (if any). It requires a clock-based
timestamp, and MUST be answered with a LAGRP, which MUST echo the
LAGRQ's timestamp. The lag between the two peers can be computed on
the peer sending the LAGRQ by comparing the timestamp of the LAGRQ
and the time the LAGRP was received.
Spencer, et al. Expires May 5, 2006 [Page 23]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.4.6.5. LAGRP
A LAGRP is a lag reply, sent in response to a LAGRQ message. It MUST
send the same timestamp it received in the LAGRQ after passing the
received frame through any jitterbuffer the peer has configured.
6.4.7. Digit Dialing
Digit Dialing support is an optional portion of the IAX2 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 IAX2 protocol May be implemented for the client/
phone-side, server side or not all. The exchanges work as a series
of Dialing Plan requests (DPREQ) 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.4.7.1. DPREQ
A DPREQ is a request for the server to analyze the passed called
number and determine if is a valid dialing pattern on the remote
peer. the status of a dialplan entry on a 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 IAX2 dialing support.
6.4.7.2. DPREP
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 SHOULD
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 length
of time the 'dpstatus' SHOULD be kept. 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
Spencer, et al. Expires May 5, 2006 [Page 24]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
support IAX2 dialing. Clients which support IAX2 dialing MUST be
capable of receiving such messages.
6.4.8. DIAL
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).
6.5. Firmware Download
The IAX2 protocol can download firmware to devices which request it.
This is an optional portion of the protocol designed such that an
embedded device can retrieve binary images from a 'server' peer.
Note Well: There is no security on firmware downloads.
6.5.1. FWDOWNL
An FWDOWNL message is a request made by an IAX device to download a
firmware binary using the IAX protocol. The FWDOWNL message MUST
include the device type and the block IEs. If the recipient is
capable of transmitting a firmware image, it does so with a FWDATA
message which includes the 'fwblockdesc' and 'fwblockdata' IEs.
On receiving this message, the server MUST determine if it has the
firmware for the specified device and respond with a FWDATA message
containing the data block of firmware that was requested. If the
firmware is not available or the offset is invalid, it MUST respond
with a REJECT message. (See Section 6.2.4.)
6.5.2. FWDATA
An FWDATA message is sent in response to an FWDOWNL message. It
carries a block of a firmware and IEs that identify which block is
being carriedi. The 'fwblockdata' and 'fwblockdesc' IEs are used.
If the FWDATA is the last of the transaction (that is, 'fwblockdata'
is of length 0), an ACK is required upon receipt. Otherwise, an
FWDOWNL requesting the next block to download in the 'fwblockdesc' IE
is required.
6.6. Provisioning
The IAX protocol allows provisioning of peer devices. This is a
Spencer, et al. Expires May 5, 2006 [Page 25]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
useful way to specify configuration information to a device that does
not maintain state. Provisioning generally allows for configuration
of network information (e.g., server address, UDP port number to use,
type of service setting, etc.), user information (e.g., username,
password, etc.), and codec information (i.e., which codecs the device
MAY use when transmitting media to an IAX peer). Provisioning can be
configured for a particular class or type of device using the 'device
type' information element, or for one specific device using the
'service identifier' information element.
6.6.1. PROVISION
A PROVISION message is sent by a provisioning peer to a remote IAX
device. It includes either the 'provisioning' or the 'AES
provisioning' IE, which contains the data to be used to perform the
actual provisioning of the device. The format is device specific.
6.7. Miscellaneous
6.7.1. ACK
An ACK acknowledges the receipt of an IAX message. An ACK is sent
upon reciept of a full frame which does not have any other protocol-
defined response. An ACK MUST have both a source call number and
destination call number. It MUST also increment the sequence number
counters, and return the same timestamp it received. This 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 which requires some other protocol-defined 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.
6.7.2. INVAL
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 hungup its end. Upon receipt of an INVAL, a peer
MUST destroy its side of a call.
Spencer, et al. Expires May 5, 2006 [Page 26]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
6.7.3. VNAK
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.
6.7.4. MWI
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.
6.7.5. UNSUPPORT
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.
6.8. Media Messages
The IAX protocol supports many types of media and these are
transported through the same UDP port as the other messages. Voice
and video are unique in that they utilize two different encodings
which use two different procedures to support. Abbreviated 'Mini
frames' are normally used for audio and video, however, each time the
timestamp is a multiple of 32,768 (0x8000 hex) a standard or 'Full
Frame' MAY be sent. This approach facilitates efficiency and
reliability by sending compressed messages without guaranteed
delivery packets most of the time and periodically having reliable
exchanges with the peer which invokes call tear down procedures if
communication is no longer successful.
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 the application or further to the next call leg. The
data MAY be buffered before it is presented to the user.
6.8.1. DTMF
The message carries a single digit of DTMF (Dual Tone Multiple
Frequency). Useful background information about DTMF can be found in
Spencer, et al. Expires May 5, 2006 [Page 27]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
RFC 2833[RFC2833], but, note that IAX does not use the RTP protocol.
6.8.2. Voice
The message carries voice data and indicates the CODEC used.
6.8.3. Video
The frame carries video data and indicates the video format of the
data.
6.8.4. Text Frame
The frame carries a text message.
6.8.5. Image Media
This message carries a single image. The image MUST fit in one
message.
6.8.6. HTML
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
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 devices that supports HTML completes loading the page, it
SHOULD send a LOAD COMPLETE message
6.8.7. Comfort Noise Frame
This message indicates that comfort noise SHOULD be played. It has a
parameter that indicates the level. The noise is to be locally
generated.
Spencer, et al. Expires May 5, 2006 [Page 28]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 messages formats: reliable
or 'Full Frames' and unconfirmed 'Mini' or 'Meta' frames. All
messages except certain voice and video messages are reliable.
Reliable messages are transported by a scheme which maintains message
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 messages 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 which has been received. In addition, it contains a
time-stamp which 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. Timestamps MAY be
approximate, but, MUST be in order.
When any message is received, the timestamps in 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. And if the message is a reliable message, the incoming
message counter MUST be used to acknowledge all the messages up to
that sequence number which 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. 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 timestamp 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 2 octets specifying the call's source
Spencer, et al. Expires May 5, 2006 [Page 29]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
number, 2 octets specifying the length in octets of the media data,
and the media data itself. IAX permits transmitting the timestamps
of each encapsulated mini frame as well, so that accurate timing
information can be used for jitterbuffers, etc. A flag in the meta
command header specifies whether the encapsulated mini frames retain
their original timestamps. If they do not retain them, they MUST
assume the timestamp in the trunk header upon being received by the
trunk peer.
7.2. Timers
There are various timers in the the IAX2 protocol. There are other
application level timers such as the call timers and ring timer which
are beyond the scope of this document. This section describes the
IAX timers and specifies their default values and behavior.
7.2.1. Retransmission Timer
The message retransmission procedures are described in section
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.
Spencer, et al. Expires May 5, 2006 [Page 30]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8. Message Encoding
This section contains the specification for each type of frame that
IAX defines.
8.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.12) or implicit based
upon receipt of an appropriate response to the full frame issued.
The standard full frame header length is 12 octets.
Field descriptions:
'F' bit
This bit specifies whether the frame is a full frame or not. 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.
when either 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 the frame is being retransmitted or
not. 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
Spencer, et al. Expires May 5, 2006 [Page 31]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.
Timestamp
The Timestamp field contains a 32-bit timestamp maintained by an
IAX peer for a given call. The timestamp 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.
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.4 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 seven bit unsigned integer.
Spencer, et al. Expires May 5, 2006 [Page 32]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSeqno | ISeqno | Frame Type |C| Subclass |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Full Frame Binary Format
8.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
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.
Timestamp
Mini frames carry a 16-bit timestamp, which is the lower 16 bits
of the transmitting peer's full 32-bit timestamp for the call.
The timestamp 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
Spencer, et al. Expires May 5, 2006 [Page 33]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
timestamp wraps after 65.536 seconds, at which point a full frame
SHOULD be sent to notify the remote peer that its timestamp has
been reset. A call MUST continue to send mini frames starting
with timestamp 0 even if acknowledgment of the resynchronization
is not received.
The F bit, source call number, and 16-bit timestamp comprise the
entire four 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.4). 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.
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 | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mini Frame Binary Format
8.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.3.1. Meta Video Frames
Field descriptions:
'F' bit
Spencer, et al. Expires May 5, 2006 [Page 34]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.
Timestamp
Meta video frames carry a 16-bit timestamp, which is the lower 16
bits of the transmitting peer's full 32-bit timestamp for the
call. When this timestamp wraps, a full frame SHOULD be sent to
notify the remote peer that the timestamp has been reset to 0.
Following the timestamp is the actual video stream data. Meta video
frames are implicitly defined to be of type 'video frame' (frametype
3; see Section 8.4). 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|?| Timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Meta Video Frame Binary Format
Spencer, et al. Expires May 5, 2006 [Page 35]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.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 timestamp
describing the transmission time of the trunk frame. Following the
timestamp 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 timestamp 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 timestamp 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 timestamps for each call so
that jitterbuffering can use the actual timestamps associated with a
call instead of the (less accurate) timestamp representing the entire
trunk. Either method is permissible for trunking.
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 numer (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 seven bit field identifies whether the meta frame is a trunk
or not. A value of '1' indicates that the frame is a meta trunk
frame. All other values are reserved for future use.
Command Data
Spencer, et al. Expires May 5, 2006 [Page 36]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
This 8-bit field specifies flags for options which apply to a
trunked call. The least significant bit of the field is the
'trunk timestamps' flag. A value of 0 indicates that the calls in
the trunk do not include their individual timestamps. A value of
1 indicates that the calls do each include their own timestamp.
All other bits are reserved for future use.
Timestamp
Meta trunk frames carry a 32-bit timestamp, which represents the
actual time of transmission of the trunk frame. This is distinct
from the timestamps of the calls included in the trunk.
Following the 32-bit timestamp is one or more trunked calls. If the
'trunk timestamps' 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 timestamps' flag is set to 1, each entry consists of 2
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 timestamp, and the media data). The following 2
diagrams help illustrate this pictorially.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 37]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Figure 4: Meta Trunk Frame Binary Format (trunk timestamps 0)
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Meta Trunk Frame Binary Format (trunk timestamps 1)
8.4. Frame Types
The IAX protocol specifies 10 types of possible frames for the
"frametype" field of a full frame. They are:
8.4.1. DTMF Frame
The frame carries a single digit of DTMF (Dual Tone Multiple
Frequency). More information about DTMF can be found in RFC
2833[RFC2833].
For DTMF frames, the subclass is the actual DTMF digit carried by the
frame.
Spencer, et al. Expires May 5, 2006 [Page 38]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.4.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 below.
8.4.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 below.
8.4.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.4.11 describing the device
control signal.
8.4.5. Null Frame
Frames with the Null value MUST not be transmitted.
8.4.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.12 describing an IAX event.
8.4.7. Text Frame
The frame carries a non-control text message.
All text frames have a subclass of 0.
8.4.8. Image Frame
The frame carries a single image.
The subclass describes the format of the image from Section 8.7
below.
Spencer, et al. Expires May 5, 2006 [Page 39]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.4.9. HTML Frame
The frame carries HTML data.
The subclass is a value from the HTML Subclasses table in
Section 8.5.
8.4.10. Comfort Noise Frame
The frame carries comfort noise.
The subclass is the level of comfort noise in -dBov.
The following table specifies all 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 Messages | Information |
| | | | 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 comfort | None |
| | Noise | noise | |
+------+-------------+---------------------------+------------------+
Spencer, et al. Expires May 5, 2006 [Page 40]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.4.11. Control Frames
The following table specifies all valid Frame Type Values:
+-------------+--------------+--------------------------------------+
| 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 (ringback) |
| | | |
| 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 | Call is in progress |
| | Progress | |
| | | |
| 0x0f | Call | Call is proceeding |
| | Proceeding | |
| | | |
| 0x10 | Hold | Call is placed on hold |
| | | |
| 0x11 | Unhold | Call is taken off hold |
+-------------+--------------+--------------------------------------+
Spencer, et al. Expires May 5, 2006 [Page 41]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.4.12. IAX Frames
Frames of type 'IAX' are used to provide management of IAX endpoints.
They handle IAX signaling (e.g. call setup, maintenance, and
teardown). 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 | Dec | Name | Description |
+------+-----------+------------------------------+-----------------+
| 0x01 | 01 | NEW | Initiate a new |
| | | | call |
| | | | |
| 0x02 | 02 | PING | Ping request |
| | | | |
| 0x03 | PONG | Ping or poke reply | 0x04 |
| | | | |
| 04 | ACK | Explicit acknowledgment | 0x05 |
| | | | |
| 05 | HANGUP | Initiate call teardown | 0x06 |
| | | | |
| 06 | REJECT | Reject a call | 0x07 |
| | | | |
| 07 | ACCEPT | Accept a call | 0x08 |
| | | | |
| 08 | AUTHREQ | Authentication request | 0x09 |
| | | | |
| 09 | AUTHREP | Authentication reply | 0x0a |
| | | | |
| 10 | INVAL | Invalid message | 0x0b |
| | | | |
| 11 | LAGRQ | Lag request | 0x0c |
| | | | |
| 12 | LAGRP | Lag reply | 0x0d |
| | | | |
| 13 | REGREQ | Registration request | 0x0e |
| | | | |
| 14 | REGAUTH | Registration authentication | 0x0f |
| | | | |
| 15 | REGACK | Registration acknowledgement | 0x10 |
| | | | |
| 16 | REGREJ | Registration reject | 0x11 |
| | | | |
| 17 | REGREL | Registration release | 0x12 |
Spencer, et al. Expires May 5, 2006 [Page 42]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| 18 | VNAK | Video/Voice retransmit | 0x13 |
| | | request | |
| | | | |
| 19 | DPREQ | Dialplan request | 0x14 |
| | | | |
| 20 | DPREP | Dialplan reply | 0x15 |
| | | | |
| 21 | DIAL | Dial | 0x16 |
| | | | |
| 22 | TXREQ | Transfer request | 0x17 |
| | | | |
| 23 | TXCNT | Transfer connect | 0x18 |
| | | | |
| 24 | TXACC | Transfer accept | 0x19 |
| | | | |
| 25 | TXREADY | Transfer ready | 0x1a |
| | | | |
| 26 | TXREL | Transfer release | 0x1b |
| | | | |
| 27 | TXREJ | Transfer reject | 0x1c |
| | | | |
| 28 | QUELCH | Halt audio/video [media] | 0x1d |
| | | transmission | |
| | | | |
| 29 | UNQUELCH | Resume audio/video [media] | 0x1e |
| | | transmission | |
| | | | |
| 30 | POKE | Poke request | 0x1f |
| | | | |
| 31 | Reserved | Reserved for future use | 0x20 |
| | | | |
| 32 | MWI | Message waiting indication | 0x21 |
| | | | |
| 33 | UNSUPPORT | Unsupported message | 0x22 |
| | | | |
| 34 | TRANSFER | Remote transfer request | 0x23 |
| | | | |
| 35 | PROVISION | Provision an IAX device | 0x24 |
| | | | |
| 36 | FWDOWNL | Download firmware request | 0x25 |
| | | | |
| 37 | FWDATA | Transmit firmware data | |
+------+-----------+------------------------------+-----------------+
Spencer, et al. Expires May 5, 2006 [Page 43]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.5. HTML Command Subclasses
IAX HTML Command Subclasses:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUMBER | DESCRIPTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Sending a URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Data frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Beginning frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | End frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 | Load is complete |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 17 | Peer does not support HTML |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 18 | Link URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 19 | Unlink URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20 | Reject Link URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 which defines the
particular information element. Table 4 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.
The remaining octet(s) of an information element contain the
actual data being transmitted. The representation of the data is
Spencer, et al. Expires May 5, 2006 [Page 44]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
dependent on the particular information element as identified by
its "IE" field. Some information elements carry binary data, some
carry ASCII data, and some have no data field at all. 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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| | | |
Spencer, et al. Expires May 5, 2006 [Page 45]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| 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 |
| | | |
| 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 | PROVISIONING | Provisioning info |
| | | |
| 0x1e | AESPROVISIONING | AES Provisioning info |
| | | |
| 0x1f | DATETIME | Date/Time |
| | | |
| 0x20 | DEVICETYPE | Device Type |
| | | |
| 0x21 | SERVICEIDENT | Service Identifier |
| | | |
Spencer, et al. Expires May 5, 2006 [Page 46]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| 0x22 | FIRMWAREVER | Firmware revision |
| | | |
| 0x23 | FWBLOCKDESC | Firmware block description |
| | | |
| 0x24 | FWBLOCKDATA | Firmware block of data |
| | | |
| 0x25 | PROVVER | Provisioning Version |
| | | |
| 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 | 128-bit AES encryption key |
| | | |
| 0x2d | CODEC PREFS | Codec Negotiation |
| | | |
| 0x2e | RR JITTER | Received jitter, as in rfc1889 |
| | | |
| 0x2f | RR LOSS | Received loss, as in rfc1889 |
| | | |
| 0x30 | RR PKTS | Received frames |
| | | |
| 0x31 | RR DELAY | Max playout delay for received frames in |
| | | ms |
| | | |
| 0x32 | RR DROPPED | Dropped frames (presumably by |
| | | jitterbuffer) |
| | | |
| 0x33 | RR OOO | Frames received Out of Order |
+------+-----------------+------------------------------------------+
Table 4: Information Element Definitions
8.6.1. CALLED NUMBER
The purpose of the CALLED NUMBER information element is to indicate
the number or extension being called. It carries ASCII-encoded data.
The CALLED NUMBER information element MUST use ASCII encoding and not
numeric data because it is not limited to E.164 numbers ([E164]),
national numbers, or even numbers. It is possible for a number or
Spencer, et al. Expires May 5, 2006 [Page 47]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
extension to include non-numeric characters. A CALLED NUMBER MAY be
a SIP URI ([RFC3261])
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-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 ASCII-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-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 ASCII-encoded data.
The CALLING ANI information element MAY be sent with an IAX NEW
message, but it is not required.
Spencer, et al. Expires May 5, 2006 [Page 48]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-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 ASCII-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded CALLING NAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.5. CALLED CONTEXT
The purpose of the CALLED CONTEXT information element is to indicate
the context in the remote peer's dialplan the call is trying to
reach. It carries ASCII-encoded data.
The CALLED CONTEXT information element MAY be sent with IAX NEW or
TRANSFER messages, though it is not required.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded CALLED CONTEXT :
| |
Spencer, et al. Expires May 5, 2006 [Page 49]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ASCII-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded USERNAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.7. PASSWORD
The purpose of the PASSWORD information element is to indicate the
plaintext password to authenticate a specified user. It carries
ASCII-encoded data.
The PASSWORD information element MAY be sent with IAX AUTHREP or
REGREQ messages. It is generally only used when the AUTH METHODS
information element has been received and specifies plaintext as the
only authentication method.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded PASSWORD :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 50]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.8. 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 four 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.
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.9. 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 four
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.10. 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 ASCII-encoded data.
The LANGUAGE information element MAY be sent with an IAX NEW message.
Spencer, et al. Expires May 5, 2006 [Page 51]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0a | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded LANGUAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.11. 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.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0b | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.12. ADSICPE
The purpose of the ADSICPE information element is to indicate the CPE
ADSI 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 52]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.13. DNID
The purpose of the DNID information element is to indicate the Dialed
Number ID, which may differ from the 'called number'. It carries
ASCII-encoded data.
The DNID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded DNID Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.14. AUTHMETHODS
The purpose of the AUTHMETHODS information element is to indicate the
authentication methods a peer accepts. It is sent as a bitmask 2
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 53]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
The following table lists valid values for authentication:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| METHOD | DESCRIPTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | Plaintext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | MD5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | RSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.15. 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 ASCII-encoded challenge data.
The CHALLENGE information element MUST be sent with IAX AUTHREQ and
REGAUTH messages if either MD5 or RSA authentication is specified.
If the CHALLENGE information element is not received, plaintext
authentication is the only authentication that MAY take place for the
call, even if the AUTHMETHODS IE specifies MD5 or RSA authentication
is accepted.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0f | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded Challenge Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.16. MD5 RESULT
The purpose of the MD5 RESULT information element is to offer an MD5
response to an authentication CHALLENGE. It carries the actual
ASCII-encoded challenge result.
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.
Spencer, et al. Expires May 5, 2006 [Page 54]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded MD5 Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.17. RSA RESULT
The purpose of the RSA RESULT information element is to offer an RSA
response to an authentication CHALLENGE. It carries the actual
ASCII-encoded challenge result.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded RSA Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.18. 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 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 the local peer is trying to
transfer its end of the connection to. 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
Spencer, et al. Expires May 5, 2006 [Page 55]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 /*fixme*/: 2 octets for the address
family /*fixme - in practice family is in 1st octet, next octet is
00*/, 2 octets for the port number, 4 octets for the IPv4 address
/*fixme*/, 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:
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 (4569)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IP address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 8 octets of all 0s |
| (padding in sockaddr_in) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 56]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.19. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.20. 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
two octet bitmask specifying flags from the table below. Exactly one
of the low 3 bits MUST be set, and zero, one, or two of the high two
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 57]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.21. 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.
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.22. 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 ASCII-encoded data. Notification of the event itself is
handled at the message level.
Spencer, et al. Expires May 5, 2006 [Page 58]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded CAUSE of event :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.23. IAX UNKNOWN
The purpose of the IAX UNKNOWN information element is to indicate
that a received IAX command was unknown or unrecognized. The one
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.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x17 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec'd Subclass|
+-+-+-+-+-+-+-+-+
8.6.24. 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.
Spencer, et al. Expires May 5, 2006 [Page 59]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.25. AUTOANSWER
The purpose of the AUTOANSWER information element is to request that
a call be auto-answered upon receipt of a NEW message which 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.26. 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
ASCII-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.
Spencer, et al. Expires May 5, 2006 [Page 60]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.27. TRANSFERID
The purpose of the TRANSFERID information element is to identify a
transfer across all 3 peers participating in a transfer event. It
carries a number, 4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.28. RDNIS
The purpose of the RDNIS information element is to indicate the
referring DNIS. It carries ASCII-encoded data.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1c | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded RDNIS :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 61]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.29. PROVISIONING
The purpose of the PROVISIONING information element is to carry
provisioning data. It carries binary data used to provision an IAX
device. The coding scheme of the data included in the PROVISIONING
IE is unspecified by the protocol, and is left to the implementor.
The PROVISIONING information element may only be sent with an IAX
PROVISION message.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Raw provisioning data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.30. AESPROVISIONING
The purpose of the AESPROVISIONING information element is to carry
AES-encrypted provisioning data. It carries encrypted data used to
provision an IAX device. The coding scheme of the data included in
the AESPROVISIONING IE is unspecified by the protocol, as is left to
the implementor.
The AESPROVISIONING information element may only be sent with an IAX
PROVISION message.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1e | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: AES provisioning data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.31. DATETIME
The DATETIME information element indicates the time a message is
sent. This differs from the header timestamp because that timestamp
begins at 0 for each call, while the DATETIME is a call-independent
Spencer, et al. Expires May 5, 2006 [Page 62]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 five least significant bits are seconds, the next six
least significant bits are minutes, the next least significant five
bits are hours, the next least significant five bits are the day of
the month, the next least significant four bits are the month, and
the most significant seven 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 is undefined but UTC
is recommended.
The DATETIME information element SHOULD be sent with IAX NEW and
REGACK messages. However, it is strictly informational, so it is
never required.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.32. DEVICETYPE
The purpose of the DEVICETYPE information element is to indicate the
type of device requesting registration or firmware downloading. It
carries ASCII-encoded data describing the type of device of the IAX
peer.
The DEVICETYPE information element MUST be sent with IAX FWDOWNL
messages in order to help identify which firmware image is
appropriate for the peer. It MAY be sent with IAX REGREQ messages,
as well.
If the initial FWDOWNL message of a call does not include the
DEVICETYPE information element, the firmware download fails and a
REJECT MUST be sent. If at least one FWDOWNL has been sent with a
valid DEVICETYPE information element, subsequent FWDOWNL messages are
not required to include it.
Spencer, et al. Expires May 5, 2006 [Page 63]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ASCII-encoded device type :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.33. SERVICEIDENT
The SERVICEIDENT information element uniquely identifies a device
requesting provisioning so that appropriate data may be made
available. The data field carries some guaranteed unique device
identifier, e.g. the six octet hardware MAC address of the device.
The SERVICEIDENT information element MAY be sent with IAX REGREQ
messages so that an IAX device may be provisioned appropriately. It
is never required.
If the SERVICEIDENT information element is absent, a 'default'
template may be used to provision the device.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x21 | 0x06 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique identifier |
: (e.g. peer's MAC) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.34. FIRMWAREVER
The purpose of the FIRMWAREVER information element is to indicate the
version of firmware an IAX device has. The data field is 2 octets
long and specifies a firmware version the server has available for
download for the received DEVICETYPE. The meaning of this value
depends on the DEVICETYPE of the device.
The FIRMWAREVER information element may be sent with IAX REGACK
messages.
Spencer, et al. Expires May 5, 2006 [Page 64]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x22 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.35. FWBLOCKDESC
The purpose of the FWBLOCKDESC information element is to identify a
block of firmware. Sent with an FWDOWNL it is a request for the
specified block of firmware. Sent with an FWDATA it is a declaration
of the block of firmware included in the FWBLOCKDATA IE. The data
field is 4 octets long and carries binary data.
The FWBLOCKDESC information element is sent with IAX FWDOWNL and
FWDATA messages. It can be used to acknowledge the amount of data
transmitted or received.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x23 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Block |
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.36. FWBLOCKDATA
The purpose of the FWBLOCKDATA information element is to carry a
block of a firmware image from a server to an IAX device. The data
field carries raw binary data.
The FWBLOCKDATA information element is sent with IAX FWDATA messages.
Once the firmware image is completely transmitted and acknowledged
(via the FWBLOCKDESC information element), a FWDATA message
containing a FWBLOCKDATA information element with no data MUST be
sent to indicate that the image has been completely transmitted.
Spencer, et al. Expires May 5, 2006 [Page 65]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x24 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Binary Block of Firmware Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.37. PROVVER
The purpose of the PROVVER information element is to indicate the
provisioning version. The data field is 4 octets long and contains
the version of the provisioning software used.
The PROVVER information element MAY be sent with IAX REGREQ messages.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x25 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Provisioning Version |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.38. 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 MAY 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. |
+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 66]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.39. 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 MAY 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 |
+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 67]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.40. 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
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 ASCII-encoded data.
The CALLINGTNS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x28 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TON | Plan | ASCII Net ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following tables list the valid values for the data field of the
'calling tns' IE.
Spencer, et al. Expires May 5, 2006 [Page 68]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Q.931 Network Identification Plan Values:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITS | DESCRIPTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0000 | Unknown |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0001 | Caller Identification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0011 | Data Network Identification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q.931 Type of Network Values:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITS | DESCRIPTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 000 | User Specified |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 010 | National Network Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 011 | International Network Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.41. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 69]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.42. 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 |
+-+-+-+-+-+-+-+-+
+--------+----------------------------------------------------------+
| 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 |
| | |
Spencer, et al. Expires May 5, 2006 [Page 70]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| 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 | Pre-empted (causes.h only) |
| | |
| 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) |
Spencer, et al. Expires May 5, 2006 [Page 71]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| 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 |
| | |
| 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 |
+--------+----------------------------------------------------------+
8.6.43. 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.
Spencer, et al. Expires May 5, 2006 [Page 72]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.44. ENCKEY
The purpose of the ENCKEY information element is to share an
encryption key with a remote peer in an already-encrypted exchange.
This makes the process of rotating encryption keys simple to
implement. Note that an ENCKEY may only be sent between peers that
are already exchanging encrypted data.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2c | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ENCKEY Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.45. 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 ASCII-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.
Spencer, et al. Expires May 5, 2006 [Page 73]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
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.46. RR JITTER
The purpose of the RR JITTER information element is to indicate the
received jitter on a call, per rfc1889[RFC1889]. 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.47. RR LOSS
The purpose of the RR LOSS information element is to indicate the
number of lost frames on a call, per rfc1889[RFC1889]. 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Spencer, et al. Expires May 5, 2006 [Page 74]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.6.48. RR PKTS
The purpose of the RR PKTS information element is to indicate the
total number of frames received on a call, per rfc1889[RFC1889]. 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.49. RR DELAY
The purpose of the RR DELAY information element is to indicate the
maximum playout delay for a call, per rfc1889[RFC1889]. 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.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x31 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Playout Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.50. RR DROPPED
The purpose of the RR DROPPED information element is to indicate the
total number of dropped frames for a call, per rfc1889[RFC1889]. 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.
Spencer, et al. Expires May 5, 2006 [Page 75]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x32 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Frames Dropped |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.6.51. 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
rfc1889[RFC1889]. 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. Expires May 5, 2006 [Page 76]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
8.7. Media Formats
Media Format Subclass 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 | |
+------------+------------------+----------------------------------+
| 0x00000080 | LPC10 | Variable size frame of 172 |
| | | samples |
+------------+------------------+----------------------------------+
| 0x00000100 | G.729 | 20 bytes chunks of 172 samples |
+------------+------------------+----------------------------------+
| 0x00000200 | Speex | Variable |
+------------+------------------+----------------------------------+
| 0x00000400 | ILBC | 50 bytes per 240 samples |
+------------+------------------+----------------------------------+
| 0x00010000 | JPEG | |
+------------+------------------+----------------------------------+
| 0x00020000 | PNG | |
+------------+------------------+----------------------------------+
| 0x00040000 | H.261 | |
+------------+------------------+----------------------------------+
| 0x00080000 | H.263 | |
+------------+------------------+----------------------------------+
| 0x00100000 | H.263p | |
+------------+------------------+----------------------------------+
Spencer, et al. Expires May 5, 2006 [Page 77]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
9. Example Calls
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 timestamp
| | as received PING.
| | ===ACK=============================> |Has same timestamp
| | | as received PONG
\ / |________________________________________| and original PING
9.2. Lagrq/Lagrp
LAGRQ->LAGRP
Peer A Peer B
________________________________________
| |
T | |
i | ===LAGRQ===========================> |
m | |
e | <===========================LAGRP=== |Same timestamp as
| | received LAGRQ.
| | ===ACK=============================> |Same timestamp as
| | | received LAGRP and
\ / |________________________________________| original LAGRQ.
Spencer, et al. Expires May 5, 2006 [Page 78]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
9.3. Registration
Registration of an IAX Peer
Peer A Peer B
________________________________________
| |
T | ===REGREQ==========================> |
i | |
m | <=========================REGAUTH=== |
e | |
| ===REGREQ==========================> |
| | |
| | <==========================REGACK=== |
\ | / | |
\|/ | ===ACK=============================> |
| |
|________________________________________|
9.4. Provisioning
Provisioning an IAX Device
Peer A (Provisioning server) Peer B (IAX Device)
________________________________________
| |
T | |
i | ===PROVISION=======================> |Carries
m | | PROVISIONING IE
e | <==========================ACCEPT=== |
| |
| | ===ACK=============================> |
| | |
\ / |________________________________________|
Spencer, et al. Expires May 5, 2006 [Page 79]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
9.5. Firmware Download
IAX Firmware Download
Peer A (IAX Device) Peer B (FW manager)
________________________________________
| |
T | |
| ===FWDOWNL=========================> |IE spec Device Type
i | . | and firmware block
| . | desired.
m | . |
| <==========================FWDATA=== |IEs spec firmware
e | . | block identifier
| . | and data block
| . |
| | ===FWDOWNL=========================> |FWDOWNL/FWDATA
| . | messages pass back
| . | forth until all
| . | firmware xmitted.
| . |
| | <==========================FWDATA=== |The last FWDATA
| . | contains 0 length
| . | FWBLOCKDATA IE
| . |
\ / | ==============================ACK==> |The last FWDATA
| | MUST be ACKed.
|________________________________________|
Spencer, et al. Expires May 5, 2006 [Page 80]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
9.6. 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.7. 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)=== |
Spencer, et al. Expires May 5, 2006 [Page 81]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| | ====ACK===========================> |
| | |
| | <---------Voice miniframe (ring)--- |
| | <---------Voice miniframe (ring)--- |
| | |
\ | / | <=========================RINGING=== |
\|/ | ====ACK============================> |
| |
| <---------Voice miniframe (ring)--- |
| <---------Voice miniframe (ring)--- |
| |
| <==========================ANSWER=== |
| ====ACK============================> |
| |
| ====Voice (full frame)=============> |
| <=============================ACK=== |
| |
| |
| <-----------Voice miniframes-------> | exchange occurs
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice miniframes-------> |
| |
| |
| ====Voice (full frame)=============> | (note 1)
| <===ACK============================= | (note 2)
| | (every 65536 ms).
| <=============Voice (full frame)==== | (note 3)
| ====ACK============================> |
| |
| |
| <-----------Voice miniframes-------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice miniframes-------> |
| |
| |
| ====HANGUP=========================> | Either can hangup
| <=============================ACK=== |
|________________________________________|
Note 1: Mini Frames carry the low 16 bits of the peer's
32-bit timestamp.
Note 2: Full frames re-sync the 32 bit timestamp when the 16 bit
timestamp overflows.
Spencer, et al. Expires May 5, 2006 [Page 82]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Note 3:Each side has its own 32 bit timestamp so each side needs
to sync at 16 bit overflow.
9.8. 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 which 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 miniframes-------> | Media exchange
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice miniframes-------> |
| |
| |
| ====Voice (full frame)=============> | (note 2)
| <===ACK============================= | (note 3)
| | (every 65536 ms).
| <=============Voice (full frame)==== | (Note 4)
| ====ACK============================> |
Spencer, et al. Expires May 5, 2006 [Page 83]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
| |
| |
| <-----------Voice miniframes-------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice miniframes-------> |
| |
| |
| ====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 timestamp.
Note 3: Full frames re-sync the 32 bit timestamp when the 16 bit
timestamp overflows
Note 4: Each side has its own 32 bit timestamp so each side needs
to sync at 16 bit overflow.
Spencer, et al. Expires May 5, 2006 [Page 84]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
10. Security Considerations
IAX is a binary protocol for setting up point to point call legs
which includes both media and signaling. As Such, it is simpler to
secure than other more general purpose VoIP protocols, however,
security remains a difficult task.
IAX registration is one area that requires attention. While clear
text passwords are supported, they should not be used. The MD5 and
RSA alternatives offer much higher security. Although not specified
by IAX, some implementations limit the number of registrants per
account to one. And 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.
Denial of service 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, using IPSEC, [RFC2401], would address many of these
potential issues.
Spencer, et al. Expires May 5, 2006 [Page 85]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
11. IANA Considerations
This document requests registration of the "iax2" URI Scheme. See
section Section 5. IAX2 also requires a well-known UDP port to be
assigned. The current port in use is 4569.
Spencer, et al. Expires May 5, 2006 [Page 86]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
12. Acknowledgements
This work was supported by Internet Foundation Austria.
13. References
[E164] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, May 1997.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833,
May 2000.
[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.
Spencer, et al. Expires May 5, 2006 [Page 87]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Authors' Addresses
Mark A. Spencer
Digium, Inc.
150 West Park Loop Suite 100
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
E-MC Software
235 Main Street, STE 253
Madison, NJ 07940
US
Phone: +1 973 437 4519
Email: edguy@emcsw.com
URI: http://www.emcsw.com/
Frank Miller
Cornfed Systems, Inc.
103 Overhill Road
Baltimore, MD 21210
US
Phone: +1 410 404-8790
Email: fwmiller@cornfed.com
URI: http://www.digium.com/
Spencer, et al. Expires May 5, 2006 [Page 88]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Kenneth C. Shumard
3818 N Lakegrove Way
Boise, ID 83713
US
Phone: +1 208 724 7801
Email: kshumard@gmail.com
Spencer, et al. Expires May 5, 2006 [Page 89]
Internet-Draft IAX: Inter-Asterisk eXchange Version 2 November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Spencer, et al. Expires May 5, 2006 [Page 90]