Independent Submission M. Spencer
Request for Comments: 5456 Digium, Inc.
Category: Informational B. Capouch
ISSN: 2070-1721 Saint Joseph's College
E. Guy, Ed.
Truphone
F. Miller
Cornfed Systems, LLC
K. Shumard
February 2010
Independent Submission M. Spencer
Request for Comments: 5456 Digium, Inc.
Category: Informational B. Capouch
ISSN: 2070-1721 Saint Joseph's College
E. Guy, Ed.
Truphone
F. Miller
Cornfed Systems, LLC
K. Shumard
February 2010
IAX: Inter-Asterisk eXchange Version 2
IAX:Inter-Asterisk eXchange版本2
Abstract
摘要
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.
本文档介绍IAX，即Inter Asterisk eXchange协议，它是一种应用层控制和媒体协议，用于通过Internet协议（IP）网络创建、修改和终止多媒体会话。IAX是由开放源码社区为Asterisk Private Branch Exchange（PBX）开发的，主要针对互联网协议语音（VoIP）呼叫控制，但它可以用于流式视频或任何其他类型的多媒体。
IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services.
IAX是一种“一体化”协议，用于在IP网络中处理多媒体。它在同一协议中结合了控制和媒体服务。此外，IAX在静态端口上使用单个UDP数据流，大大简化了网络地址转换（NAT）网关的遍历，消除了其他协议围绕NAT工作的需要，并简化了网络和防火墙管理。IAX采用了一种紧凑的编码，可以减少带宽使用，非常适合于Internet电话服务。此外，其开放性允许添加新的有效负载类型，以支持额外的服务。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5456.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5456.
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
The IESG thinks that this work is related to IETF work done in SIP, MMUSIC, and AVT WGs, but this does not prevent publishing.
IESG认为这项工作与在SIP、MMUSIC和AVT WGs中完成的IETF工作有关，但这并不妨碍发布。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Basic Properties ...........................................4
1.2. Drawbacks ..................................................5
2. IAX Terminology .................................................6
3. Overview of IAX Protocol ........................................6
4. Naming Conventions ..............................................8
5. IAX Uniform Resource Identifiers ................................8
5.1. IAX URI Scheme Registration ................................8
5.2. URI Comparison ............................................11
6. Peer Behavior and Related Messages .............................11
6.1. Registration (OPTIONAL) ...................................12
6.2. Call Leg Management .......................................18
6.3. Call Control ..............................................24
6.4. Mid-Call Link Operations ..................................26
6.5. Call Path Optimization ....................................28
6.6. Call Tear Down ............................................33
6.7. Network Monitoring ........................................33
6.8. Digit Dialing .............................................34
6.9. Miscellaneous .............................................36
6.10. Media Messages ...........................................38
7. Message Transport ..............................................39
7.1. Trunking ..................................................40
7.2. Timers ....................................................41
7.3. NAT Considerations ........................................41
7.4. Encryption ................................................42
8. Message Encoding ...............................................42
8.1. Frame Structure ...........................................42
8.2. Frame Types ...............................................52
8.3. Control Frames Subclasses .................................55
8.4. IAX Frames ................................................56
8.5. HTML Command Subclasses ...................................58
8.6. Information Elements ......................................58
8.7. Media Formats .............................................86
9. Example Message Flows ..........................................87
9.1. Ping/Pong .................................................88
9.2. Lagrq/Lagrp ...............................................88
9.3. Registration ..............................................89
9.4. Registration Release ......................................89
9.5. Call Path Optimization ....................................90
9.6. IAX Media Call ............................................91
9.7. IAX Media Call via an IAX Device ..........................93
10. Security Considerations .......................................94
11. IANA Considerations ...........................................96
12. Implementation Notes ..........................................96
13. Acknowledgments ...............................................97
1. Introduction ....................................................4
1.1. Basic Properties ...........................................4
1.2. Drawbacks ..................................................5
2. IAX Terminology .................................................6
3. Overview of IAX Protocol ........................................6
4. Naming Conventions ..............................................8
5. IAX Uniform Resource Identifiers ................................8
5.1. IAX URI Scheme Registration ................................8
5.2. URI Comparison ............................................11
6. Peer Behavior and Related Messages .............................11
6.1. Registration (OPTIONAL) ...................................12
6.2. Call Leg Management .......................................18
6.3. Call Control ..............................................24
6.4. Mid-Call Link Operations ..................................26
6.5. Call Path Optimization ....................................28
6.6. Call Tear Down ............................................33
6.7. Network Monitoring ........................................33
6.8. Digit Dialing .............................................34
6.9. Miscellaneous .............................................36
6.10. Media Messages ...........................................38
7. Message Transport ..............................................39
7.1. Trunking ..................................................40
7.2. Timers ....................................................41
7.3. NAT Considerations ........................................41
7.4. Encryption ................................................42
8. Message Encoding ...............................................42
8.1. Frame Structure ...........................................42
8.2. Frame Types ...............................................52
8.3. Control Frames Subclasses .................................55
8.4. IAX Frames ................................................56
8.5. HTML Command Subclasses ...................................58
8.6. Information Elements ......................................58
8.7. Media Formats .............................................86
9. Example Message Flows ..........................................87
9.1. Ping/Pong .................................................88
9.2. Lagrq/Lagrp ...............................................88
9.3. Registration ..............................................89
9.4. Registration Release ......................................89
9.5. Call Path Optimization ....................................90
9.6. IAX Media Call ............................................91
9.7. IAX Media Call via an IAX Device ..........................93
10. Security Considerations .......................................94
11. IANA Considerations ...........................................96
12. Implementation Notes ..........................................96
13. Acknowledgments ...............................................97
14. References ....................................................97
14.1. Normative References .....................................97
14.2. Informative References ...................................99
14. References ....................................................97
14.1. Normative References .....................................97
14.2. Informative References ...................................99
Numerous protocols have been specified by the Internet community to support control or signaling of multimedia sessions, for instance, SIP [RFC3261], Media Gateway Control Protocol (MGCP) [RFC3435], and MEGACO/H.248 [RFC3525] (which has been obsoleted and made historic by [RFC5125]). In general, these protocols are designed to offer full support for many types of media transmission. This flexible approach adds some overhead to the protocol headers, but allows for the protocol use well beyond the current application. Typically, these protocols reference, but do not specify, the media transmission protocol used to carry the actual stream. SIP commonly uses Session Description Protocol (SDP) [RFC4566] to specify Real-Time Transport Protocol (RTP) [RFC3550] streams. This method allows for great flexibility, but again leads to more overhead. Furthermore, multimedia solutions that use different, perhaps dynamic, network addresses for signaling and media transmission frequently suffer from Network Address Translation (NAT) traversal and security challenges.
互联网社区已经指定了许多协议来支持多媒体会话的控制或信令，例如，SIP[RFC3261]、媒体网关控制协议（MGCP）[RFC3435]和MEGACO/H.248[RFC3525]（已被[RFC5125]淘汰并成为历史）。通常，这些协议旨在为多种类型的媒体传输提供全面支持。这种灵活的方法为协议头增加了一些开销，但允许在当前应用程序之外使用协议。通常，这些协议参考但不指定用于承载实际流的媒体传输协议。SIP通常使用会话描述协议（SDP）[RFC4566]来指定实时传输协议（RTP）[RFC3550]流。这种方法允许很大的灵活性，但同样会导致更多的开销。此外，使用不同的（可能是动态的）网络地址进行信令和媒体传输的多媒体解决方案经常面临网络地址转换（NAT）遍历和安全挑战。
IAX is the Inter-Asterisk eXchange protocol, which facilitates VoIP connections between servers, and between servers and clients that also use the IAX protocol. IAX was created through an open source methodology rather than through a traditional, standards-based methodology. It is an open protocol originally used by Asterisk, a dual-licensed open source and commercial PBX server from Digium. Independent IAX implementations may be open, proprietary, or licensed in anyway the author seems fit without royalty to the protocol creators.
IAX是Inter Asterisk eXchange协议，它促进了服务器之间以及也使用IAX协议的服务器和客户端之间的VoIP连接。IAX是通过开源方法而不是传统的基于标准的方法创建的。它是一个开放协议，最初由Asterisk使用，Asterisk是Digium的一个双许可开源和商用PBX服务器。独立的IAX实现可能是开放的、专有的或许可的，但作者似乎不需要协议创建者的特许权。
IAX is a robust and full-featured, yet, simple protocol. It is general enough that it can handle most common types of media streams. However, the protocol is highly optimized for VoIP calls where low-overhead and low-bandwidth consumption are priorities. This pragmatic aspect makes IAX more efficient for VoIP than protocols that consider possibilities far beyond current needs and specify many more details than are strictly necessary to describe or transport a point-to-point call. Furthermore, because IAX is designed to be lightweight and VoIP-friendly, it consumes less bandwidth than more general approaches. IAX is a binary protocol, designed to reduce overhead, especially in regards to voice streams. Bandwidth efficiency, in some places, is sacrificed in exchange for bandwidth efficiency for individual voice calls. For example, when
IAX是一个健壮、功能齐全但简单的协议。它足够通用，可以处理最常见类型的媒体流。但是，该协议针对优先考虑低开销和低带宽消耗的VoIP呼叫进行了高度优化。这种实用性使得IAX比VoIP更有效，它考虑了远远超出当前需求的可能性，并且指定了比严格描述或传输点对点呼叫所必需的更多细节。此外，由于IAX被设计为轻量级且对VoIP友好，因此它比更通用的方法消耗更少的带宽。IAX是一种二进制协议，旨在减少开销，特别是在语音流方面。在某些地方，带宽效率被牺牲，以换取单个语音呼叫的带宽效率。例如，当
transmitting a voice stream compressed to 8 kbit/s with a 20 ms packetization, each data packet consists of 20 bytes. IAX adds 20% overhead, 4 bytes, on the majority of voice packets while RTP adds 60% overhead with 12 additional bytes per voice packet.
通过20ms的分组传输压缩到8kbit/s的语音流，每个数据包由20个字节组成。IAX在大多数语音数据包上增加了20%的开销，即4个字节，而RTP在每个语音数据包上增加了60%的开销，增加了12个字节。
In addition to efficiency, IAX's single static UDP port approach makes IAX traffic easy for network managers to shape, prioritize, and pass through firewalls. IAX's basic structure is that it multiplexes signaling and multiple media streams over a single UDP stream between two computers. IAX also uses the same UDP port for both its signaling and media messages, and because all communications regarding a call are done over a the same point-to-point path, NAT traversal is much simpler for IAX than for other commonly deployed protocols.
除了提高效率之外，IAX的单静态UDP端口方法使IAX流量易于网络管理器形成、优先排序和通过防火墙。IAX的基本结构是在两台计算机之间通过单个UDP流多路传输信令和多个媒体流。IAX还为其信令和媒体消息使用相同的UDP端口，并且由于与呼叫有关的所有通信都是通过相同的点到点路径完成的，因此IAX的NAT遍历比其他常用部署的协议简单得多。
While IAX is very effective, addressing many of today's communications needs, it does have a few limitations. For instance, IAX uses a point-to-point codec negotiation mechanism that limits extensibility because every IAX node in a call path must support every used codec to some degree. In addition, the codec definition is controlled by an internally defined 32-bit mask, so the codecs must be defined in the protocol, and the maximum number of simultaneous codecs is, therefore, limited.
虽然IAX非常有效，可以满足当今许多通信需求，但它确实存在一些局限性。例如，IAX使用一种限制扩展性的点对点编解码器协商机制，因为调用路径中的每个IAX节点都必须在一定程度上支持所使用的每个编解码器。此外，编解码器定义由内部定义的32位掩码控制，因此必须在协议中定义编解码器，因此，同时编解码器的最大数量是有限的。
One of IAX's design strengths also presents a potential problem. The use of a single, well-known, port makes the protocol an easier target for denial-of-service attacks. Real-time systems like VoIP are particularly sensitive to these attacks.
IAX的设计优势之一也存在潜在问题。使用单个众所周知的端口使协议更容易成为拒绝服务攻击的目标。像VoIP这样的实时系统对这些攻击特别敏感。
The protocol is typically deployed with all signaling and media going to a centralized server. While this combined path approach provides a great deal of control, it limits the overall system scalability. IAX now provides the ability to split the media from the signaling stream, which overcomes this limitation of earlier IAX versions.
该协议通常部署在所有信令和媒体都流向集中服务器的情况下。虽然这种组合路径方法提供了大量的控制，但它限制了整个系统的可伸缩性。IAX现在提供了从信令流中分离媒体的能力，这克服了早期IAX版本的这一限制。
Most IAX drawbacks are due to implementation issues rather than protocol issues. Threading presents a series of problems. Many implementations have a limited number of threads available to process IAX traffic and can become overwhelmed by high use or denial-of-service attacks. Newer implementations have additional controls to minimize the impact of these challenges.
大多数IAX的缺点是由于实现问题而不是协议问题。线程化带来了一系列问题。许多实现只有有限数量的线程可用于处理IAX流量，并且可能会被高使用率或拒绝服务攻击所淹没。较新的实现有额外的控制，以尽量减少这些挑战的影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Additionally, this document uses the following terminology:
此外，本文件使用以下术语：
Peer: A host or device that implements the IAX protocol.
对等机：实现IAX协议的主机或设备。
Call: A call is a relationship between two or more parties (i.e., resources such as devices, user agents, or programs) that exists for some time for the purpose of exchanging real-time media. In the context of this document, a call is an end-to-end relationship where at least the one leg of call path is implemented using the IAX protocol.
呼叫：呼叫是两方或多方（即设备、用户代理或程序等资源）之间存在一段时间以交换实时媒体的关系。在本文档的上下文中，调用是一种端到端关系，其中至少有一段调用路径是使用IAX协议实现的。
Calling Party: A device or program that initiates a call.
呼叫方：发起呼叫的设备或程序。
Called Party: A device or program to which a call is directed.
被叫方：呼叫所指向的设备或程序。
Context: A context is a named partition of a Dialplan.
上下文：上下文是拨号计划的命名分区。
Dialplan: A Dialplan is a set of rules for associating provided names and numbers with a particular called party.
拨号计划：拨号计划是一组规则，用于将提供的姓名和号码与特定被叫方关联。
Frame: The atomic communication unit between two IAX peers. All IAX messages are carried within frames.
帧：两个IAX对等点之间的原子通信单元。所有IAX消息都在帧内传输。
Information Element (IE): A discrete data unit appended to an IAX frame that specifies user- or call-specific data.
信息元素（IE）：附加到IAX帧的离散数据单元，用于指定用户或呼叫特定数据。
Registrant: A registrant is a peer that makes REGISTER requests in order to advertise the address of a resource, i.e., a device or program to which a call may be directed.
注册人：注册人是指发出注册请求以公布资源地址的对等方，即呼叫可能指向的设备或程序。
Registrar: A registrar is a peer that processes REGISTER requests and places the information it receives in those requests into the location service. [RFC3261].
注册者：注册者是处理注册请求并将其在这些请求中收到的信息放入位置服务的对等方。[RFC3261]。
IAX is a peer-to-peer, VoIP-oriented protocol. IAX includes both control and media functions. It can register locations, create, modify, terminate multimedia sessions, and carry the actual media streams specified by the sessions it manages. The protocol is designed and optimized for describing and transporting multimedia
IAX是一种面向VoIP的对等协议。IAX包括控制和媒体功能。它可以注册位置、创建、修改、终止多媒体会话，并携带由其管理的会话指定的实际媒体流。该协议是为描述和传输多媒体而设计和优化的
calls using Internet Protocol. This document describes Version 2 of IAX; Version 1, although somewhat similar in design, utilized a different port and was not widely deployed.
使用互联网协议的呼叫。本文件描述了IAX的第2版；版本1虽然在设计上有些相似，但使用了不同的端口，并且没有得到广泛部署。
The basic design approach for IAX multiplexes signaling and multiple media streams over a single UDP association between two hosts. This is accomplished by using the same "well-known" UDP port, 4569, for all types of IAX traffic. IAX's unified signaling and media paths achieve NAT transparency, which is an advantage of IAX over alternative media transport protocols such as SIP [RFC3261].
IAX的基本设计方法是在两台主机之间通过单个UDP关联多路传输信令和多个媒体流。这是通过为所有类型的IAX通信使用相同的“知名”UDP端口4569来实现的。IAX的统一信令和媒体路径实现了NAT透明性，这是IAX优于SIP[RFC3261]等替代媒体传输协议的优势。
IAX is coded as a binary protocol. One major benefit of using a binary protocol is bandwidth efficiency because the quality of voice calls is frequently related to the amount of bandwidth consumed. This is one way the protocol is specifically optimized to make efficient use of bandwidth for individual voice calls. The bandwidth efficiency for other stream types is sacrificed for the sake of individual voice calls. Other benefits of a binary protocol are robustness against buffer-overrun attacks, and compact implementation capability, which reduces interoperability issues related to parsing.
IAX编码为二进制协议。使用二进制协议的一个主要好处是带宽效率，因为语音呼叫的质量通常与所消耗的带宽量有关。这是对协议进行专门优化的一种方法，可以有效地利用带宽进行单独的语音呼叫。其他流类型的带宽效率是为了单个语音呼叫而牺牲的。二进制协议的其他好处是对缓冲区溢出攻击的鲁棒性，以及紧凑的实现能力，这减少了与解析相关的互操作性问题。
The atomic communication unit in IAX is the "Frame". There are multiple classes of Frames, each of which is described below. In general, "Full Frames" carry signaling/control data, while "Mini Frames" carry media stream data. Full Frames enclose optional 'Information Elements' (IEs). IEs describe various types of user- or call-specific data. "Meta Frames" are used for call trunking or video stream transmission.
IAX中的原子通信单元是“帧”。有多个帧类别，每个类别如下所述。通常，“全帧”承载信令/控制数据，“小帧”承载媒体流数据。完整框架包含可选的“信息元素”（IE）。IEs描述各种类型的用户或呼叫特定数据。“元帧”用于呼叫中继或视频流传输。
An IAX-based call may consist of many call legs, or segments. Each call leg may be implemented using different protocols, e.g., SIP to IAX to ISDN (Integrated Services Digital Network). IAX is responsible for setting up one or more legs of a complete call path, not necessarily the end-to-end call.
基于IAX的呼叫可能由许多呼叫分支或段组成。每个呼叫分支可以使用不同的协议来实现，例如，SIP到IAX到ISDN（综合业务数字网络）。IAX负责设置完整呼叫路径的一个或多个分支，不一定是端到端呼叫。
IAX is an optimized peer-to-peer protocol. If two adjacent call legs utilize the IAX protocol and if the intermediate peer determines that it does not need to remain in the call path, it can supervise a calling path change such that it removes itself from the path. This supervision is complete, a call path is not changed until all peers in the optimized call path confirm they can properly communicate.
IAX是一种优化的对等协议。如果两个相邻的呼叫分支使用IAX协议，并且如果中间对等方确定它不需要保留在呼叫路径中，则它可以监视呼叫路径的更改，从而将自己从路径中移除。此监控完成后，在优化呼叫路径中的所有对等方确认它们可以正确通信之前，不会更改呼叫路径。
IAX supports security features by allowing multiple methods of user authentication and authorization, as well as allowing multiple security methods for peer registration. IAX also specifies a generic framework for native encryption.
IAX通过允许多种用户身份验证和授权方法以及允许多种对等注册安全方法来支持安全功能。IAX还为本机加密指定了通用框架。
Call Identifier: A call leg is marked with two unique integers, one assigned by each peer involved in creating the call leg.
调用标识符：调用段用两个唯一的整数标记，其中一个由创建调用段的每个对等方分配。
Number: The Calling and Called Numbers are a set of digits and letters identifying a call originator and the desired terminating resource. The term 'Number' is historic and has been expanded to include letters. A peer is responsible for defining its own dialplan. A peer MAY define its dialplan according to ITU-T Recommendation E.164 [E164]. However, this is not required.
号码：主叫号码和被叫号码是一组数字和字母，用于标识呼叫发起人和所需的终止资源。“数字”一词具有历史意义，已扩展到包括字母。对等方负责定义自己的拨号计划。对等方可根据ITU-T建议E.164[E164]定义其拨号计划。然而，这不是必需的。
Username: A username is a string used for identification purposes.
用户名：用户名是用于标识目的的字符串。
This section registers IAX according to the guidelines in [RFC4395].
本节根据[RFC4395]中的指南注册IAX。
URI scheme name:
URI方案名称：
iax.
iax。
Status:
地位：
Permanent.
永久的
URI scheme syntax:
URI方案语法：
The "iax:" scheme follows the guidelines in [RFC3986].
“iax:”方案遵循[RFC3986]中的指南。
The general form is as follows:
一般形式如下：
iax:[username@]host[:port][/number[?context]]
iax:[username@]host[:port][/number[?context]]
where these tokens have the following meanings:
其中，这些标记具有以下含义：
iax: The literal 'iax:'.
iax：文本“iax:”。
username: A string used for identification purposes.
用户名：用于标识目的的字符串。
host: The domain of the resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. An IPv6 address must be enclosed within brackets (i.e., '[2001:db8::1]') as defined in [RFC3986]. Using the fully-qualified domain name form is RECOMMENDED whenever possible.
主机：资源的域。主机部分包含完全限定的域名或数字IPv4或IPv6地址。IPv6地址必须包含在[RFC3986]中定义的括号内（即“[2001:db8:：1]”）。建议尽可能使用完全限定的域名形式。
port: The numeric UDP port number.
端口：数字UDP端口号。
number: The name or number identifying the resource on that host.
编号：标识该主机上资源的名称或编号。
context: The name of the host partition in which the service is identified or processed.
上下文：标识或处理服务的主机分区的名称。
Examples
iax:example.com/alice
iax:example.com:4569/alice
iax:example.com:4570/alice?friends
iax:192.0.2.4:4569/alice?friends
iax:[2001:db8::1]:4569/alice?friends
iax:example.com/12022561414
iax:johnQ@example.com/12022561414
Examples
iax:example.com/alice
iax:example.com:4569/alice
iax:example.com:4570/alice?friends
iax:192.0.2.4:4569/alice?friends
iax:[2001:db8::1]:4569/alice?friends
iax:example.com/12022561414
iax:johnQ@example.com/12022561414
ABNF Formal syntax is defined using ABNF [RFC5234]. Certain values are included by reference from [RFC3986]:
ABNF形式语法是使用ABNF[RFC5234]定义的。参考[RFC3986]中的某些值：
iax-uri = "iax:" [ userinfo "@" ] host [ ":" port ]
[ "/" number [ "?" context ] ]
iax-uri = "iax:" [ userinfo "@" ] host [ ":" port ]
[ "/" number [ "?" context ] ]
userinfo = <as specified in RFC 3986>
userinfo = <as specified in RFC 3986>
host = <as specified in RFC 3986>
host = <as specified in RFC 3986>
port = <as specified in RFC 3986>
port = <as specified in RFC 3986>
number = *(unreserved / sub-delims / pct-encoded )
number = *(unreserved / sub-delims / pct-encoded )
context = *(unreserved / sub-delims / pct-encoded )
context = *(unreserved / sub-delims / pct-encoded )
unreserved = <as specified in RFC 3986>
unreserved = <as specified in RFC 3986>
sub-delims = <as specified in RFC 3986>
sub-delims = <as specified in RFC 3986>
pct-encoded = <as specified in RFC 3986>
pct-encoded = <as specified in RFC 3986>
URI Scheme Semantics:
URI方案语义：
An IAX URI identifies a communications resource capable of communicating using the IAX Version 2 protocol defined in this document. Within this document, we refer to IAX Version 2 protocol URI as IAX. An IAX URI contains enough information to initiate an IAX-based call with that resource.
IAX URI标识能够使用本文档中定义的IAX版本2协议进行通信的通信资源。在本文中，我们将IAX版本2协议URI称为IAX。IAX URI包含足够的信息，可以使用该资源启动基于IAX的调用。
IAX URIs are associated with server resources to which calls may be routed. For instance, an IAX URI may represent an appearance on a phone, a voice-mail box on a messaging service, an interactive program, a Public Switched Telephone Network (PSTN) address or gateway, or any group of the above.
IAX URI与呼叫可能路由到的服务器资源相关联。例如，IAX URI可以表示电话上的外观、消息传送服务上的语音信箱、交互程序、公共交换电话网络（PSTN）地址或网关，或上述任何一组。
The IAX URI scheme translates into a location that may be used by the IAX protocol to establish a new call using the URI scheme components described in the previous section. This new call function is the only defined operation.
IAX URI方案转换为一个位置，IAX协议可以使用该位置使用前面部分中描述的URI方案组件建立新的调用。这个新的调用函数是唯一定义的操作。
Encoding considerations:
编码注意事项：
IAX URI scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
IAX URI方案编码符合[RFC3986]中为URI建立的编码规则。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
The scheme is used by ENUM Dynamic Delegation Discovery System (DDDS) services to specify resources that support the IAX protocol. The IAX protocol provides application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks.
ENUM动态委派发现系统（DDDS）服务使用该方案指定支持IAX协议的资源。IAX协议提供应用层控制和媒体协议，用于在Internet协议（IP）网络上创建、修改和终止多媒体会话。
Interoperability considerations:
互操作性注意事项：
None.
没有一个
Security considerations:
安全考虑：
The IAX URI Scheme does not introduce any new security concerns except that it provides a uniform syntax for describing IAX resources and that, when published, these addresses are subject to various denial-of-service attacks.
IAX URI方案没有引入任何新的安全问题，只是它提供了描述IAX资源的统一语法，并且在发布时，这些地址会受到各种拒绝服务攻击。
Contact:
联系人：
Ed Guy, edguy@emcsw.com, +1.973.437.4519.
艾德·盖伊，edguy@emcsw.com, +1.973.437.4519.
Author/Change controller
作者/变更控制员
Not Applicable.
不适用。
References:
参考资料：
RFC 5456 (this document)
RFC 5456（本文件）
Some operations in this specification require determining whether two IAX URIs are equivalent. IAX URIs are compared for equality according to the following rules:
本规范中的某些操作需要确定两个IAX URI是否等效。根据以下规则比较IAX URI是否相等：
All components of the URI MUST be identical except:
URI的所有组件必须相同，但以下组件除外：
The port, if omitted, is considered to be the same as the default, 4569.
如果省略，则认为端口与默认端口4569相同。
All URI components, except the username field, are case insensitive, and MUST be normalized to lower case as per Section 6.2.2.1 of [RFC3986] before comparison.
除用户名字段外，所有URI组件都不区分大小写，在比较之前，必须按照[RFC3986]第6.2.2.1节的规定将其规范化为小写。
The URIs within each of the following sets are equivalent:
以下每组中的URI是等效的：
iax:atlanta.com/alice
iax:AtLaNtA.com/ALicE
iax:atlanta.com:4569/alice
iax:atlanta.com/alice
iax:AtLaNtA.com/ALicE
iax:atlanta.com:4569/alice
iax:alice@atlanta.com/alice
iax:alice@AtLaNtA.com:4569/ALicE
iax:alice@atlanta.com/alice
iax:alice@AtLaNtA.com:4569/ALicE
The URIs within the following set are not equivalent:
以下集合中的URI不等效：
iax:ALICE@atlanta.com/alice
iax:alice@atlanta.com/alice
iax:ALICE@atlanta.com/alice
iax:alice@atlanta.com/alice
NOTE: A host in domain form and in IP address form are NOT considered identical even if the host name resolves to an address record that matches the given IP address.
注意：即使主机名解析为与给定IP地址匹配的地址记录，域形式和IP地址形式的主机也不被视为相同。
Messages are divided into two categories: reliable and non-guaranteed. The reliable messages are referred to as "Full Frames". In addition to a message type indicator and facilities to ensure reliability, see Section 7, they include the full call identifier. It consists of each of peer's identifiers for the call. Additional attributes, "Information Elements" or "IEs", may be associated with the Full Frame messages.
消息分为两类：可靠消息和非保证消息。可靠消息称为“完整帧”。除了消息类型指示器和确保可靠性的设施（见第7节）外，它们还包括完整的呼叫标识符。它由每个对等方的呼叫标识符组成。附加属性“信息元素”或“ie”可与全帧消息相关联。
The non-guaranteed messages are referred to as "Mini-Frames" and "Meta Frames" and these more compact messages only have the originating peer's call identifier and MUST NOT have any "Information Elements".
非保证消息被称为“迷你帧”和“元帧”，并且这些更紧凑的消息仅具有发起对等方的呼叫标识符，并且不得具有任何“信息元素”。
Peer behavior is presented in several partitions divided by the following functional areas:
对等行为呈现在由以下功能区域划分的几个分区中：
Registration (OPTIONAL)
注册（可选）
Call Link Management
呼叫链路管理
Call Path Optimization (OPTIONAL)
呼叫路径优化（可选）
Mid-Call Behavior
通话中行为
Call Tear Down
拆毁
Network Monitoring
网络监控
Digit Dialing (OPTIONAL)
数字拨号（可选）
Miscellaneous
混杂的
Media Messages
媒体信息
Each of these behavior topics and the messages involved are described in the sections that follow.
这些行为主题中的每一个以及所涉及的消息都将在下面的部分中进行描述。
In order for one IAX peer to be reachable by another IAX peer, the calling peer needs the network address of the receiving peer. This address may be manually provisioned, determined through a shared directory, e.g. an ENUM-like service, [RFC3761] or configured using the IAX protocol. IAX provides a facility for one peer to register its address and credentials with another so that callers can reach the registrant. The IAX registration facility is optional. If implemented, the IAX registration protocol MAY be done in parts, e.g., an analog telephone adapter MAY only implement the registrant portion of the protocol.
为了使一个IAX对等点可以被另一个IAX对等点访问，主叫对等点需要接收对等点的网络地址。该地址可以手动设置，通过共享目录确定，例如类似枚举的服务[RFC3761]，或使用IAX协议进行配置。IAX为一个对等方提供了向另一个对等方注册其地址和凭证的设施，以便呼叫者能够联系到注册者。IAX注册设施是可选的。如果实现，IAX注册协议可以部分实现，例如，模拟电话适配器可以仅实现协议的注册者部分。
IAX allows user authentication via multiple methods. MD5 Message-Digest authentication [RFC1321] uses an MD5 sum arrangement, but still requires that both ends have plaintext access to the secret. (See Section 8.6.15.) Rivest, Shamir, and Adleman's (RSA) algorithm [RFC3447] allows unidirectional secret knowledge through public/ private key pairs. IAX Private keys SHOULD always be Triple Data Encryption Standard (3DES) encrypted [RFC1851]. (See Section 8.6.16.)
IAX允许通过多种方法进行用户身份验证。MD5消息摘要身份验证[RFC1321]使用MD5和安排，但仍然要求两端都有对秘密的明文访问。（参见第8.6.15节。）Rivest、Shamir和Adleman（RSA）算法[RFC3447]允许通过公钥/私钥对进行单向保密。IAX私钥应始终采用三重数据加密标准（3DES）加密[RFC1851]。（见第8.6.16节。）
________________
| |
| Unregistered |<--------------------------\
|________________| |
| |
/Init | |
------------ | |
snd REGREQ | +--------+ |
| | | rec REGAUTH |
_______V____V___ | ----------- |
| | | snd REGREQ |
| Reg Sent +----+ |
|________________+----------+ |
| ^ | rec REGAUTH |
rec REGACK | | | /No Credentials|
------------ | | REG timeout | -------------- |
snd ack | | ------- | snd ack |
| | REGREQ __V___ |
_______V____|___ | | |
| | | No | |
| Registered | | Auth | |
|________________| |______| |
| ^ |
| | rec REGAUTH |
| release | /No Credentials|
| ------- | -------------- |
+-------+ | snd REGREL | snd ack |
rec REGAUTH | | | | |
----------- | _V_____V________ | |
snd REGREL | | |----------+ |
+-----+ Releasing |---------------------------+
|________________| rec ACK
-------
x
________________
| |
| Unregistered |<--------------------------\
|________________| |
| |
/Init | |
------------ | |
snd REGREQ | +--------+ |
| | | rec REGAUTH |
_______V____V___ | ----------- |
| | | snd REGREQ |
| Reg Sent +----+ |
|________________+----------+ |
| ^ | rec REGAUTH |
rec REGACK | | | /No Credentials|
------------ | | REG timeout | -------------- |
snd ack | | ------- | snd ack |
| | REGREQ __V___ |
_______V____|___ | | |
| | | No | |
| Registered | | Auth | |
|________________| |______| |
| ^ |
| | rec REGAUTH |
| release | /No Credentials|
| ------- | -------------- |
+-------+ | snd REGREL | snd ack |
rec REGAUTH | | | | |
----------- | _V_____V________ | |
snd REGREL | | |----------+ |
+-----+ Releasing |---------------------------+
|________________| rec ACK
-------
x
__________
rec REGREJ | |
---------- *->| Rejected |
snd ack |__________|
__________
rec REGREJ | |
---------- *->| Rejected |
snd ack |__________|
Figure 1: Registrant State Diagram
图1：注册人状态图
Registration, illustrated in Figure 1, is performed by a registrant that sends a username and a registration 'refresh' period to the registrar. This is accomplished with a REGREQ message. If authentication is required, the registrar responds with the REGAUTH message that indicates the types of authentication supported by the
注册，如图1所示，由注册人执行，该注册人向注册人发送用户名和注册“刷新”周期。这是通过REGREQ消息完成的。如果需要身份验证，注册器将使用REGAUTH消息进行响应，该消息指示注册器支持的身份验证类型
registrar. In response, the registrant resends a REGREQ with one of the supported authentications. If the registrant cannot authenticate, no further action is necessary. If accepted, the registrar sends a REGACK message, which MUST indicate the 'apparent address' and SHOULD indicate the 'refresh'/expire time. If no 'refresh' is sent, a default registration expiration of 60 seconds MUST be assumed by both peers. At any time during this exchange, the registrar may send a REGREJ message to indicate a failure.
登记员作为响应，注册人使用支持的认证之一重新发送REGREQ。如果注册人无法认证，则无需采取进一步行动。如果接受，注册器将发送一条重新确认消息，该消息必须指示“明显地址”，并应指示“刷新”/“过期时间”。如果未发送“刷新”，则两个对等方都必须假定默认注册到期时间为60秒。在交换过程中的任何时候，注册器都可以发送REGREJ消息来指示失败。
A registration has a specified time period associated with it for which it is valid. This time period begins when the registrar sends a REGACK message. A registrant may extend that time period by repeating the registration process. A registrant MAY also force an expiration in the registrar by sending the REGREL message. This message may be challenged with REGAUTH or, if sufficient credentials were included, it will be accepted with REGACK. In response to a REGAUTH, a REGREL message SHOULD be resent using the specified credentials.
注册具有与之关联的指定有效时间段。此时间段从注册器发送重新确认消息时开始。注册人可通过重复注册过程延长该期限。注册人也可以通过发送“重新注册”消息在注册人中强制到期。此消息可能会被REGAUTH质询，或者，如果包含足够的凭据，则将被REGACK接受。响应重新授权，应使用指定的凭据重新发送重新授权消息。
See Sections 9.3 and 9.4 for example call flows.
呼叫流示例见第9.3节和第9.4节。
The REGREQ occurs independently of any media-carrying call. A REGREQ MUST include the 'username' IE and SHOULD include the 'refresh' IE. A REGREQ is used both for an initial registration request as well as for a reply to a REGAUTH. As a reply to a REGAUTH message, it MUST include credentials such as a response to a REGAUTH's challenge.
REGREQ独立于任何承载呼叫的媒体。REGREQ必须包括“用户名”IE，并应包括“刷新”IE。REGREQ用于初始注册请求以及回复REGAUTH。作为对REGAUTH消息的答复，它必须包括凭据，如对REGAUTH质询的响应。
Upon receipt of a REGREQ message that has credentials, a registrar MUST determine their validity. If valid, it MUST respond with a REGACK message indicating the time period for which this registration is valid. If the provided credentials are not valid or the registrar cannot validate the credentials, the registrar MUST respond with a REGREJ message. If credentials are not provided, the registrar MUST respond with a REGAUTH message that indicates the available authentication methods.
在收到具有凭据的REGREQ消息后，注册器必须确定其有效性。如果有效，它必须以REGACK消息响应，指示此注册有效的时间段。如果提供的凭据无效或注册器无法验证凭据，则注册器必须使用REGREJ消息进行响应。如果未提供凭据，则注册器必须以REGAUTH消息响应，该消息指示可用的身份验证方法。
Registrants MUST implement this message and registrars MUST be able to process it.
注册人必须执行此消息，并且注册人必须能够处理此消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------+----------------+-------------+-------------+
| IE | Section | Status | Comments |
+------------+----------------+-------------+-------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | per REGAUTH |
| | | | |
| RSA Result | Section 8.6.16 | Conditional | per REGAUTH |
| | | | |
| Refresh | Section 8.6.18 | Optional | |
+------------+----------------+-------------+-------------+
+------------+----------------+-------------+-------------+
| IE | Section | Status | Comments |
+------------+----------------+-------------+-------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | per REGAUTH |
| | | | |
| RSA Result | Section 8.6.16 | Conditional | per REGAUTH |
| | | | |
| Refresh | Section 8.6.18 | Optional | |
+------------+----------------+-------------+-------------+
A REGAUTH is a response to a REGREQ or REGREL. It is sent when a registrar requires authentication to permit registration. A REGAUTH message MUST include the 'authentication methods' and 'username' IEs, and the 'MD5 challenge' or 'RSA challenge' IE if the authentication methods include MD5 or RSA.
REGAUTH是对REGREQ或REGREL的响应。当注册官要求认证以允许注册时，会发送该消息。ReAuth消息必须包括“身份验证方法”和“用户名”IE，以及“MD5质询”或“RSA质询”，如果身份验证方法包括MD5或RSA。
Upon receipt of a REGAUTH message, the registrant MUST resend the REGREQ or REGREL message with one of the requested credentials, if it has the specified credentials.
在收到REGAUTH消息后，注册人必须使用请求的凭据之一重新发送REGREQ或REGREL消息（如果其具有指定凭据）。
Registrars MUST implement this message and registrants MUST be able to process it.
注册人必须实现此消息，并且注册人必须能够处理此消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+--------------+----------------+-------------+---------------+
| IE | Section | Status | Comments |
+--------------+----------------+-------------+---------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Auth Methods | Section 8.6.13 | Required | |
| | | | |
| Challenge | Section 8.6.14 | Conditional | If RSA or MD5 |
+--------------+----------------+-------------+---------------+
+--------------+----------------+-------------+---------------+
| IE | Section | Status | Comments |
+--------------+----------------+-------------+---------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Auth Methods | Section 8.6.13 | Required | |
| | | | |
| Challenge | Section 8.6.14 | Conditional | If RSA or MD5 |
+--------------+----------------+-------------+---------------+
A REGACK is sent in response to a REGREQ. A REGACK typically includes the 'refresh' IE specifying the number of seconds before the registration will expire. If the 'refresh' IE is not included with a REGACK, a default registration expiration of 60 seconds MUST be assumed. A REGACK MAY also include the 'username' and 'apparent
REGACK被发送以响应REGREQ。重新打包通常包括“刷新”，即指定注册到期前的秒数。如果“刷新”IE未包含在重新打包中，则必须假定默认注册过期时间为60秒。REGACK还可能包括“用户名”和“外观”
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.
地址指示对等方如何识别注册人。也可以发送与呼叫者身份或注册发生时间相关的IEs。
Receipt of a REGACK message requires an ACK in response.
接收重新确认消息需要ACK响应。
Registrars MUST be able to send this message and registrants MUST be able to process it.
注册人必须能够发送此消息，注册人必须能够处理此消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------------+----------------+----------+----------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Date Time | Section 8.6.28 | Required | |
| | | | |
| Apparent Address | Section 8.6.17 | Required | |
| | | | |
| Message Count | Section 8.6.23 | Optional | |
| | | | |
| Calling Number | Section 8.6.2 | Optional | |
| | | | |
| Calling Name | Section 8.6.4 | Optional | |
| | | | |
| Refresh | Section 8.6.18 | Optional | |
+------------------+----------------+----------+----------+
+------------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------------+----------------+----------+----------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Date Time | Section 8.6.28 | Required | |
| | | | |
| Apparent Address | Section 8.6.17 | Required | |
| | | | |
| Message Count | Section 8.6.23 | Optional | |
| | | | |
| Calling Number | Section 8.6.2 | Optional | |
| | | | |
| Calling Name | Section 8.6.4 | Optional | |
| | | | |
| Refresh | Section 8.6.18 | Optional | |
+------------------+----------------+----------+----------+
A REGREJ indicates that a registration request has been rejected. This rejection can occur for several reasons. A REGREJ MUST include the 'causecode' and 'cause' IEs to specify why registration was rejected.
REGREJ表示注册请求已被拒绝。这种拒绝可能有几个原因。REGREJ必须包含“原因代码”和“原因”IEs，以指定拒绝注册的原因。
Upon receipt of a REGREJ message, the registrant MUST consider registration process unsuccessful and no further interaction is required. A peer MAY reinitiate the process at later time accounting for potential configuration changes on the registrar or registrant.
在收到一个DRYJ消息后，注册人必须考虑注册过程不成功，并且不需要进一步的交互。对等方可在稍后重新初始化该过程，以考虑注册者或注册者上的潜在配置更改。
Both registrants and registrars MUST be capable of sending and processing this message.
注册人和注册人都必须能够发送和处理此消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Required | |
| | | | |
| Cause Code | Section 8.6.33 | Required | |
+------------+----------------+----------+----------+
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Required | |
| | | | |
| Cause Code | Section 8.6.33 | Required | |
+------------+----------------+----------+----------+
A REGREL is used by a registrant for a forced release of a prior registration. It MUST include the 'username' IE to identify the registrant to be released, and MAY include the 'causecode' and 'cause' IEs to specify why registration is being released.
注册人使用Regel强制解除先前的注册。它必须包括“用户名”IE以识别要发布的注册人，还可能包括“原因代码”和“原因”IE以指定发布注册的原因。
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.
收到此消息后，对等方必须使用提供的凭据对发送方进行身份验证，或发送请求凭据的重新授权消息。如果经过身份验证，则必须立即清除指定注册人的注册，或者如果未找到注册，则发送REGREJ消息。
Registrants SHOULD be capable of sending this message and registrars MUST be able to process it.
注册人应该能够发送此消息，并且注册人必须能够处理此消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+----------+----------------+-------------+-------------------------+
| IE | Section | Status | Comments |
+----------+----------------+-------------+-------------------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| MD5 | Section 8.6.15 | Conditional | MD5 or RSA Result is |
| Result | | | required |
| | | | |
| RSA | Section 8.6.16 | Conditional | |
| Result | | | |
| | | | |
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause | Section 8.6.33 | Optional | |
| Code | | | |
+----------+----------------+-------------+-------------------------+
+----------+----------------+-------------+-------------------------+
| IE | Section | Status | Comments |
+----------+----------------+-------------+-------------------------+
| Username | Section 8.6.6 | Required | |
| | | | |
| MD5 | Section 8.6.15 | Conditional | MD5 or RSA Result is |
| Result | | | required |
| | | | |
| RSA | Section 8.6.16 | Conditional | |
| Result | | | |
| | | | |
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause | Section 8.6.33 | Optional | |
| Code | | | |
+----------+----------------+-------------+-------------------------+
+--------+ HANGUP/ack
| |
_____________|__ |
| | |
+--------->| Initial |<----+
| |________________|<---------------------+
| | ^
| start call | |
| ---------- | |
| send NEW | +-------+ |
| | | | rec AUTHREQ |
| _____V__V__ | ----------- |
| | | | snd AUTHREP |
+------------| Waiting |----+ |
rec REJECT |___________|------------------------>+
---------- | |
ack | rec HANGUP |
| --------- |
| snd ack |
| |
rec ACCEPT | |
---------- | +------+ |
snd ack | | | PROCEEDING / ack |
_________V___V | RINGING / ack |
| | | |
| Linked |-----+ |
|______________|------------------------>+
| rec HANGUP |
rec ANSWER | ---------- |
----------- | snd ack |
snd ack | |
| |
| rec HANGUP |
_______V________ --------- |
| | snd ack |
| UP |--------------------->+
|________________|--------------------->+
finish
------
snd HANGUP
+--------+ HANGUP/ack
| |
_____________|__ |
| | |
+--------->| Initial |<----+
| |________________|<---------------------+
| | ^
| start call | |
| ---------- | |
| send NEW | +-------+ |
| | | | rec AUTHREQ |
| _____V__V__ | ----------- |
| | | | snd AUTHREP |
+------------| Waiting |----+ |
rec REJECT |___________|------------------------>+
---------- | |
ack | rec HANGUP |
| --------- |
| snd ack |
| |
rec ACCEPT | |
---------- | +------+ |
snd ack | | | PROCEEDING / ack |
_________V___V | RINGING / ack |
| | | |
| Linked |-----+ |
|______________|------------------------>+
| rec HANGUP |
rec ANSWER | ---------- |
----------- | snd ack |
snd ack | |
| |
| rec HANGUP |
_______V________ --------- |
| | snd ack |
| UP |--------------------->+
|________________|--------------------->+
finish
------
snd HANGUP
Figure 2: Call Origination State Diagram
图2：呼叫发起状态图
+--------+ rec HANGUP/ack
| |
_____________V__ | rec NEW(no Auth)/snd AUTHREQ
| | |
| Initial |-----+ rec NEW(not Auth)/snd REJECT
| |
|________________|<--------------------+
| |
rec NEW | |
(valid credentials)| |
---------- | +------+ |
snd ACCEPT | | | snd PROCEEDING |
_________V___V | snd RINGING |
| | | |
| Linked |-----+ |
| |
|______________|------------------------>+
| rec HANGUP |
/answered | ---------- |
----------- | snd ack |
snd ANSWER | |
| rec HANGUP |
_______V________ --------- |
| | snd ack |
| UP |--------------------->+
|________________|--------------------->+
finish
------
snd HANGUP
+--------+ rec HANGUP/ack
| |
_____________V__ | rec NEW(no Auth)/snd AUTHREQ
| | |
| Initial |-----+ rec NEW(not Auth)/snd REJECT
| |
|________________|<--------------------+
| |
rec NEW | |
(valid credentials)| |
---------- | +------+ |
snd ACCEPT | | | snd PROCEEDING |
_________V___V | snd RINGING |
| | | |
| Linked |-----+ |
| |
|______________|------------------------>+
| rec HANGUP |
/answered | ---------- |
----------- | snd ack |
snd ANSWER | |
| rec HANGUP |
_______V________ --------- |
| | snd ack |
| UP |--------------------->+
|________________|--------------------->+
finish
------
snd HANGUP
Figure 3: Call Termination State Diagram
图3：呼叫终止状态图
The IAX protocol can be used to set up 'links' or 'call legs' between two peers for the purposes of placing a call. The process, illustrated in Figure 2 and Figure 3, starts when a peer sends a NEW message indicating the destination 'number' (or name) of a Called Party on the remote peer. The remote peer can respond with either a credentials challenge (AUTHREQ), a REJECT message, or an ACCEPT message. The AUTHREQ message indicates the permitted authentication schemes and SHOULD result in the sending of an AUTHREP message with the requested credentials. The REJECT message indicates the call cannot be established at this time. ACCEPT indicates that the call leg between these two peers is established and that higher-level call signaling (Section 6.3) MAY proceed. After sending or receiving the
IAX协议可用于在两个对等方之间建立“链路”或“呼叫分支”，以便进行呼叫。如图2和图3所示，当一个对等方发送一条新消息，指示远程对等方上被叫方的目的地“号码”（或名称）时，该过程开始。远程对等方可以使用凭据质询（AUTHREQ）、拒绝消息或接受消息进行响应。AUTHREQ消息指示允许的身份验证方案，并应导致发送带有请求凭据的AUTHREP消息。拒绝消息表示此时无法建立呼叫。ACCEPT表示这两个对等方之间的呼叫分支已经建立，并且可以继续进行更高级别的呼叫信令（第6.3节）。在发送或接收
ACCEPT message, the call leg is in the 'Linked' state and is used to pass call control messages until the call is completed. Further detail on messages used for this process can be found in Section 6.3.
接受消息时，呼叫分支处于“链接”状态，用于传递呼叫控制消息，直到呼叫完成。有关此过程中使用的消息的更多详细信息，请参见第6.3节。
Call legs are labeled with a pair of identifiers. Each end of the call leg assigns the source or destination identifier during the call leg creation process.
调用分支用一对标识符进行标记。呼叫分支的每一端在呼叫分支创建过程中分配源或目标标识符。
A NEW message is sent to initiate a call. It is the first call-specific message sent to initiate an actual media exchange between two peers. 'NEW' messages are unique compared to other Call Supervision messages in that they do not require a destination call identifier in their header. This absence is because the remote peer's source call identifier is not created until after receipt of this frame. Before sending a NEW message, the local IAX peer MUST assign a source call identifier that is not currently being used for another call. A time-stamp MUST also be assigned for the call, beginning at zero and incrementing by one each millisecond. Sequence numbers for a NEW message, described in the transport section, (Section 7) are both set to 0.
将发送一条新消息以发起呼叫。这是发送的第一条呼叫特定消息，用于启动两个对等方之间的实际媒体交换。”与其他呼叫监控消息相比，“新”消息是唯一的，因为它们不需要在报头中包含目标呼叫标识符。这种缺失是因为远程对等方的源调用标识符在收到此帧后才创建。在发送新消息之前，本地IAX对等方必须分配当前未用于另一个呼叫的源呼叫标识符。还必须为调用分配一个时间戳，从零开始，每毫秒递增一个。传输部分（第7部分）中描述的新消息的序列号均设置为0。
A NEW message MUST include the 'version' IE, and it MUST be the first IE; the order of other IEs is unspecified. A NEW SHOULD generally include IEs to indicate routing on the remote peer, e.g., via the 'called number' IE or to indicate a peer partition or ruleset, the 'called context' IE. Caller identification and CODEC negotiation IEs MAY also be included.
新消息必须包含“版本”IE，并且必须是第一个IE；其他IEs的顺序未明。新系统通常应包括指示远程对等上路由的IEs，例如，通过“被叫号码”IE或指示对等分区或规则集的IEs，“被叫上下文”IE。也可包括呼叫者识别和编解码器协商IEs。
Upon receipt of a NEW message, the receiving peer examines the destination and MUST perform one of the following actions:
收到新消息后，接收对等方检查目的地，必须执行以下操作之一：
Send a REJECT response,
发送拒绝响应，
Challenge the caller with an AUTHREQ response,
使用AUTHREQ响应质询调用方，
Accept the call using an ACCEPT message, or
使用接受消息接受呼叫，或
Abort the connection using a HANGUP message, although the REJECT message is preferred at this point in call.
使用挂断消息中止连接，尽管此时首选拒绝消息。
If the call is accepted, the peer MUST progress the call and further respond with one of PROCEEDING, RINGING, BUSY, or ANSWER depending on the status of the called party on the peer. See Section 6.3 for further details.
如果呼叫被接受，对等方必须继续呼叫，并根据被呼叫方在对等方上的状态，进一步响应继续、振铃、忙或应答。详见第6.3节。
The following table specifies IEs for the NEW message:
下表指定了新消息的IEs：
+--------------+----------------+-------------+---------------------+
| IE | Section | Status | Comments |
+--------------+----------------+-------------+---------------------+
| Version | Section 8.6.10 | Required | |
| | | | |
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Auto Answer | Section 8.6.24 | Optional | |
| | | | |
| Codecs Prefs | Section 8.6.35 | Required | |
| | | | |
| Calling | Section 8.6.29 | Required | |
| Presentation | | | |
| | | | |
| Calling | Section 8.6.2 | Optional | |
| Number | | | |
| | | | |
| Calling TON | Section 8.6.30 | Required | |
| | | | |
| Calling TNS | Section 8.6.31 | Required | |
| | | | |
| Calling Name | Section 8.6.4 | Optional | |
| | | | |
| ANI | Section 8.6.3 | Optional | |
| | | | |
| Language | Section 8.6.9 | Optional | |
| | | | |
| DNID | Section 8.6.12 | Optional | |
| | | | |
| Called | Section 8.6.5 | Conditional | 'Default' assumed |
| Context | | | if IE excluded |
| | | | |
| Username | Section 8.6.6 | Optional | |
| | | | |
| RSA Result | Section 8.6.16 | Conditional | If challenged with |
| | | | RSA |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | If challenged with |
| | | | MD5 |
| | | | |
| Format | Section 8.6.8 | Required | |
| | | | |
| Capability | Section 8.6.7 | Conditional | |
| | | | |
| ADSICPE | Section 8.6.11 | Optional | |
| | | | |
| Date Time | Section 8.6.28 | Optional | Suggested |
+--------------+----------------+-------------+---------------------+
| IE | Section | Status | Comments |
+--------------+----------------+-------------+---------------------+
| Version | Section 8.6.10 | Required | |
| | | | |
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Auto Answer | Section 8.6.24 | Optional | |
| | | | |
| Codecs Prefs | Section 8.6.35 | Required | |
| | | | |
| Calling | Section 8.6.29 | Required | |
| Presentation | | | |
| | | | |
| Calling | Section 8.6.2 | Optional | |
| Number | | | |
| | | | |
| Calling TON | Section 8.6.30 | Required | |
| | | | |
| Calling TNS | Section 8.6.31 | Required | |
| | | | |
| Calling Name | Section 8.6.4 | Optional | |
| | | | |
| ANI | Section 8.6.3 | Optional | |
| | | | |
| Language | Section 8.6.9 | Optional | |
| | | | |
| DNID | Section 8.6.12 | Optional | |
| | | | |
| Called | Section 8.6.5 | Conditional | 'Default' assumed |
| Context | | | if IE excluded |
| | | | |
| Username | Section 8.6.6 | Optional | |
| | | | |
| RSA Result | Section 8.6.16 | Conditional | If challenged with |
| | | | RSA |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | If challenged with |
| | | | MD5 |
| | | | |
| Format | Section 8.6.8 | Required | |
| | | | |
| Capability | Section 8.6.7 | Conditional | |
| | | | |
| ADSICPE | Section 8.6.11 | Optional | |
| | | | |
| Date Time | Section 8.6.28 | Optional | Suggested |
| | | | |
| Encryption | Section 8.6.34 | Optional | |
| | | | |
| OSP Token | Section 8.6.42 | Optional | |
+--------------+----------------+-------------+---------------------+
| | | | |
| Encryption | Section 8.6.34 | Optional | |
| | | | |
| OSP Token | Section 8.6.42 | Optional | |
+--------------+----------------+-------------+---------------------+
An ACCEPT response is issued when a NEW message is received, and authentication has taken place (if required). It acknowledges receipt of a NEW message and indicates that the call leg has been set up on the terminating side, including assigning a CODEC. An ACCEPT message MUST include the 'format' IE to indicate its desired CODEC to the originating peer. The CODEC format MUST be one of the formats sent in the associated NEW command.
接收到新消息并进行身份验证（如果需要）时，将发出接受响应。它确认接收到新消息，并指示已在终端端设置呼叫分支，包括分配编解码器。接受消息必须包含“格式”IE，以向发起对等方指示其所需的编解码器。编解码器格式必须是在关联的NEW命令中发送的格式之一。
Upon receipt of an ACCEPT, an ACK MUST be sent and the CODEC for the call MAY be configured using the 'format' IE from the received ACCEPT. The call then waits for an ANSWER, HANGUP, or other call control signal. (See Section 6.3.) If a subsequent ACCEPT message is received for a call that has already started, or has not sent a NEW message, the message MUST be ignored.
接收到接受后，必须发送ACK，并且可以使用接收到的接受的“格式”IE配置呼叫的编解码器。然后呼叫等待应答、挂断或其他呼叫控制信号。（参见第6.3节。）如果收到已开始或未发送新消息的呼叫的后续接受消息，则必须忽略该消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+--------+---------------+----------+----------+
| IE | Section | Status | Comments |
+--------+---------------+----------+----------+
| Format | Section 8.6.8 | Required | |
+--------+---------------+----------+----------+
+--------+---------------+----------+----------+
| IE | Section | Status | Comments |
+--------+---------------+----------+----------+
| Format | Section 8.6.8 | Required | |
+--------+---------------+----------+----------+
A REJECT response is sent to indicate that a NEW, AUTHREP, DIAL, or ACCEPT request has been denied. It MAY be due to an authentication failure, an invalid username, or if a peer cannot provide a valid password or response to an issued challenge. It MAY also be used to notify a peer of a call setup failure, e.g., when IAX peers cannot negotiate a CODEC to use. Upon receipt of a REJECT message, the call leg is destroyed and no further action is required. (Note: REJECT messages require an explicit ACK.)
将发送拒绝响应，以指示新请求、AUTHREP请求、拨号请求或接受请求已被拒绝。这可能是由于身份验证失败、用户名无效，或者对等方无法提供有效密码或对发出的质询做出响应。它还可用于通知对等方呼叫设置失败，例如，当IAX对等方无法协商要使用的编解码器时。收到拒绝消息后，调用分支将被销毁，无需采取进一步行动。（注意：拒绝消息需要明确的确认。）
REJECT messages MAY include the 'causecode' and 'cause' IEs to indicate the rejection reason.
拒绝消息可能包括“原因代码”和“原因”以指示拒绝原因。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause Code | Section 8.6.33 | Optional | |
+------------+----------------+----------+----------+
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause Code | Section 8.6.33 | Optional | |
+------------+----------------+----------+----------+
A HANGUP message is sent by either peer and indicates a call tear-down. It MAY include the 'causecode' and 'cause' IEs to indicate the reason for terminating the call. Upon receipt of a HANGUP message, an IAX peer MUST immediately respond with an ACK, and then destroy the call leg at its end. After a HANGUP message has been received for a call leg, any messages received that reference that call leg (i.e., have the same source/destination call identifiers) MUST be answered with an INVAL message. This indicates that the received message is invalid because the call no longer exists.
任何一个对等方都会发送一条挂断消息，表示呼叫中断。它可能包括“原因代码”和“原因”以指示终止呼叫的原因。收到挂断消息后，IAX对等方必须立即响应ACK，然后在其末端销毁呼叫分支。在接收到呼叫分支的挂断消息后，必须使用INVAL消息应答接收到的引用该呼叫分支的任何消息（即，具有相同的源/目标呼叫标识符）。这表示收到的消息无效，因为呼叫已不存在。
After sending a HANGUP message, the sender MUST destroy the call and respond to subsequent messages regarding this call with an INVAL message.
发送挂断消息后，发送方必须销毁该呼叫，并用INVAL消息响应有关该呼叫的后续消息。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause Code | Section 8.6.33 | Optional | |
+------------+----------------+----------+----------+
+------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------+----------------+----------+----------+
| Cause | Section 8.6.21 | Optional | |
| | | | |
| Cause Code | Section 8.6.33 | Optional | |
+------------+----------------+----------+----------+
An AUTHREP MUST include the appropriate challenge response or password IE, and is only sent in response to an AUTHREQ. An AUTHREP requires a response of either an ACCEPT or a REJECT.
AUTHREP必须包含相应的质询响应或密码IE，并且仅在响应AUTHREQ时发送。AUTHREP需要接受或拒绝的响应。
Typical reasons for rejecting an AUTHREP include 'destination does not exist' and 'suitable bearer not found'.
拒绝AUTHREP的典型原因包括“目的地不存在”和“未找到合适的承载者”。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+------------+----------------+-------------+----------+
| IE | Section | Status | Comments |
+------------+----------------+-------------+----------+
| RSA Result | Section 8.6.16 | Conditional | If RSA |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | If MD5 |
+------------+----------------+-------------+----------+
+------------+----------------+-------------+----------+
| IE | Section | Status | Comments |
+------------+----------------+-------------+----------+
| RSA Result | Section 8.6.16 | Conditional | If RSA |
| | | | |
| MD5 Result | Section 8.6.15 | Conditional | If MD5 |
+------------+----------------+-------------+----------+
The AUTHREQ message is sent in response to a NEW message if authentication is required for the call to be accepted. It MUST include the 'authentication methods' and 'username' IEs, and the 'challenge' IE if MD5 or RSA authentication is specified.
如果要接受调用需要身份验证，则会发送AUTHREQ消息以响应新消息。如果指定了MD5或RSA身份验证，则必须包括“身份验证方法”和“用户名”IE，以及“质询”IE。
Upon receiving an AUTHREQ message, the receiver MUST respond with an AUTHREP or HANGUP message.
接收到AUTHREQ消息后，接收器必须使用AUTHREP或HANGUP消息进行响应。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+--------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+--------------+----------------+----------+----------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Auth Methods | Section 8.6.13 | Required | |
| | | | |
| Challenge | Section 8.6.14 | Required | |
+--------------+----------------+----------+----------+
+--------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+--------------+----------------+----------+----------+
| Username | Section 8.6.6 | Required | |
| | | | |
| Auth Methods | Section 8.6.13 | Required | |
| | | | |
| Challenge | Section 8.6.14 | Required | |
+--------------+----------------+----------+----------+
IAX's call control messages provide end-to-end signaling functions common to other telephony control protocols. The messages include RINGING, ANSWER, BUSY, and PROCEEDING. These messages MUST only be sent after an IAX call leg has been ACCEPTed.
IAX的呼叫控制消息提供其他电话控制协议所共有的端到端信令功能。消息包括响铃、应答、忙和继续。只有在接受IAX呼叫分支后，才能发送这些消息。
In response to an exchange starting with a NEW message, typically, the first call control message is RINGING; however, a PROCEEDING message MAY precede it or the call MAY proceed directly to the ANSWER message. If the call is answered, an ANSWER message will be sent. Other possibilities include a "BUSY" indication, or if the called party's service cannot be reached, the call will be torn down using the link-level HANGUP and an appropriate cause code.
通常，响应于以新消息开始的交换，第一呼叫控制消息正在振铃；但是，通话前可能会有一条正在进行的消息，或者通话可能会直接转到应答消息。如果呼叫已应答，将发送应答消息。其他可能性包括“忙”指示，或者如果无法接通被叫方的服务，则将使用链路级挂断和适当的原因码中断呼叫。
If the link was started with a DIAL message, the sequence is an optional PROCEEDING, then optional RINGING, then ANSWER or BUSY. Of course, a link level HANGUP MAY occur at any time.
如果链接是通过拨号信息启动的，则顺序是可选的继续，然后是可选的振铃，然后是应答或忙。当然，链路级挂起可能随时发生。
Various private extensions to IAX Control messages have been deployed for passing application-specific data over the IAX control link. One such extension is an application that controls ham radio transceivers. An IAX peer that receives a control message that is not understood MUST respond with the UNSUPPORT message.
已部署了IAX控制消息的各种专用扩展，用于通过IAX控制链路传递特定于应用程序的数据。一个这样的扩展是控制ham无线电收发机的应用程序。接收到未被理解的控制消息的IAX对等方必须以不支持消息进行响应。
The mandatory IAX control messages are explained below.
强制性IAX控制消息解释如下。
The PROCEEDING message SHOULD be sent to a calling party when their call request is being processed by a further network element but has not yet reached the called party.
当另一个网元正在处理呼叫请求，但尚未到达被叫方时，应将进行中的消息发送给主叫方。
Upon receipt of a PROCEEDING message, the peer SHOULD perform protocol-specific actions to indicate this fact to the calling party, e.g., tones, an ISUP (ISDN User Part) Proceeding message, etc. If the prior call leg is utilizing the IAX protocol, a PROCEEDING message MUST be sent to that peer. The processing of this message at an originating or transcoding peer is not specified; however, if possible, the status may be displayed to the calling party.
在接收到进行中的消息后，对等方应执行特定于协议的操作，以向呼叫方指示这一事实，例如，音调、ISUP（ISDN用户部分）进行中的消息等。如果先前的呼叫分支正在使用IAX协议，则必须向该对等方发送进行中的消息。未指定在始发或转码对等端对该消息的处理；但是，如果可能，状态可以显示给呼叫方。
The PROCEEDING message does not require any IEs.
继续发送的消息不需要任何IEs。
This message is sent from a terminating party to indicate that the called party's service has processed the call request and is being alerted to the call. An IAX RINGING message MUST be sent to an IAX-based calling party when the peer determines that the called party is being alerted, e.g., when their phone is ringing.
此消息由终止方发送，以指示被叫方的服务已处理呼叫请求，并收到呼叫警报。当对等方确定被叫方正在收到警报时（例如，当其手机正在鸣响时），必须向基于IAX的主叫方发送IAX振铃消息。
Upon receipt of an IAX RINGING message, the peer MUST pass this indication to the calling party, unless the calling party has already received such indication. For an initiating peer, this is typically done by starting the ring-back tone; however, many implementations start ring-back before ringing in order to meet user expectations. If the calling party is using the IAX protocol, a RINGING message MUST be passed to this caller.
在收到IAX振铃消息后，对等方必须将该指示传递给主叫方，除非主叫方已经收到该指示。对于发起对等方，这通常通过启动回铃音来完成；然而，许多实现在振铃之前就开始回铃，以满足用户的期望。如果主叫方使用IAX协议，则必须向该主叫方传递振铃消息。
The RINGING message does not require any IEs.
铃声信息不需要任何提示。
This message is sent from the called party to indicate that the party has accepted the call request and is communicating with the calling party. Upon receipt of this message, any ring-back or other progress tones MUST be terminated and the communications channel MUST be opened.
此消息由被叫方发送，表示被叫方已接受呼叫请求并正在与主叫方通信。收到此消息后，必须终止任何回铃或其他进度音，并且必须打开通信通道。
The ANSWER message does not require any IEs.
应答消息不需要任何IEs。
The FLASH message is sent to indicate a mid-call feature. Its interpretation is system dependent and if it is not expected, it SHOULD be ignored. Typically, this message is only sent from analog telephone adapters when a brief circuit interruption is made during an answered call.
发送闪存消息以指示通话中的功能。其解释取决于系统，如果不是预期的，则应忽略。通常，只有在接听电话期间发生短暂电路中断时，才会从模拟电话适配器发送此消息。
The FLASH message does not require any IEs.
闪存消息不需要任何IEs。
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.
发送HOLD（保持）消息以使远程系统停止在此频道上传输音频，并可选择使用音乐或其他声音替换音频。如果远程系统无法执行此请求，则应忽略此请求。
The HOLD message SHOULD only be sent in IAX calls that are started using the DIAL message.
保持消息只能在使用拨号消息启动的IAX呼叫中发送。
The HOLD message does not require any IEs.
保持消息不需要任何IEs。
The UNHOLD message is sent to cause the remote system to resume transmitting audio on this channel. If the remote system cannot perform this request, it SHOULD be ignored.
发送UNHOLD消息以使远程系统恢复在此频道上传输音频。如果远程系统无法执行此请求，则应忽略此请求。
The UNHOLD message SHOULD only be sent in IAX calls after the HOLD message.
取消挂起消息只能在挂起消息之后的IAX调用中发送。
The UNHOLD message does not require any IEs.
“取消冻结”消息不需要任何提示。
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.
发送QUELCH消息以使远程对等方静噪或停止在此信道上传输音频。它可以用音乐或其他声音代替发送给另一方的音频。如果远程系统无法执行此请求，则应忽略此请求。
The QUELCH message MUST only be sent in IAX calls after an ACCEPT is sent or received; it SHOULD only be used on calls that are started using the NEW message.
QUELCH消息只能在发送或接收到ACCEPT后在IAX呼叫中发送；它只能用于使用新消息启动的呼叫。
The QUELCH message does not require any IEs.
QUELCH消息不需要任何IEs。
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.
发送UNQUELCH消息以使远程系统恢复在此频道上传输音频。如果以前用音乐或其他声音替换了音频，则必须立即停止。如果远程系统无法执行此请求，则应忽略此请求。
The UNQUELCH message SHOULD only be sent in IAX calls after the QUELCH message.
UNQUELCH消息只能在QUELCH消息之后的IAX调用中发送。
The UNQUELCH message does not require any IEs.
UNQUELCH消息不需要任何IEs。
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.
发送转接信息时，呼叫转接到的新号码必须包括在被叫号码IE中，并且可能包括被叫号码IE。呼叫腿不得用于任何其他用途，可能会被拆下。
The following table specifies IEs for this message:
下表指定了此消息的IEs：
+-----------+---------------+----------+----------------------------+
| IE | Section | Status | Comments |
+-----------+---------------+----------+----------------------------+
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Called | Section 8.6.5 | Optional | Use this IE if context is |
| Context | | | other than default. |
+-----------+---------------+----------+----------------------------+
+-----------+---------------+----------+----------------------------+
| IE | Section | Status | Comments |
+-----------+---------------+----------+----------------------------+
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Called | Section 8.6.5 | Optional | Use this IE if context is |
| Context | | | other than default. |
+-----------+---------------+----------+----------------------------+
If a peer is handling a call between two other IAX peers and the peer no longer has any need to monitor the progress, content, or duration of the call, it MAY remove itself from the call by directing the other two peers to communicate directly. This call path optimization, or "supervised transfer", is done in a manner that ensures the call will not be lost in the process; the initiating peer does not give up control of the process until it has confirmed the other two peers are communicating. Note: the parties involved in the call are not aware of this operation; it is purely a network operation.
如果一个对等方正在处理另外两个IAX对等方之间的呼叫，并且该对等方不再需要监控呼叫的进度、内容或持续时间，那么它可以通过指示其他两个对等方直接通信来将自己从呼叫中移除。这种呼叫路径优化，或“有监督的转移”，以确保呼叫不会在过程中丢失的方式进行；发起对等方在确认其他两个对等方正在通信之前不会放弃对流程的控制。注意：参与呼叫的各方不知道此操作；这纯粹是一种网络操作。
________________
rec TXREJ | | rec TXREL
---------- *--------->| None |<-----------------+
snd TXREJ |________________| ack ^
to other | | |
| V |
| |
| * (From All) |
/Init Transfer | | rec TXREQ |
------------ | | --------- |
snd TXREQ | | snd TXCNT |
to both | | |
_v___________v__ |
| | |
| Begin |----------------->+
|________________| |
| | |
rec TXACC | | rec TXREADY |
--------- | | --------- |
snd TXREADY | | x |
| | |
_v___________v__ |
| |----------------->+
----------| Ready |---------- |
| |________________| | |
| | | |
/Both Legs Ready| /Both Legs Ready| rec TXMEDIA| |
and not media-only| and media-only | | |
------------ | ------------ | -----------| |
snd TXREL | snd TXMEDIA | x | |
| | | |
____V____ _____V___ ___V_____ |
| | | | | | |
| Release | | Media | | Media | |
|_________| |_________| | Pass | |
| |_________| |
| | |
V V |
rec TXCNT +------------------------->+
---------- (In any state)
snd TXACC
________________
rec TXREJ | | rec TXREL
---------- *--------->| None |<-----------------+
snd TXREJ |________________| ack ^
to other | | |
| V |
| |
| * (From All) |
/Init Transfer | | rec TXREQ |
------------ | | --------- |
snd TXREQ | | snd TXCNT |
to both | | |
_v___________v__ |
| | |
| Begin |----------------->+
|________________| |
| | |
rec TXACC | | rec TXREADY |
--------- | | --------- |
snd TXREADY | | x |
| | |
_v___________v__ |
| |----------------->+
----------| Ready |---------- |
| |________________| | |
| | | |
/Both Legs Ready| /Both Legs Ready| rec TXMEDIA| |
and not media-only| and media-only | | |
------------ | ------------ | -----------| |
snd TXREL | snd TXMEDIA | x | |
| | | |
____V____ _____V___ ___V_____ |
| | | | | | |
| Release | | Media | | Media | |
|_________| |_________| | Pass | |
| |_________| |
| | |
V V |
rec TXCNT +------------------------->+
---------- (In any state)
snd TXACC
Figure 4: Call Path Optimization State Diagram
图4：呼叫路径优化状态图
When a peer initiates this procedure, both call legs MUST be in the UP state, i.e., they MUST have sent or received the ACCEPT message for that call leg. To start, it sends a TXREQ message with the addresses and information from the other remote peers to each its neighbors. If capable of performing this procedure, they begin transmitting all channel information to both the initiating peer and the new remote peer. They also send a TXCNT message indicating packet counts for the call leg to the new remote peer. Each TXCNT message is acknowledged with a TXACC message. The peers respond by sending a TXREADY message to the initiator indicating that they have confirmed the new communications path. When all remote peers have sent the initiator a TXREADY message, the transfer is successful and the initiator responds with a TXREL and has finished its involvement with the call. If during the transfer process, the two remote peers cannot communicate, they send a TXREJ message to the initiator. An example is shown in Section 9.5.
当对等方发起此过程时，两个呼叫分支都必须处于向上状态，即它们必须已发送或接收该呼叫分支的接受消息。首先，它发送一条TXREQ消息，其中包含来自其他远程对等方的地址和信息，并发送给每个远程对等方及其邻居。如果能够执行此过程，则它们开始将所有信道信息传输到发起对等方和新的远程对等方。它们还向新的远程对等方发送TXCNT消息，指示呼叫分支的数据包计数。每个TXCNT消息都用TXACC消息确认。对等方通过向发起方发送TXREADY消息来响应，该消息指示它们已确认新的通信路径。当所有远程对等方向发起方发送TXREADY消息时，传输成功，发起方用TXREL响应，并已完成参与呼叫。如果在传输过程中，两个远程对等方无法通信，它们将向启动器发送TXREJ消息。第9.5节给出了一个示例。
These messages are described in the sections that follow.
这些消息将在下面的章节中介绍。
The TXREQ message is sent by a peer to initiate the transfer process. When sent, it MUST be sent to both adjacent peers involved in the call.
TXREQ消息由对等方发送，以启动传输过程。发送时，必须将其发送给参与呼叫的两个相邻对等方。
It MUST include the following Information Elements:
它必须包括以下信息元素：
+------------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------------+----------------+----------+----------+
| Apparent Address | Section 8.6.17 | Required | |
| | | | |
| Call Number | Section 8.6.20 | Required | |
| | | | |
| Transfer ID | Section 8.6.26 | Required | |
+------------------+----------------+----------+----------+
+------------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+------------------+----------------+----------+----------+
| Apparent Address | Section 8.6.17 | Required | |
| | | | |
| Call Number | Section 8.6.20 | Required | |
| | | | |
| Transfer ID | Section 8.6.26 | Required | |
+------------------+----------------+----------+----------+
The Apparent Address is the IP address data structure address for the other remote peer. The Call Number IE is the callid used by the other remote peer and the Transfer ID is a unique number assigned by the initiator.
表观地址是另一个远程对等方的IP地址数据结构地址。呼叫号码IE是另一个远程对等方使用的callid，传输ID是由发起方分配的唯一号码。
Upon receipt of a TXREQ message for a valid call from the corresponding remote peer, a peer MUST respond by attempting to communicate with the newly specified remote peer. This task is accomplished by sending a TXCNT message directly to the peer at the address specified in the Apparent Address parameter.
在收到来自相应远程对等方的有效调用的TXREQ消息后，对等方必须通过尝试与新指定的远程对等方通信来响应。此任务是通过直接将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.
TXCNT消息用于验证与呼叫的潜在替代对等方的连接。它必须包括TRANSFERID，即在收到此类消息时，如果对等方之前已收到此呼叫分支的TXREQ，则对等方必须使用TXACC消息进行响应。
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.
如果TXCNT消息未成功传输，或者未收到TXACC消息响应，则必须通过向发起主机发送TXREJ消息来中止传输过程。
It MUST include the following Information Element:
它必须包括以下信息元素：
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
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.
与TXCNT消息一样，TXACC消息用于验证与潜在替换对等方的连接。它必须包括TRANSFERID，即，在收到此类消息后，如果对等方试图转移此呼叫分支，则对等方停止向发起对等方发送呼叫相关媒体，并向其发送TXREADY消息。
It MUST include the following Information Element:
它必须包括以下信息元素：
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
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.
TXREADY消息表示发送对等方已验证与指示其转接呼叫的对等方的连接。它必须包括TRANSFERID IE。当从两个远程对等方接收到TXREADY消息时，它必须停止媒体传输并向每个对等方发送TXREL消息。
It MUST include the following Information Element:
它必须包括以下信息元素：
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Transfer | Section 8.6.26 | Required | A unique number assigned |
| ID | | | by the initiator. |
+----------+----------------+----------+----------------------------+
The TXREL message indicates that the transfer process has successfully completed. After sending and upon receipt of this message, no further interaction (other than an ACK, of course) is needed between the peers on this call leg. The TXREL is also used to revert a split-media call (one where the media and signaling follow different paths) to a call where the media and signaling follow the same path.
TXREL消息表示传输过程已成功完成。在发送和接收此消息后，此呼叫分支上的对等方之间不需要进一步的交互（当然，ACK除外）。TXREL还用于将拆分媒体呼叫（其中媒体和信令遵循不同路径）恢复为媒体和信令遵循相同路径的呼叫。
It MUST include the following Information Element:
它必须包括以下信息元素：
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
The TXREL message indicates that the MEDIA transfer process has successfully completed. After sending and upon processing of this message, Full Frames MUST continue to follow the original signaling path and media frames MUST follow the newly negotiated path. This split-path process continues until the call ends with a HANGUP or peer receives a TXREL message for the call leg. A peer MAY force the paths to rejoin by sending a TXREL message.
TXREL消息表示介质传输过程已成功完成。在发送和处理此消息后，完整帧必须继续遵循原始信令路径，媒体帧必须遵循新协商的路径。此分割路径过程将继续进行，直到呼叫以挂断结束，或者对等方收到呼叫分支的TXREL消息。对等方可以通过发送TXREL消息来强制路径重新加入。
It MUST include the following Information Element:
它必须包括以下信息元素：
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
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.
TXREJ可在传输过程中随时发送，以指示传输无法继续。在接收到TXREJ消息后，如果接收方是发起对等方，则必须形成TXREJ消息并将其发送给另一个远程对等方。
The TXREJ message does not require any IEs.
TXREJ消息不需要任何IEs。
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.
挂断。见第6.2.5节。
REJECT. See Section 6.2.4.
拒绝见第6.2.4节。
TRANSFER. See Section 6.4.6.
转移见第6.4.6节。
TXREADY. See Section 6.5.4.
TXREADY。见第6.5.4节。
These messages are discussed in their respective sections. Also, if the reliable transport procedures determine that messaging cannot be maintained, the call leg MUST be torn down without any other indications over the errant IAX call leg.
这些信息将在各自的章节中讨论。此外，如果可靠的传输过程确定无法维持消息传递，则必须在错误的IAX呼叫分支上没有任何其他指示的情况下拆除呼叫分支。
The IAX protocol has various tools to determine the network load. It uses the POKE message to monitor reachability of remote peer and the LAGRQ message to measure the quality of a current call leg including the jitter buffer delay.
IAX协议有各种工具来确定网络负载。它使用POKE消息来监视远程对等方的可达性，使用LAGRQ消息来测量当前呼叫段的质量，包括抖动缓冲延迟。
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.
发送戳消息以测试远程IAX对等机的连接。它类似于PING消息，不同的是它必须在没有对远程端点的现有调用时发送。它还可用于将用户“限定”到远程对等方，以便远程对等方能够保持对用户状态的感知。POKE的目标呼叫号码必须为0。
Upon receiving a POKE message, the peer MUST respond with a PONG message.
在收到POKE消息后，对等方必须用PONG消息进行响应。
This message does not require any IEs.
此消息不需要任何IEs。
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.
发送PING消息以测试现有呼叫上远程IAX端点的连接。当对等方定义的秒数过去而没有在呼叫中接收到传入的媒体帧时，或默认情况下每20秒发送一次PING。收到PING需要发送一个确认PONG。
This message does not require any IEs.
此消息不需要任何IEs。
A PONG message is a response to a PING or a POKE. It acknowledges the connection. The receiver uses the time-stamp of the received PING or POKE and its times to determine the Round Trip Time of the connection. Several receiver report IEs MAY be included with a PONG, including received jitter, received frames, delay, and dropped frames. Receipt of a PONG requires an ACK.
乒乓球信息是对乒乓球或戳击的回应。它承认这种联系。接收器使用接收到的PING或POKE的时间戳及其时间来确定连接的往返时间。PONG可以包括多个接收机报告IEs，包括接收抖动、接收帧、延迟和丢弃帧。收到PONG需要ACK。
This message does not require any IEs.
此消息不需要任何IEs。
A LAGRQ is a lag request. It is sent to determine the lag between two IAX endpoints, including the amount of time used to process a frame through a jitter buffer (if any). It requires a clock-based time-stamp, and MUST be answered with a LAGRP, which MUST echo the LAGRQ's time-stamp. The lag between the two peers can be computed on the peer sending the LAGRQ by comparing the time-stamp of the LAGRQ and the time the LAGRP was received.
LAGRQ是一个滞后请求。发送它是为了确定两个IAX端点之间的延迟，包括通过抖动缓冲区（如果有）处理帧所用的时间量。它需要一个基于时钟的时间戳，并且必须用LAGRP应答，LAGRP必须与LAGRQ的时间戳相呼应。通过比较LAGRQ的时间戳和接收LAGRP的时间，可以在发送LAGRQ的对等方上计算两个对等方之间的延迟。
This message does not require any IEs.
此消息不需要任何IEs。
A LAGRP is a lag reply, sent in response to a LAGRQ message. It MUST send the same time-stamp it received in the LAGRQ after passing the received frame through any jitter buffer the peer has configured.
LAGRP是响应LAGRQ消息而发送的滞后回复。在通过对等方配置的任何抖动缓冲区传递接收到的帧之后，它必须发送它在LAGRQ中接收到的相同时间戳。
This message does not require any IEs.
此消息不需要任何IEs。
Digit Dialing support is an optional portion of the IAX protocol designed to support devices that do not maintain their own dial plans, for instance, analog telephone adapters, or ATAs. The dialing portion of the IAX protocol MAY be implemented for the client/ phone-side, server-side or not all. The exchanges work as a series
数字拨号支持是IAX协议的可选部分，旨在支持不维护自己拨号计划的设备，例如模拟电话适配器或ATA。IAX协议的拨号部分可以针对客户端/电话端、服务器端或并非全部实现。这些交易所是一系列的
of Dialing Plan requests (DPREQs) each followed by a response (DPREP) indicating if additional digits SHOULD be collected before sending the call. The sections that follow describe these messages and the rules associated with them.
一组拨号计划请求（DPREQ），每个请求后面都有一个响应（DPREP），指示在发送呼叫之前是否应收集其他数字。下面的章节描述了这些消息以及与之相关的规则。
A DPREQ is a request for the server to analyze the passed called number and determine if there is a valid dialing pattern on the remote peer. It MUST include the 'called number' IE to specify what extension is being queried. This command is used in the case where a local peer does not handle its own dialplan/extension switching. The local peer can inquire (as a user dials) how the remote peer perceives the 'called number'. If a DPREP is received indicating that the number is valid, a DIAL MAY be sent.
DPREQ是服务器分析传递的被叫号码并确定远程对等机上是否存在有效拨号模式的请求。它必须包括“被叫号码”，即指定要查询的分机。此命令用于本地对等方不处理自己的拨号计划/分机切换的情况。本地对等方可以查询（当用户拨号时）远程对等方如何感知“被叫号码”。如果收到指示号码有效的DPREP，则可以发送拨号。
This message MAY be sent by the client and MUST be implemented on servers which provide IAX dialing support.
此消息可能由客户端发送，必须在提供IAX拨号支持的服务器上实现。
It MUST include the following Information Element:
它必须包括以下信息元素：
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
+-------------+----------------+----------+----------+
| IE | Section | Status | Comments |
+-------------+----------------+----------+----------+
| Call Number | Section 8.6.20 | Required | |
+-------------+----------------+----------+----------+
A DPREP is a reply to a DPREQ, containing the status of the dialplan entry requested in the 'called number' IE of the DPREQ. It MUST include the 'called number', 'dpstatus', and 'refresh' IEs. The called number is the same one received in the 'called number' IE of the DPREQ. The 'dpstatus' IE contains the status of the dialplan entry referenced by the received called number. The status indicates whether the called number exists, can exist, needs more digits, or is invalid. More information can be found in Section 8.6 under the DPSTATUS information element. The 'refresh' IE specifies the number of minutes the 'dpstatus' is valid. If the 'refresh' IE is not present, a default 10 minutes period is assumed.
DPREP是对DPREQ的回复，包含在DPREQ的“被叫号码”IE中请求的拨号计划条目的状态。它必须包括“被叫号码”、“dpstatus”和“refresh”IEs。被叫号码与DPREQ的“被叫号码”IE中接收到的号码相同。“dpstatus”IE包含收到的被叫号码所引用的拨号计划条目的状态。状态指示被叫号码是否存在、是否可以存在、是否需要更多数字或是否无效。更多信息可在第8.6节的DPSTATUS信息元素下找到。“刷新”IE指定“dpstatus”有效的分钟数。如果“刷新”IE不存在，则默认为10分钟。
The sending of this message MUST be implemented by servers which support IAX dialing. Clients which support IAX dialing MUST be capable of receiving such messages.
此消息的发送必须由支持IAX拨号的服务器实现。支持IAX拨号的客户端必须能够接收此类消息。
It MUST include the following Information Elements:
它必须包括以下信息元素：
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Call | Section 8.6.20 | Required | |
| Number | | | |
| | | | |
| Dial | Section 8.6.20 | Required | Indicates if number |
| Plan | | | exists, is a partial |
| Status | | | match, etc. |
| | | | |
| Dial | Section 8.6.20 | Optional | Inclusion is strongly |
| Plan | | | suggested. The default is |
| Refresh | | | 10 minutes. |
+----------+----------------+----------+----------------------------+
+----------+----------------+----------+----------------------------+
| IE | Section | Status | Comments |
+----------+----------------+----------+----------------------------+
| Call | Section 8.6.20 | Required | |
| Number | | | |
| | | | |
| Dial | Section 8.6.20 | Required | Indicates if number |
| Plan | | | exists, is a partial |
| Status | | | match, etc. |
| | | | |
| Dial | Section 8.6.20 | Optional | Inclusion is strongly |
| Plan | | | suggested. The default is |
| Refresh | | | 10 minutes. |
+----------+----------------+----------+----------------------------+
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).
拨号消息用于不维护自己的拨号计划/分机路由的IAX对等方。一个或多个DPREQ/DPREP交换机验证分机后，可以在拨号消息中拨打该号码，使用“被叫号码”IE指定其试图到达的分机。然后，远程对等方处理呼叫设置的其余方面，包括按与新命令相同的要求拨打分机并在应答时通知本地对等方（第6.2.2节）。
The following table specifies the IEs used by this message:
下表指定了此消息使用的IEs：
+-----------+---------------+----------+----------------------------+
| IE | Section | Status | Comments |
+-----------+---------------+----------+----------------------------+
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Called | Section 8.6.5 | Optional | Use this IE if context is |
| Context | | | other than default. |
+-----------+---------------+----------+----------------------------+
+-----------+---------------+----------+----------------------------+
| IE | Section | Status | Comments |
+-----------+---------------+----------+----------------------------+
| Called | Section 8.6.1 | Required | |
| Number | | | |
| | | | |
| Called | Section 8.6.5 | Optional | Use this IE if context is |
| Context | | | other than default. |
+-----------+---------------+----------+----------------------------+
An ACK acknowledges the receipt of an IAX message. An ACK is sent upon receipt of a Full Frame that does not have any other protocol-defined response. An ACK MUST have both a source call number and destination call number. It MUST also not change the sequence number
ACK确认收到IAX消息。在接收到没有任何其他协议定义响应的完整帧时发送ACK。ACK必须同时具有源呼叫号码和目标呼叫号码。也不得更改序列号
counters, and MUST return the same time-stamp it received. This time-stamp allows the originating peer to determine to which message the ACK is responding. Receipt of an ACK requires no action.
计数器，并且必须返回与接收到的时间戳相同的时间戳。此时间戳允许发起对等方确定ACK响应的消息。接收确认无需任何操作。
An ACK MAY also be sent as an initial acknowledgment of an IAX message that requires some other protocol-defined message acknowledgment, as long as the required message is also sent within some peer-defined amount of time. This allows the acknowledging peer to delay transmission of the proper IAX message, which may add security against brute-force password attacks during authentication exchanges.
ACK也可以作为IAX消息的初始确认发送，该IAX消息需要一些其他协议定义的消息确认，只要所需的消息也在一些对等方定义的时间内发送。这允许确认的对等方延迟正确的IAX消息的传输，这可能会在身份验证交换期间增加对暴力密码攻击的安全性。
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.
当收到以下消息时，必须发送ACK：新建、挂断、拒绝、接受、PONG、AUTHREP、REGREL、REGACK、REGREJ、TXREL。任何对等方都不应期望ACK，它们的目的纯粹是强制传输层更新。
The ACK message does not requires any IEs.
ACK消息不需要任何IEs。
An INVAL is sent as a response to a received message that is not valid. This occurs when an IAX peer sends a message on a call after the remote peer has hung up its end. Upon receipt of an INVAL, a peer MUST destroy its side of a call.
INVAL作为对接收到的无效消息的响应发送。当IAX对等方在远程对等方挂断其终端后在呼叫中发送消息时，就会发生这种情况。收到无效呼叫后，对等方必须销毁其呼叫端。
The INVAL message does not requires any IEs.
INVAL消息不需要任何IEs。
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.
当接收到的消息顺序不正确时，会发送VNAK，特别是当在呼叫的第一个完整语音帧之前接收到一个小帧时。这是对已丢弃消息的重新传输的请求。如果收到的iseqno与预期的iseqno不同，则认为消息顺序不正确。在接收到VNAK时，对等方必须重新传输序列号高于VNAK消息iseqno的所有帧。
The VNAK message does not requires any IEs.
VNAK消息不需要任何IEs。
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.
MWI消息用于向远程对等方指示它有一条或多条消息等待。它可能包括“msgcount”IE以指定有多少消息正在等待。
The following table specifies IEs used by this message:
下表指定了此消息使用的IEs：
+----------+----------------+----------+-----------+
| IE | Section | Status | Comments |
+----------+----------------+----------+-----------+
| MSGCOUNT | Section 8.6.23 | Optional | Suggested |
+----------+----------------+----------+-----------+
+----------+----------------+----------+-----------+
| IE | Section | Status | Comments |
+----------+----------------+----------+-----------+
| MSGCOUNT | Section 8.6.23 | Optional | Suggested |
+----------+----------------+----------+-----------+
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.
发送不支持消息以响应IAX对等方不支持的消息。当接收到具有无法识别或不支持的子类的IAX命令时，会发生这种情况。收到此消息后无需执行任何操作，但对等方应意识到远程对等方不支持可选包含的“IAX未知”IE中引用的消息。
The following table specifies IEs used by this message:
下表指定了此消息使用的IEs：
+---------+----------------+----------+-----------+
| IE | Section | Status | Comments |
+---------+----------------+----------+-----------+
| UNKNOWN | Section 8.6.22 | Optional | Suggested |
+---------+----------------+----------+-----------+
+---------+----------------+----------+-----------+
| IE | Section | Status | Comments |
+---------+----------------+----------+-----------+
| UNKNOWN | Section 8.6.22 | Optional | Suggested |
+---------+----------------+----------+-----------+
The IAX protocol supports many types of media and these are transported through the same UDP port as other IAX messages. Voice and video are unique in that they utilize two different encodings, each with different support procedures. Abbreviated 'Mini Frames' are normally used for audio and video; however, each time the time-stamp is a multiple of 32,768 (0x8000 hex), a standard or 'Full Frame' MUST be sent. This approach facilitates efficiency and reliability by sending compressed packets, without guaranteed delivery, most of the time while periodically forcing reliable exchanges with the peer. If communication fails, call tear-down procedures are invoked.
IAX协议支持多种类型的媒体，这些媒体通过与其他IAX消息相同的UDP端口传输。语音和视频的独特之处在于它们使用两种不同的编码，每种编码都有不同的支持程序。缩写的“迷你帧”通常用于音频和视频；但是，每次时间戳是32768（0x8000十六进制）的倍数时，必须发送标准帧或“完整帧”。这种方法通过发送压缩数据包来提高效率和可靠性，在大多数情况下不保证传输，同时定期强制与对等方进行可靠交换。如果通信失败，调用调用中断过程。
Upon receiving any media message, except the abbreviated audio and video Mini Frames, an ACK message MUST be sent. The content SHOULD be passed to an associated application, device, or call leg. The data MAY be buffered before it is presented to the user.
在收到任何媒体消息时，除了简短的音频和视频小帧外，必须发送ACK消息。内容应传递给相关的应用程序、设备或呼叫分支。数据在呈现给用户之前可以被缓冲。
The message carries a single digit of DTMF (Dual Tone Multi-Frequency). Useful background information about DTMF can be found in [RFC4733] and [RFC4734], but, note that IAX does not use the RTP protocol.
该信息携带一位DTMF（双音多频）。有关DTMF的有用背景信息可在[RFC4733]和[RFC4734]中找到，但请注意，IAX不使用RTP协议。
The message carries voice data and indicates the CODEC used.
该消息携带语音数据并指示使用的编解码器。
The frame carries video data and indicates the video format of the data.
帧承载视频数据并指示数据的视频格式。
The frame carries a text message in UTF-8 [RFC3629] format.
框架承载UTF-8[RFC3629]格式的文本消息。
This message carries a single image. The image MUST fit in one message in this version of the protocol.
这条信息只包含一个图像。映像必须适合此协议版本中的一条消息。
The HTML message class carries HTML and related data as well as status about the display of that HTML page. The subclass parameter indicates the HTML content type. It MAY be a URL, the start, middle, or end of a data block. HTML data MUST be in the format described in [html401].
HTML消息类携带HTML和相关数据，以及关于HTML页面显示的状态。subclass参数指示HTML内容类型。它可以是URL、数据块的开始、中间或结束。HTML数据必须采用[html401]中描述的格式。
If a peer receives an HTML message for a channel that does not support HTML, it MUST respond with an HTML message that has the HTML NOT SUPPORTED indication.
如果对等方接收到不支持HTML的频道的HTML消息，则必须使用带有HTML不支持指示的HTML消息进行响应。
When a device that supports HTML completes loading the page, it SHOULD send a LOAD COMPLETE message
当支持HTML的设备完成加载页面时，它应该发送一条加载完成消息
This message indicates that comfort noise SHOULD be played. It has a parameter that indicates the level. The noise is to be locally generated.
此消息表示应播放舒适噪音。它有一个指示级别的参数。噪声是局部产生的。
IAX is sent over UDP and uses an application-level protocol to provide reliable transport where needed.
IAX通过UDP发送，并使用应用程序级协议在需要时提供可靠的传输。
With respect to transport, there are two message formats: reliable or 'Full Frames' and unacknowledged 'Mini' or 'Meta' frames. All messages except certain voice and video messages are reliable. Reliable messages are transported by a scheme that maintains message
关于传输，有两种消息格式：可靠或“完整帧”和未确认的“迷你”或“元”帧。除某些语音和视频信息外，所有信息都是可靠的。可靠的消息由维护消息的方案传输
counts and time-stamps for both peers involved in the call. The counts are per call. Each peer maintains a timer for all reliable messages and MUST periodically retransmit those messages until they acknowledge or the retry limit is exceeded.
参与呼叫的两个对等方的计数和时间戳。每次通话的次数为。每个对等方为所有可靠消息维护一个计时器，并且必须定期重新传输这些消息，直到它们确认或超过重试限制。
When starting a call, the outgoing and incoming message sequence numbers MUST both be set to zero. Each reliable message that is sent increments the message count by one except the ACK, INVAL, TXCNT, TXACC, and VNAK messages, which do not change the message count. The message includes the outgoing message count and the highest numbered incoming message that has been received. In addition, it contains a time-stamp that represents the number of milliseconds since the call started. Or, in the case of certain network timing messages, it contains a copy of the time-stamp sent to it. Time-stamps MAY be approximate, but, MUST be in order.
开始呼叫时，传出和传入的消息序列号必须都设置为零。除了ACK、INVAL、TXCNT、TXACC和VNAK消息外，发送的每个可靠消息都会将消息计数增加1，这些消息不会更改消息计数。该消息包括传出消息计数和已接收的编号最高的传入消息。此外，它还包含一个时间戳，表示自调用启动以来的毫秒数。或者，对于某些网络定时消息，它包含发送给它的时间戳的副本。时间戳可能是近似值，但必须是有序的。
When any message is received, the time-stamps MUST be checked to make sure that they are in order. If a message is received out of order, it MUST be ignored and a VNAK message sent to resynchronize the peers. If the message is a reliable message, the incoming message counter MUST be used to acknowledge all the messages up to that sequence number that have been sent.
当收到任何消息时，必须检查时间戳，以确保它们是有序的。如果收到的消息顺序不正确，则必须忽略该消息，并发送VNAK消息以重新同步对等方。如果消息是可靠消息，则必须使用传入消息计数器确认已发送的序列号之前的所有消息。
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.
如果在本地配置的重试次数（默认值4）后未收到确认，则应认为呼叫分支不可用，并且必须在该呼叫分支上没有任何进一步交互的情况下中断呼叫。
IAX allows multiple media exchanges between the same two peers to be multiplexed into a single trunk call coalescing media payload into a combined packet. This decreases bandwidth usage as there are fewer total packets being transmitted. Trunking MAY occur in one or both directions of an IAX exchange. A trunk consists of a trunk header and one or more trunked IAX calls. The trunk message contains a time-stamp specifying the time of transmission of the trunk frame. The audio data from the trunked calls are encapsulated in the trunk frame following the header. Each trunked call consists of two octets specifying the call's source number, two octets specifying the length in octets of the media data, and the media data itself. IAX permits transmitting the time-stamps of each encapsulated Mini Frame as well, so that accurate timing information can be used for jitter buffers, etc. A flag in the meta command header specifies whether the encapsulated Mini Frames retain their original time-stamps. If they do not retain them, they MUST assume the time-stamp in the trunk header upon being received by the trunk peer.
IAX允许同两个对等方之间的多个媒体交换被多路复用到单个中继呼叫中，将媒体负载合并到一个组合数据包中。这减少了带宽使用，因为传输的数据包总数较少。中继可能发生在IAX交换机的一个或两个方向上。中继由中继头和一个或多个中继IAX呼叫组成。中继消息包含指定中继帧传输时间的时间戳。来自中继呼叫的音频数据封装在报头后面的中继帧中。每个集群呼叫由两个八位字节组成，指定呼叫的源号码，两个八位字节指定媒体数据的长度（以八位字节为单位），以及媒体数据本身。IAX还允许传输每个封装的小帧的时间戳，以便准确的定时信息可用于抖动缓冲器等。meta命令头中的标志指定封装的小帧是否保留其原始时间戳。如果它们没有保留它们，则必须在中继对等方接收时在中继报头中使用时间戳。
There are various timers in the IAX protocol. There are other application-level timers, such as the call timer and ring timer, that are beyond the scope of this document. This section describes the IAX timers and specifies their default values and behaviors.
IAX协议中有各种定时器。还有其他应用程序级计时器，如呼叫计时器和响铃计时器，超出了本文档的范围。本节介绍IAX计时器并指定其默认值和行为。
The message retransmission procedures are described in Section 7. On each call, there is a timer for how long to wait for an acknowledgment of a message. This timer starts at twice the measured Round-Trip Time from the last PING/PONG command. If a retransmission is needed, it is exponentially increased until it meets a boundary value. The maximum retry time period boundary is 10 seconds.
第7节描述了消息重传过程。在每次呼叫中，都有一个计时器，用于等待消息确认的时间。该计时器从最后一个乒乓球命令开始测量往返时间的两倍开始。如果需要重新传输，它将以指数方式增加，直到满足边界值。最大重试时间段边界为10秒。
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.
注册在指定的时间段内有效。客户有责任在期限到期前更新此注册。应以随机间隔更新注册，以防止网络拥塞。如果客户/注册人在计时器过期之前未更新其注册，注册人必须监控此时间段并使注册无效。
IAX is very well suited to operating behind NAT due to its single port approach. This approach eliminates any start of call media stream delays while the NAT gateway establishes a bidirectional port association. Deploying a single IAX server behind a NAT gateway requires little effort. If the server acts as a registrar, the IAX UDP port on the NAT gateway must be forwarded to the server. If the server acts as a registrant, the default, 60 second, REGREQ refresh timer should be sufficient to maintain a port association in the NAT gateway; however, a static port mapping is preferred.
由于采用单端口方式，IAX非常适合在NAT后面运行。这种方法消除了NAT网关建立双向端口关联时任何呼叫开始媒体流延迟。在NAT网关后面部署单个IAX服务器只需很少的工作。如果服务器充当注册器，则NAT网关上的IAX UDP端口必须转发到服务器。如果服务器充当注册者，默认的60秒REGREQ刷新计时器应足以维持NAT网关中的端口关联；但是，静态端口映射是首选。
If multiple servers are to be deployed behind a single NAT gateway, most NAT gateways require each IAX server to use different UDP ports. Of course, there may be NAT implementations that recognize when multiple devices utilize the same private port and manage it appropriately.
如果要在单个NAT网关后面部署多个服务器，大多数NAT网关要求每个IAX服务器使用不同的UDP端口。当然，可能存在NAT实现，可以识别多个设备何时使用同一个专用端口并对其进行适当管理。
IAX supports call encryption using the symmetric key, Rijndael [AES] block cipher (also called AES -- Advanced Encryption Standard). Rijndael is a 128-bit block cipher utilizing a shared secret. IAX encrypts on a call-by-call basis starting with a plaintext NEW message indicating, in addition to the other message parameters, that the call should be encrypted. This indication is given by sending the ENCRYPTION IE (Section 8.6.34) in the NEW request message. If the called host supports encryption, it will respond with a plaintext AUTHREQ message that also includes the ENCRYPTION IE. All subsequent messages in the call MUST be encrypted. If the called host does not support encryption, the AUTHREQ sent in response to the NEW must not include the ENCRYPTION IE and the calling host MUST either HANGUP the request or continue with the unencrypted call.
IAX支持使用对称密钥Rijndael[AES]分组密码（也称为AES——高级加密标准）进行呼叫加密。Rijndael是一种利用共享秘密的128位分组密码。IAX以逐个调用的方式进行加密，从明文新消息开始，除了其他消息参数外，还指示应加密该调用。通过在新请求消息中发送加密IE（第8.6.34节）给出该指示。如果被调用的主机支持加密，它将以明文AUTHREQ消息响应，该消息还包括加密，即调用中的所有后续消息都必须加密。如果被调用主机不支持加密，则响应新请求而发送的AUTHREQ不得包含加密IE，并且调用主机必须挂断请求或继续进行未加密的调用。
The key to use in encrypting the messages is computed by taking the CHALLENGE IE Section 8.6.14 from the AUTHREQ and concatenating any one of the shared passwords then computing the 128-bit MD5 digest of this combination. To decrypt, if there is more than one password for the peer, each must be tried until the message is successfully decoded. The key remains constant for the duration of the call. Only the data portion of the messages are encoded.
通过从AUTHREQ中获取质询IE第8.6.14节并连接任何一个共享密码，然后计算该组合的128位MD5摘要，计算用于加密消息的密钥。要解密，如果对等方有多个密码，则必须尝试每个密码，直到消息成功解码。该键在通话期间保持不变。仅对消息的数据部分进行编码。
This section contains the specification for each type of frame that IAX defines.
本节包含IAX定义的每种帧类型的规范。
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).
全帧可以发送信令或媒体数据。通常，全帧用于控制IAX调用的启动、设置和终止，但它们也可用于传输流数据（尽管这通常不是最优的）。
Full Frames are sent reliably, so all Full Frames require an immediate acknowledgment upon receipt. This acknowledgment can be explicit via an 'ACK' message (see Section 8.4) or implicit based upon receipt of an appropriate response to the Full Frame issued.
完整的帧被可靠地发送，因此所有完整的帧在收到时都需要立即确认。该确认可以通过“确认”消息（见第8.4节）明确表示，也可以基于收到对发出的完整帧的适当响应而隐式表示。
The standard Full Frame header length is 12 octets.
标准的全帧标头长度为12个八位字节。
Field descriptions:
字段说明：
'F' bit
“F”位
This bit specifies whether or not the frame is a Full Frame. If the 'F' bit is set to 1, the frame is a Full Frame. If it is set to 0, it is not a Full Frame.
此位指定帧是否为完整帧。如果“F”位设置为1，则帧为完整帧。如果设置为0，则它不是完整帧。
Source call number
来源电话号码
This 15-bit value specifies the call number the transmitting client uses to identify this call. The source call number for an active call MUST NOT be in use by another call on the same client. Call numbers MAY be reused once a call is no longer active, i.e., either when there is positive acknowledgment that the call has been destroyed or when all possible timeouts for the call have expired.
此15位值指定传输客户端用于标识此呼叫的呼叫号码。同一客户端上的另一个呼叫不得使用活动呼叫的源呼叫号码。一旦呼叫不再处于活动状态，即，当有肯定的确认呼叫已被破坏或呼叫的所有可能超时已过期时，可以重新使用呼叫号码。
'R' bit
“R”位
This bit specifies whether or not the frame is being retransmitted. If the 'R' bit is set to 0, the frame is being transmitted for the first time. If it is set to 1, the frame is being retransmitted. IAX does not specify a retransmit timeout; this is left to the implementor.
This bit specifies whether or not the frame is being retransmitted. If the 'R' bit is set to 0, the frame is being transmitted for the first time. If it is set to 1, the frame is being retransmitted. IAX does not specify a retransmit timeout; this is left to the implementor.translate error, please retry
Destination call number
目的地呼叫号码
This 15-bit value specifies the call number the transmitting client uses to reference the call at the remote peer. This number is the same as the remote peer's source call number. The destination call number uniquely identifies a call on the remote peer. The source call number uniquely identifies the call on the local peer.
此15位值指定传输客户端用于引用远程对等方的呼叫的呼叫号码。此号码与远程对等方的源呼叫号码相同。目标呼叫号码唯一标识远程对等方上的呼叫。源呼叫号码唯一标识本地对等方的呼叫。
Time-stamp
时间戳
The time-stamp field contains a 32-bit time-stamp maintained by an IAX peer for a given call. The time-stamp is an incrementally increasing representation of the number of milliseconds since the first transmission of the call.
时间戳字段包含由IAX对等方为给定调用维护的32位时间戳。时间戳是自调用第一次传输以来毫秒数的增量表示。
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.
8位OSeqno字段是出站流序列号。调用初始化时，其值为0。当发送完整帧时，它会递增。当计数器溢出时，它会自动重置为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.
8位ISeqno字段是入站流序列号。调用初始化时，其值为0。它随着接收到完整帧而递增。在任何时候，调用的ISeqno表示下一个预期的入站流序列号。当计数器溢出时，它会自动重置为0。
Frametype
框架类型
The Frametype field identifies the type of message carried by the frame. See Section 8.2 for more information.
Frametype字段标识帧携带的消息类型。更多信息请参见第8.2节。
'C' bit
C形钻头
This bit determines how the remaining 7 bits of the Subclass field are coded. If the 'C' bit is set to 1, the Subclass value is interpreted as a power of 2. If it is not set, the Subclass value is interpreted as a simple 7-bit unsigned integer.
该位确定子类字段的其余7位的编码方式。如果“C”位设置为1，则子类值被解释为2的幂。如果未设置，则子类值将解释为简单的7位无符号整数。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSeqno | ISeqno | Frame Type |C| Subclass |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSeqno | ISeqno | Frame Type |C| Subclass |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Full Frame Binary Format
图5：全帧二进制格式
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
迷你帧之所以如此命名，是因为它们的头是最小的4个八位字节。微型帧不携带控制或信号数据；他们的唯一目的是在已经建立的IAX呼叫上传输媒体流。它们被不可靠地发送。之所以做出这一决定，是因为VoIP呼叫通常会错过多个帧，而不会显著降低呼叫质量，同时为确保可靠性而产生的开销会增加带宽需求并降低吞吐量。更进一步，因为
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
“F”位
Mini Frames MUST have the 'F' bit set to 0 to specify that they are not Full Frames.
迷你帧的“F”位必须设置为0，以指定它们不是完整帧。
Source call number
来源电话号码
The source call number is the number that is used by the transmitting peer to identify the current call.
源呼叫号码是发送对等方用来识别当前呼叫的号码。
time-stamp
时间戳
Mini frames carry a 16-bit time-stamp, which is the lower 16 bits of the transmitting peer's full 32-bit time-stamp for the call. The time-stamp allows synchronization of incoming frames so that they MAY be processed in chronological order instead of the (possibly different) order in which they are received. The 16-bit time-stamp wraps after 65.536 seconds, at which point a full frame SHOULD be sent to notify the remote peer that its time-stamp has been reset. A call MUST continue to send mini frames starting with time-stamp 0 even if acknowledgment of the resynchronization is not received.
迷你帧携带16位时间戳，这是传输对等方呼叫的完整32位时间戳的较低16位。时间戳允许同步传入帧，以便可以按时间顺序处理它们，而不是按接收它们的顺序（可能不同）。16位时间戳在65.536秒后结束，此时应发送完整帧以通知远程对等方其时间戳已重置。即使未收到重新同步的确认，调用也必须继续发送从时间戳0开始的小帧。
The F bit, source call number, and 16-bit time-stamp comprise the entire 4-octet header for a full frame. Following this header is the actual stream data, of arbitrary length, up to the maximum supported by the network.
F位、源呼叫号码和16位时间戳构成完整帧的整个4-octet报头。此标头后面是实际的流数据，长度任意，最大可达网络支持的最大值。
Mini frames are implicitly defined to be of type 'voice frame' (frametype 2; see Section 8.2). The subclass is implicitly defined by the most recent full voice frame of a call (i.e. the subclass for a voice frame specifies the CODEC used with the stream). The first voice frame of a call SHOULD be sent using the CODEC agreed upon in the initial CODEC negotiation. On-the-fly CODEC negotiation is permitted by sending a full voice frame specifying the new CODEC to use in the subclass field.
迷你帧隐式定义为“语音帧”类型（帧类型2；见第8.2节）。子类由呼叫的最新完整语音帧隐式定义（即，语音帧的子类指定流使用的编解码器）。呼叫的第一个语音帧应使用初始编解码器协商中商定的编解码器发送。通过在子类字段中发送指定要使用的新编解码器的完整语音帧，允许动态编解码器协商。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source call number | time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source call number | time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Mini Frame Binary Format
图6：迷你帧二进制格式
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.
元框架有两个用途。元视频帧允许传输具有优化报头的视频流。它们的用途与迷你语音框相似。元中继帧用于将两个对等方之间的多个IAX媒体流中继到一个报头中，以进一步减少带宽消耗。
Field descriptions:
字段说明：
'F' bit
“F”位
Meta video frames MUST have the 'F' bit set to 0 to indicate that they are not full frames.
元视频帧的“F”位必须设置为0，以指示它们不是完整帧。
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).
元指示符是一个全零的15位字段，用于指示帧是元帧。元帧是可识别的，因为在任何元帧中，前16位始终为零，而完整或迷你帧将设置“F”位或源呼叫号码的某些（非零）值（或两者）。
'V' bit
V形钻头
The 'V' bit in a meta video frame is set to 1 to specify that the frame is a meta video frame.
元视频帧中的“V”位设置为1，以指定该帧为元视频帧。
Source call number
来源电话号码
The call number that is used by the transmitting peer to identify this video call.
传输对等方用于标识此视频呼叫的呼叫号码。
time-stamp
时间戳
Meta video frames carry a 16-bit time-stamp, which is the lower 16 bits of the transmitting peer's full 32-bit time-stamp for the call. When this time-stamp wraps, a Full Frame SHOULD be sent to notify the remote peer that the time-stamp has been reset to 0.
元视频帧携带16位时间戳，这是传输对等方呼叫的完整32位时间戳的较低16位。当此时间戳结束时，应发送完整帧以通知远程对等方时间戳已重置为0。
Following the time-stamp is the actual video stream data. Meta video frames are implicitly defined to be of type 'video frame' (frametype 3; see Section 8.2). The video CODEC used is implicitly defined by the subclass of the most recent full video frame of a call.
时间戳之后是实际的视频流数据。元视频帧隐式定义为“视频帧”类型（帧类型3；见第8.2节）。使用的视频编解码器由调用的最新完整视频帧的子类隐式定义。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|?| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|?| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Meta Video Frame Binary Format
图7：元视频帧二进制格式
IAX natively supports two methods of trunking multiple media streams between two peers into a single association. The first method sends a standard meta header, along with a single 32-bit time-stamp describing the transmission time of the trunk frame. Following the time-stamp are one or more media frames consisting of the call number and the length in octets of the stream data included in the frame.
IAX本机支持两种将两个对等方之间的多个媒体流中继到单个关联中的方法。第一种方法发送一个标准元报头，以及一个描述中继帧传输时间的32位时间戳。时间戳之后是一个或多个媒体帧，由帧中包括的流数据的呼叫号码和长度（以八位字节为单位）组成。
The second method of trunking is very similar to the first. It sends a standard meta header, including the 32-bit time-stamp describing the time of transmission of the trunk frame. But the media frames included in the trunk are actually complete Mini Frames, including the 16-bit time-stamp for each call. The first method uses slightly less bandwidth (2 fewer octets per call in the trunk), while the second method maintains the individual time-stamps for each call so that jitter buffering can use the actual time-stamps associated with a call instead of the (less accurate) time-stamp representing the entire trunk. Either method is permissible for trunking.
第二种中继方法与第一种非常相似。它发送一个标准元报头，包括描述中继帧传输时间的32位时间戳。但是中继中包含的媒体帧实际上是完整的迷你帧，包括每个呼叫的16位时间戳。第一种方法使用的带宽稍小（中继中每个呼叫少2个八位字节），而第二种方法为每个呼叫维护单独的时间戳，以便抖动缓冲可以使用与呼叫相关联的实际时间戳，而不是代表整个中继的（不太准确的）时间戳。任何一种方法都可用于中继。
Field descriptions:
字段说明：
'F' bit
“F”位
Meta trunk frames MUST have the 'F' bit set to 0 to indicate that they are not Full Frames.
元中继帧的“F”位必须设置为0，以指示它们不是完整帧。
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).
元指示符是一个全零的15位字段，用于指示帧是元帧。元帧是可识别的，因为在任何元帧中，前16位始终为零，而完整或迷你帧将设置“F”位或源呼叫号码的某些（非零）值（或两者）。
'V' bit
V形钻头
The 'V' bit in a meta trunk frame is set to 0 to specify that the frame is not a meta video frame.
元中继帧中的“V”位设置为0，以指定该帧不是元视频帧。
Meta Command
元命令
This 7-bit field identifies whether or not the Meta Frame is a trunk. A value of '1' indicates that the frame is a meta trunk frame. All other values are reserved for future use. See the IANA Registry for additional IAX Meta Command Assignments.
此7位字段标识元帧是否为主干。值“1”表示该帧是元中继帧。所有其他值保留供将来使用。有关其他IAX Meta命令分配，请参阅IANA注册表。
Command Data
命令数据
This 8-bit field specifies flags for options that apply to a trunked call. The least significant bit of the field is the 'trunk time-stamps' flag. A value of 0 indicates that the calls in the trunk do not include their individual time-stamps. A value of 1 indicates that the calls do each include their own time-stamp. All other bits are reserved for future use.
此8位字段指定适用于中继呼叫的选项的标志。字段的最低有效位是“中继时间戳”标志。值为0表示中继中的呼叫不包括各自的时间戳。值为1表示每个调用都包含自己的时间戳。所有其他位保留供将来使用。
time-stamp
时间戳
Meta trunk frames carry a 32-bit time-stamp, which represents the actual time of transmission of the trunk frame. This is distinct from the time-stamps of the calls included in the trunk.
元中继帧带有32位时间戳，表示中继帧的实际传输时间。这与中继中包含的呼叫的时间戳不同。
Following the 32-bit time-stamp is one or more trunked calls. If the 'trunk time-stamps' flag is set to 0, each entry consists of 2 octets specifying the source call number of the call, 2 octets specifying the length in octets of the media data, and then the media data. If the 'trunk time-stamps' flag is set to 1, each entry consists of 2
32位时间戳之后是一个或多个集群呼叫。如果“中继时间戳”标志设置为0，则每个条目由2个八位字节组成，指定呼叫的源呼叫号码，2个八位字节指定媒体数据的长度（以八位字节为单位），然后是媒体数据。如果“中继时间戳”标志设置为1，则每个条目由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 time-stamp, and the media data). The following two diagrams help illustrate this structure.
八位字节指定媒体数据的长度（以八位字节为单位），然后是一个小帧（两个八位字节指定源呼叫号码，两个八位字节指定16位时间戳，以及媒体数据）。以下两个图有助于说明此结构。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V|Meta Command | Cmd Data (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V|Meta Command | Cmd Data (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Source Call Number | Data Length (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Meta Trunk Frame Binary Format (trunk time-stamps 0)
图8：元中继帧二进制格式（中继时间戳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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Meta Indicator |V|Meta Command | Cmd Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length (in octets) |R| Source Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time-stamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Data |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Meta Trunk Frame Binary Format (trunk time-stamps 1)
图9：元中继帧二进制格式（中继时间戳1）
All of the above frames may be encrypted. The header call numbers are passed through in the clear, first 4 bytes for a Full Frame or 2 bytes for a Mini Frame. The remainder of the frame is padded with between 16 and 32 bytes of random data, then encrypted with AES each block being XOR'd with the previous block. The padding is added at the front of the data.
可以对上述所有帧进行加密。报头呼叫号码以明文形式传递，完整帧的前4个字节或迷你帧的前2个字节。帧的其余部分用16到32字节的随机数据填充，然后用AES加密，每个块与前一个块异或。填充添加在数据的前面。
Figure 10 shows a padded Full Frame before encryption, and Figure 11 shows the frame after encryption. Other frame types follow the same procedure, except the cleartext portion is shorter, as described above.
图10显示加密前的填充完整帧，图11显示加密后的帧。其他帧类型遵循相同的过程，除了明文部分较短，如上所述。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 Random bytes |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 Random bits |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: between 0 and 15 (as indicated by the padding field above) :
: Random bytes :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Remainder of Actual Frame :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 Random bytes |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 28 Random bits |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: between 0 and 15 (as indicated by the padding field above) :
: Random bytes :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Remainder of Actual Frame :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Full Frame before encryption
图10：加密前的完整帧
Since AES requires a 16 byte block size, some padding is essential. This padding has been placed at the beginning of the payload because it makes it more difficult to take advantage of the predictability of the IAX frame header. For example, the first encrypted Frame an IAX client sends within an incoming IAX call is entirely predictable: It is always an ACK - where even the time-stamp is guessable as it is the time the AUTHREP packet was sent.
由于AES需要16字节的块大小，一些填充是必需的。此填充已放置在有效负载的开头，因为它使利用IAX帧头的可预测性变得更加困难。例如，IAX客户端在传入的IAX调用中发送的第一个加密帧是完全可预测的：它始终是一个ACK，即使时间戳也是可以猜测的，因为它是AUTHREP数据包发送的时间。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted data |
| Multiple of 16 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Source Call Number |R| Destination Call Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted data |
| Multiple of 16 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Frame after encryption
图11：加密后的帧
The same encryption rules apply to the Mini Frames, except that the initial unencrypted portion is only 2 bytes.
除了初始未加密部分仅为2字节外，相同的加密规则适用于小帧。
The IAX protocol specifies 10 types of possible frames for the "frametype" field of a Full Frame. They are described in the following subsections.
IAX协议为完整帧的“frametype”字段指定了10种可能的帧类型。以下各小节对其进行了描述。
The frame carries a single digit of DTMF (Dual Tone Multi-Frequency). More information about DTMF can be found in RFC 4733 [RFC4733] and [RFC4734].
该帧携带一位DTMF（双音多频）。有关DTMF的更多信息，请参见RFC 4733[RFC4733]和[RFC4734]。
For DTMF frames, the subclass is the actual DTMF digit carried by the frame.
对于DTMF帧，子类是帧携带的实际DTMF数字。
The frame carries voice data.
该帧承载语音数据。
The subclass specifies the audio format of the data. Predefined voice formats can be found in Section 8.7.
子类指定数据的音频格式。预定义的语音格式见第8.7节。
The frame carries video data.
帧承载视频数据。
The subclass specifies the video format of the data. Predefined video formats can be found in Section 8.7.
子类指定数据的视频格式。预定义的视频格式见第8.7节。
The frame carries session control data, i.e., it refers to control of a device connected to an IAX endpoint.
该帧承载会话控制数据，即，它指连接到IAX端点的设备的控制。
The subclass is a value from Section 8.3 describing the device control signal.
子类是第8.3节中描述设备控制信号的值。
Frames with the Null value MUST NOT be transmitted.
不能传输具有空值的帧。
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.
该帧承载提供IAX协议特定端点管理的控制数据。此帧类型用于管理通常独立于端点类型的IAX协议交互。
The subclass is a value from Section 8.4 describing an IAX event.
子类是第8.4节中描述IAX事件的值。
The frame carries a non-control text message in UTF-8 [RFC3629] format.
帧携带UTF-8[RFC3629]格式的非控制文本消息。
All text frames have a subclass of 0.
所有文本框都有一个子类0。
The frame carries a single image.
镜框上只有一个图像。
The subclass describes the format of the image from Section 8.7.
子类描述了第8.7节中的图像格式。
The frame carries HTML data.
框架承载HTML数据。
The subclass is a value from the HTML Subclasses table in Section 8.5.
子类是第8.5节中HTML子类表中的值。
The frame carries comfort noise.
这个框架带有舒适的噪音。
The subclass is the level of comfort noise in -dBov.
子类是-dBov中的舒适噪声级别。
The following table specifies valid Frame Type Values:
下表指定了有效的帧类型值：
+------+-------------+--------------------------+-------------------+
| TYPE | Description | Subclass Description | Data Description |
+------+-------------+--------------------------+-------------------+
| 0x01 | DTMF | 0-9, A-D, *, # | Undefined |
| | | | |
| 0x02 | Voice | Audio Compression Format | Data |
| | | | |
| 0x03 | Video | Video Compression Format | Data |
| | | | |
| 0x04 | Control | See Control Frame Types | Varies with |
| | | | subclass |
| | | | |
| 0x05 | Null | Undefined | Undefined |
| | | | |
| 0x06 | IAX Control | See IAX Protocol | Information |
| | | Messages | Elements |
| | | | |
| 0x07 | Text | Always 0 | Raw Text |
| | | | |
| 0x08 | Image | Image Compression Format | Raw image |
| | | | |
| 0x09 | HTML | See HTML Frame Types | Message Specific |
| | | | |
| 0x0A | Comfort | Level in -dBov of | None |
| | Noise | comfort noise | |
+------+-------------+--------------------------+-------------------+
+------+-------------+--------------------------+-------------------+
| TYPE | Description | Subclass Description | Data Description |
+------+-------------+--------------------------+-------------------+
| 0x01 | DTMF | 0-9, A-D, *, # | Undefined |
| | | | |
| 0x02 | Voice | Audio Compression Format | Data |
| | | | |
| 0x03 | Video | Video Compression Format | Data |
| | | | |
| 0x04 | Control | See Control Frame Types | Varies with |
| | | | subclass |
| | | | |
| 0x05 | Null | Undefined | Undefined |
| | | | |
| 0x06 | IAX Control | See IAX Protocol | Information |
| | | Messages | Elements |
| | | | |
| 0x07 | Text | Always 0 | Raw Text |
| | | | |
| 0x08 | Image | Image Compression Format | Raw image |
| | | | |
| 0x09 | HTML | See HTML Frame Types | Message Specific |
| | | | |
| 0x0A | Comfort | Level in -dBov of | None |
| | Noise | comfort noise | |
+------+-------------+--------------------------+-------------------+
Refer to the IANA Registry for additional IAX Frame Type values.
有关其他IAX帧类型值，请参阅IANA注册表。
The following table specifies valid Control Frame Subclasses:
下表指定了有效的控制框架子类：
+-------------+---------------+-------------------------------------+
| VALUE | Name | Description |
+-------------+---------------+-------------------------------------+
| 0x01 | Hangup | The call has been hungup at the |
| | | remote end |
| | | |
| 0x02 | Reserved | Reserved for future use |
| | | |
| 0x03 | Ringing | Remote end is ringing (ring-back) |
| | | |
| 0x04 | Answer | Remote end has answered |
| | | |
| 0x05 | Busy | Remote end is busy |
| | | |
| 0x06 | Reserved | Reserved for future use |
| | | |
| 0x07 | Reserved | Reserved for future use |
| | | |
| 0x08 | Congestion | The call is congested |
| | | |
| 0x09 | Flash Hook | Flash hook |
| | | |
| 0x0a | Reserved | Reserved for future use |
| | | |
| 0x0b | Option | Device-specific options are being |
| | | transmitted |
| | | |
| 0x0c | Key Radio | Key Radio |
| | | |
| 0x0d | Unkey Radio | Unkey Radio |
| | | |
| 0x0e | Call Progress | Call is in progress |
| | | |
| 0x0f | Call | Call is proceeding |
| | Proceeding | |
| | | |
| 0x10 | Hold | Call is placed on hold |
| | | |
| 0x11 | Unhold | Call is taken off hold |
+-------------+---------------+-------------------------------------+
+-------------+---------------+-------------------------------------+
| VALUE | Name | Description |
+-------------+---------------+-------------------------------------+
| 0x01 | Hangup | The call has been hungup at the |
| | | remote end |
| | | |
| 0x02 | Reserved | Reserved for future use |
| | | |
| 0x03 | Ringing | Remote end is ringing (ring-back) |
| | | |
| 0x04 | Answer | Remote end has answered |
| | | |
| 0x05 | Busy | Remote end is busy |
| | | |
| 0x06 | Reserved | Reserved for future use |
| | | |
| 0x07 | Reserved | Reserved for future use |
| | | |
| 0x08 | Congestion | The call is congested |
| | | |
| 0x09 | Flash Hook | Flash hook |
| | | |
| 0x0a | Reserved | Reserved for future use |
| | | |
| 0x0b | Option | Device-specific options are being |
| | | transmitted |
| | | |
| 0x0c | Key Radio | Key Radio |
| | | |
| 0x0d | Unkey Radio | Unkey Radio |
| | | |
| 0x0e | Call Progress | Call is in progress |
| | | |
| 0x0f | Call | Call is proceeding |
| | Proceeding | |
| | | |
| 0x10 | Hold | Call is placed on hold |
| | | |
| 0x11 | Unhold | Call is taken off hold |
+-------------+---------------+-------------------------------------+
Refer to the IANA Registry for additional IAX Control Frame Subclass values.
有关其他IAX控制框架子类值，请参阅IANA注册表。
Frames of type 'IAX' are used to provide management of IAX endpoints. They handle IAX signaling (e.g., call setup, maintenance, and tear-down). They MAY also handle direct transmission of media data, but this is not optimal for VoIP calls. They do not carry session-specific control (e.g., device state), as this is the purpose of Control Frames. The IAX commands are listed and described below.
“IAX”类型的帧用于提供对IAX端点的管理。它们处理IAX信令（例如，呼叫设置、维护和中断）。它们还可以处理媒体数据的直接传输，但这对于VoIP呼叫来说并不是最佳选择。它们不携带特定于会话的控制（例如，设备状态），因为这是控制帧的目的。下面列出并描述了IAX命令。
The following table specifies all valid IAX Frame values:
下表指定了所有有效的IAX帧值：
+------+-----------+-----------------------------------------+
| Hex | Name | Description |
+------+-----------+-----------------------------------------+
| 0x01 | NEW | Initiate a new call |
| | | |
| 0x02 | PING | Ping request |
| | | |
| 0x03 | PONG | Ping or poke reply |
| | | |
| 0x04 | ACK | Explicit acknowledgment |
| | | |
| 0x05 | HANGUP | Initiate call tear-down |
| | | |
| 0x06 | REJECT | Reject a call |
| | | |
| 0x07 | ACCEPT | Accept a call |
| | | |
| 0x08 | AUTHREQ | Authentication request |
| | | |
| 0x09 | AUTHREP | Authentication reply |
| | | |
| 0x0a | INVAL | Invalid message |
| | | |
| 0x0b | LAGRQ | Lag request |
| | | |
| 0x0c | LAGRP | Lag reply |
| | | |
| 0x0d | REGREQ | Registration request |
| | | |
| 0x0e | REGAUTH | Registration authentication |
| | | |
| 0x0f | REGACK | Registration acknowledgement |
| | | |
| 0x10 | REGREJ | Registration reject |
| | | |
| 0x11 | REGREL | Registration release |
| | | |
+------+-----------+-----------------------------------------+
| Hex | Name | Description |
+------+-----------+-----------------------------------------+
| 0x01 | NEW | Initiate a new call |
| | | |
| 0x02 | PING | Ping request |
| | | |
| 0x03 | PONG | Ping or poke reply |
| | | |
| 0x04 | ACK | Explicit acknowledgment |
| | | |
| 0x05 | HANGUP | Initiate call tear-down |
| | | |
| 0x06 | REJECT | Reject a call |
| | | |
| 0x07 | ACCEPT | Accept a call |
| | | |
| 0x08 | AUTHREQ | Authentication request |
| | | |
| 0x09 | AUTHREP | Authentication reply |
| | | |
| 0x0a | INVAL | Invalid message |
| | | |
| 0x0b | LAGRQ | Lag request |
| | | |
| 0x0c | LAGRP | Lag reply |
| | | |
| 0x0d | REGREQ | Registration request |
| | | |
| 0x0e | REGAUTH | Registration authentication |
| | | |
| 0x0f | REGACK | Registration acknowledgement |
| | | |
| 0x10 | REGREJ | Registration reject |
| | | |
| 0x11 | REGREL | Registration release |
| | | |
| 0x12 | VNAK | Video/Voice retransmit request |
| | | |
| 0x13 | DPREQ | Dialplan request |
| | | |
| 0x14 | DPREP | Dialplan reply |
| | | |
| 0x15 | DIAL | Dial |
| | | |
| 0x16 | TXREQ | Transfer request |
| | | |
| 0x17 | TXCNT | Transfer connect |
| | | |
| 0x18 | TXACC | Transfer accept |
| | | |
| 0x19 | TXREADY | Transfer ready |
| | | |
| 0x1a | TXREL | Transfer release |
| | | |
| 0x1b | TXREJ | Transfer reject |
| | | |
| 0x1c | QUELCH | Halt audio/video [media] transmission |
| | | |
| 0x1d | UNQUELCH | Resume audio/video [media] transmission |
| | | |
| 0x1e | POKE | Poke request |
| | | |
| 0x1f | Reserved | Reserved for future use |
| | | |
| 0x20 | MWI | Message waiting indication |
| | | |
| 0x21 | UNSUPPORT | Unsupported message |
| | | |
| 0x22 | TRANSFER | Remote transfer request |
| | | |
| 0x23 | Reserved | Reserved for future use |
| | | |
| 0x24 | Reserved | Reserved for future use |
| | | |
| 0x25 | Reserved | Reserved for future use |
+------+-----------+-----------------------------------------+
| 0x12 | VNAK | Video/Voice retransmit request |
| | | |
| 0x13 | DPREQ | Dialplan request |
| | | |
| 0x14 | DPREP | Dialplan reply |
| | | |
| 0x15 | DIAL | Dial |
| | | |
| 0x16 | TXREQ | Transfer request |
| | | |
| 0x17 | TXCNT | Transfer connect |
| | | |
| 0x18 | TXACC | Transfer accept |
| | | |
| 0x19 | TXREADY | Transfer ready |
| | | |
| 0x1a | TXREL | Transfer release |
| | | |
| 0x1b | TXREJ | Transfer reject |
| | | |
| 0x1c | QUELCH | Halt audio/video [media] transmission |
| | | |
| 0x1d | UNQUELCH | Resume audio/video [media] transmission |
| | | |
| 0x1e | POKE | Poke request |
| | | |
| 0x1f | Reserved | Reserved for future use |
| | | |
| 0x20 | MWI | Message waiting indication |
| | | |
| 0x21 | UNSUPPORT | Unsupported message |
| | | |
| 0x22 | TRANSFER | Remote transfer request |
| | | |
| 0x23 | Reserved | Reserved for future use |
| | | |
| 0x24 | Reserved | Reserved for future use |
| | | |
| 0x25 | Reserved | Reserved for future use |
+------+-----------+-----------------------------------------+
Refer to the IANA Registry for additional IAX Frame values.
有关其他IAX帧值，请参阅IANA注册表。
IAX HTML Command Subclasses:
IAX HTML命令子类：
+--------+----------------------------+
| NUMBER | DESCRIPTION |
+--------+----------------------------+
| 0x01 | Sending a URL |
| | |
| 0x02 | Data frame |
| | |
| 0x04 | Beginning frame |
| | |
| 0x08 | End frame |
| | |
| 0x10 | Load is complete |
| | |
| 0x11 | Peer does not support HTML |
| | |
| 0x12 | Link URL |
| | |
| 0x13 | Unlink URL |
| | |
| 0x14 | Reject Link URL |
+--------+----------------------------+
+--------+----------------------------+
| NUMBER | DESCRIPTION |
+--------+----------------------------+
| 0x01 | Sending a URL |
| | |
| 0x02 | Data frame |
| | |
| 0x04 | Beginning frame |
| | |
| 0x08 | End frame |
| | |
| 0x10 | Load is complete |
| | |
| 0x11 | Peer does not support HTML |
| | |
| 0x12 | Link URL |
| | |
| 0x13 | Unlink URL |
| | |
| 0x14 | Reject Link URL |
+--------+----------------------------+
Refer to the IANA Registry for additional IAX HTML Command Subclass values.
有关其他IAX HTML命令子类值，请参阅IANA注册表。
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.
作为完整帧发送的IAX消息可能包含指定用户或呼叫特定数据的信息元素。信息元素附加到其数据字段中的帧头。任何IAX消息都可能包含零个、一个或多个信息元素。
Information elements are coded as follows:
信息元素编码如下：
The first octet of any information element consists of the "IE" field. The IE field is an identification number that defines the particular information element. Table 1 lists the defined information elements and each information element is defined below the table.
任何信息元素的第一个八位组由“IE”字段组成。IE字段是定义特定信息元素的标识号。表1列出了定义的信息元素，每个信息元素都在表下方定义。
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 dependent on the particular information element as identified by its "IE" field. Some information elements carry binary data, some carry UTF-8 [RFC3629] data, and some have no data field at all. Elements that carry UTF-8 MUST prepare strings as per [RFC3454] and [RFC3491], so that illegal characters, case folding, and other characters properties are handled and compared properly. The data representation for each information element is described below.
信息元素的剩余八位字节包含正在传输的实际数据。数据的表示取决于由其“IE”字段标识的特定信息元素。有些信息元素携带二进制数据，有些携带UTF-8[RFC3629]数据，有些根本没有数据字段。携带UTF-8的元素必须按照[RFC3454]和[RFC3491]准备字符串，以便正确处理和比较非法字符、大小写折叠和其他字符属性。每个信息元素的数据表示如下所述。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IE | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: DATA :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following is a table of the information elements IAX defines, and a brief description of each information element's purpose. More information about each IE may be found below the table.
以下是IAX定义的信息元素表，以及每个信息元素用途的简要说明。关于每个IE的更多信息可在下表中找到。
+------+----------------+-------------------------------------------+
| HEX | NAME | DESCRIPTION |
+------+----------------+-------------------------------------------+
| HEX | NAME | DESCRIPTION |
| 0x01 | CALLED NUMBER | Number/extension being called |
| 0x02 | CALLING NUMBER | Calling number |
| 0x03 | CALLING ANI | Calling number ANI for billing |
| 0x04 | CALLING NAME | Name of caller |
| 0x05 | CALLED CONTEXT | Context for number |
| 0x06 | USERNAME | Username (peer or user) for |
| | | authentication |
| 0x07 | PASSWORD | Password for authentication |
| 0x08 | CAPABILITY | Actual CODEC capability |
| 0x09 | FORMAT | Desired CODEC format |
| 0x0a | LANGUAGE | Desired language |
| 0x0b | VERSION | Protocol version |
| 0x0c | ADSICPE | CPE ADSI capability |
| 0x0d | DNID | Originally dialed DNID |
| 0x0e | AUTHMETHODS | Authentication method(s) |
| 0x0f | CHALLENGE | Challenge data for MD5/RSA |
| 0x10 | MD5 RESULT | MD5 challenge result |
| 0x11 | RSA RESULT | RSA challenge result |
+------+----------------+-------------------------------------------+
| HEX | NAME | DESCRIPTION |
+------+----------------+-------------------------------------------+
| HEX | NAME | DESCRIPTION |
| 0x01 | CALLED NUMBER | Number/extension being called |
| 0x02 | CALLING NUMBER | Calling number |
| 0x03 | CALLING ANI | Calling number ANI for billing |
| 0x04 | CALLING NAME | Name of caller |
| 0x05 | CALLED CONTEXT | Context for number |
| 0x06 | USERNAME | Username (peer or user) for |
| | | authentication |
| 0x07 | PASSWORD | Password for authentication |
| 0x08 | CAPABILITY | Actual CODEC capability |
| 0x09 | FORMAT | Desired CODEC format |
| 0x0a | LANGUAGE | Desired language |
| 0x0b | VERSION | Protocol version |
| 0x0c | ADSICPE | CPE ADSI capability |
| 0x0d | DNID | Originally dialed DNID |
| 0x0e | AUTHMETHODS | Authentication method(s) |
| 0x0f | CHALLENGE | Challenge data for MD5/RSA |
| 0x10 | MD5 RESULT | MD5 challenge result |
| 0x11 | RSA RESULT | RSA challenge result |
| 0x12 | APPARENT ADDR | Apparent address of peer |
| 0x13 | REFRESH | When to refresh registration |
| 0x14 | DPSTATUS | Dialplan status |
| 0x15 | CALLNO | Call number of peer |
| 0x16 | CAUSE | Cause |
| 0x17 | IAX UNKNOWN | Unknown IAX command |
| 0x18 | MSGCOUNT | How many messages waiting |
| 0x19 | AUTOANSWER | Request auto-answering |
| 0x1a | MUSICONHOLD | Request musiconhold with QUELCH |
| 0x1b | TRANSFERID | Transfer Request Identifier |
| 0x1c | RDNIS | Referring DNIS |
| 0x1d | Reserved | Reserved for future use |
| 0x1e | Reserved | Reserved for future use |
| 0x1f | DATETIME | Date/Time |
| 0x20 | Reserved | Reserved for future use |
| 0x21 | Reserved | Reserved for future use |
| 0x22 | Reserved | Reserved for future use |
| 0x23 | Reserved | Reserved for future use |
| 0x24 | Reserved | Reserved for future use |
| 0x25 | Reserved | Reserved for future use |
| 0x26 | CALLINGPRES | Calling presentation |
| 0x27 | CALLINGTON | Calling type of number |
| 0x28 | CALLINGTNS | Calling transit network select |
| 0x29 | SAMPLINGRATE | Supported sampling rates |
| 0x2a | CAUSECODE | Hangup cause |
| 0x2b | ENCRYPTION | Encryption format |
| 0x2c | ENCKEY | Reserved for future Use |
| 0x2d | CODEC PREFS | CODEC Negotiation |
| 0x2e | RR JITTER | Received jitter, as in RFC 3550 |
| 0x2f | RR LOSS | Received loss, as in RFC 3550 |
| 0x30 | RR PKTS | Received frames |
| 0x31 | RR DELAY | Max playout delay for received frames in |
| | | ms |
| 0x32 | RR DROPPED | Dropped frames (presumably by jitter |
| | | buffer) |
| 0x33 | RR OOO | Frames received Out of Order |
| 0x34 | OSPTOKEN | OSP Token Block |
+------+----------------+-------------------------------------------+
| 0x12 | APPARENT ADDR | Apparent address of peer |
| 0x13 | REFRESH | When to refresh registration |
| 0x14 | DPSTATUS | Dialplan status |
| 0x15 | CALLNO | Call number of peer |
| 0x16 | CAUSE | Cause |
| 0x17 | IAX UNKNOWN | Unknown IAX command |
| 0x18 | MSGCOUNT | How many messages waiting |
| 0x19 | AUTOANSWER | Request auto-answering |
| 0x1a | MUSICONHOLD | Request musiconhold with QUELCH |
| 0x1b | TRANSFERID | Transfer Request Identifier |
| 0x1c | RDNIS | Referring DNIS |
| 0x1d | Reserved | Reserved for future use |
| 0x1e | Reserved | Reserved for future use |
| 0x1f | DATETIME | Date/Time |
| 0x20 | Reserved | Reserved for future use |
| 0x21 | Reserved | Reserved for future use |
| 0x22 | Reserved | Reserved for future use |
| 0x23 | Reserved | Reserved for future use |
| 0x24 | Reserved | Reserved for future use |
| 0x25 | Reserved | Reserved for future use |
| 0x26 | CALLINGPRES | Calling presentation |
| 0x27 | CALLINGTON | Calling type of number |
| 0x28 | CALLINGTNS | Calling transit network select |
| 0x29 | SAMPLINGRATE | Supported sampling rates |
| 0x2a | CAUSECODE | Hangup cause |
| 0x2b | ENCRYPTION | Encryption format |
| 0x2c | ENCKEY | Reserved for future Use |
| 0x2d | CODEC PREFS | CODEC Negotiation |
| 0x2e | RR JITTER | Received jitter, as in RFC 3550 |
| 0x2f | RR LOSS | Received loss, as in RFC 3550 |
| 0x30 | RR PKTS | Received frames |
| 0x31 | RR DELAY | Max playout delay for received frames in |
| | | ms |
| 0x32 | RR DROPPED | Dropped frames (presumably by jitter |
| | | buffer) |
| 0x33 | RR OOO | Frames received Out of Order |
| 0x34 | OSPTOKEN | OSP Token Block |
+------+----------------+-------------------------------------------+
Table 1: Information Element Definitions
表1：信息元素定义
Refer to the IANA Registry for additional IAX Information Element values.
有关其他IAX信息元素值，请参阅IANA注册表。
The purpose of the CALLED NUMBER information element is to indicate the number or extension being called. It carries UTF-8-encoded data. The CALLED NUMBER information element MUST use UTF-8 encoding and not numeric data because destinations are not limited to E.164 numbers ([E164]), national numbers, or even digits. It is possible for a number or extension to include non-numeric characters. The CALLED NUMBER IE MAY contain a SIP URI, [RFC3261] or a URI in any other format. The ability to serve a CALLED NUMBER is server dependent.
被叫号码信息元素的用途是指示被呼叫的号码或分机。它携带UTF-8编码的数据。被叫号码信息元素必须使用UTF-8编码，而不是数字数据，因为目的地不限于E.164号码（[E164]）、国家号码或偶数。数字或扩展名可以包含非数字字符。被叫号码IE可以包含SIP URI、[rfc326]或任何其他格式的URI。为被叫号码提供服务的能力取决于服务器。
The CALLED NUMBER information element is generally sent with IAX NEW, DPREQ, DPREP, DIAL, and TRANSFER messages.
被叫号码信息元素通常与IAX NEW、DPREQ、DPREP、拨号和传输消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLED NUMBER :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLED NUMBER :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CALLING NUMBER information element is to indicate the number or extension of the calling entity to the remote peer. It carries UTF-8-encoded data.
主叫号码信息元素的目的是向远程对等方指示主叫实体的号码或分机。它携带UTF-8编码的数据。
The CALLING NUMBER information element is usually sent with IAX NEW messages.
主叫号码信息元素通常与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING NUMBER :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING NUMBER :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CALLING ANI information element is to indicate the calling number ANI (Automatic Number Identification) for billing. It carries UTF-8-encoded data.
呼叫ANI信息元素的目的是指示呼叫号码ANI（自动号码识别），以便计费。它携带UTF-8编码的数据。
The CALLING ANI information element MAY be sent with an IAX NEW message, but it is not required.
调用ANI信息元素可以与IAX新消息一起发送，但不是必需的。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING ANI :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING ANI :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CALLING NAME information element is to indicate the calling name of the transmitting peer. It carries UTF-8-encoded data.
呼叫名称信息元素的目的是指示发送对等方的呼叫名称。它携带UTF-8编码的数据。
The CALLING NAME information element is usually sent with IAX NEW messages.
调用名称信息元素通常与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING NAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLING NAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CALLED CONTEXT information element is to indicate the context (or partition) of the remote peer's dialplan that the CALLED NUMBER is interpreted. It carries UTF-8-encoded data.
被调用上下文信息元素的目的是指示被调用号码被解释的远程对等方拨号计划的上下文（或分区）。它携带UTF-8编码的数据。
The CALLED CONTEXT information element MAY be sent with IAX NEW or TRANSFER messages, though it is not required.
被调用的上下文信息元素可以与IAX NEW或TRANSFER消息一起发送，尽管它不是必需的。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLED CONTEXT :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CALLED CONTEXT :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the USERNAME information element is to specify the identity of the user participating in an IAX message exchange. It carries UTF-8-encoded data.
USERNAME信息元素的目的是指定参与IAX消息交换的用户的身份。它携带UTF-8编码的数据。
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.
用户名信息元素可以与IAX NEW、AUTHREQ、REGREQ、REGAUTH或REGACK消息一起发送，也可以在对等方需要识别用户时发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x06 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded USERNAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x06 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded USERNAME :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CAPABILITY information element is to indicate the media CODEC capabilities of an IAX peer. Its data is represented in a 4-octet bitmask according to Section 8.7. Multiple CODECs MAY be specified by logically OR'ing them into the CAPABILITY information element.
能力信息元素的目的是指示IAX对等方的媒体编解码器能力。根据第8.7节，其数据以4个八位组的位掩码表示。可以通过将多个编解码器逻辑地或“输入”到能力信息元素中来指定它们。
The CAPABILITY information element is sent with IAX NEW messages if appropriate for the CODEC negotiation method the peer is using.
如果适用于对等方正在使用的编解码器协商方法，则功能信息元素将与IAX新消息一起发送。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the FORMAT information element is to indicate a single preferred media CODEC. When sent with a NEW message, the indicated CODEC is the desired CODEC an IAX peer wishes to use for a call. When sent with an ACCEPT message, it indicates the actual CODEC that has been selected for the call. Its data is represented in a 4-octet bitmask according to Section 8.7. Only one CODEC MUST be specified in the FORMAT information element.
格式信息元素的目的是指示单个首选媒体编解码器。当与新消息一起发送时，指示的编解码器是IAX对等方希望用于呼叫的所需编解码器。当与接受消息一起发送时，它表示已为呼叫选择的实际编解码器。根据第8.7节，其数据以4个八位组的位掩码表示。格式信息元素中只能指定一个编解码器。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the LANGUAGE information element is to indicate the language in which the transmitting peer would like the remote peer to send signaling information. It carries UTF-8-encoded data and tags should be selected per [RFC5646] and [RFC4647].
语言信息元素的目的是指示发送对等方希望远程对等方发送信令信息的语言。它携带UTF-8编码的数据，应根据[RFC5646]和[RFC4647]选择标签。
The LANGUAGE information element MAY be sent with an IAX NEW message.
语言信息元素可以与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0a | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded LANGUAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0a | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded LANGUAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
版本信息元素的目的是指示对等方正在使用的协议版本。呼叫两端的对等方必须使用相同的协议版本。目前，唯一受支持的版本是2。版本信息元素的数据字段长度为2个八位字节。
The VERSION information element MUST be sent with an IAX NEW message.
版本信息元素必须与IAX新消息一起发送。
When sent, the VERSION information element MUST be the first IE in the message.
发送时，版本信息元素必须是消息中的第一个IE。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0b | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0b | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the ADSICPE information element is to indicate the CPE (Customer Premises Equipment) ADSI (Analog Display Services Interface) capability. The data field of the ADSICPE information element is 2 octets long.
ADSICPE信息元素的目的是指示CPE（客户场所设备）ADSI（模拟显示服务接口）能力。ADSICPE信息元素的数据字段长度为2个八位字节。
The ADSICPE information element MAY be sent with an IAX NEW message.
ADSICPE信息元素可以与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADSICPE Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADSICPE Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the DNID information element is to indicate the Dialed Number ID, which may differ from the 'called number'. It carries UTF-8-encoded data.
DNID信息元素的用途是指示拨号号码ID，它可能不同于“被叫号码”。它携带UTF-8编码的数据。
The DNID information element MAY be sent with an IAX NEW message.
DNID信息元素可以与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded DNID Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded DNID Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the AUTHMETHODS information element is to indicate the authentication methods a peer accepts. It is sent as a bitmask two octets long. The table below lists the valid authentication methods.
AUTHMETHODS信息元素的目的是指示对等方接受的身份验证方法。它作为两个八位字节长的位掩码发送。下表列出了有效的身份验证方法。
The AUTHMETHODS information element MUST be sent with IAX AUTHREQ and REGAUTH messages.
AUTHMETHODS信息元素必须与IAX AUTHREQ和REGAUTH消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0e | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Authentication Methods |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0e | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Authentication Methods |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following table lists valid values for authentication:
下表列出了用于身份验证的有效值：
+--------+--------------------------+
| METHOD | DESCRIPTION |
+--------+--------------------------+
| 0x0001 | Reserved (was Plaintext) |
| | |
| 0x0002 | MD5 |
| | |
| 0x0004 | RSA |
+--------+--------------------------+
+--------+--------------------------+
| METHOD | DESCRIPTION |
+--------+--------------------------+
| 0x0001 | Reserved (was Plaintext) |
| | |
| 0x0002 | MD5 |
| | |
| 0x0004 | RSA |
+--------+--------------------------+
Refer to the IANA Registry for additional IAX Authentication Method values.
有关其他IAX身份验证方法值，请参阅IANA注册表。
The purpose of the CHALLENGE information element is to offer the MD5 or RSA challenge to be used for authentication. It carries the actual UTF-8-encoded challenge data.
质询信息元素的目的是提供用于身份验证的MD5或RSA质询。它携带实际的UTF-8编码挑战数据。
The CHALLENGE information element MUST be sent with IAX AUTHREQ and REGAUTH messages.
质询信息元素必须与IAX AUTHREQ和REGAUTH消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0f | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded Challenge Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0f | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded Challenge Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the MD5 RESULT information element is to offer an MD5 response to an authentication CHALLENGE. It carries the UTF-8- encoded challenge result. The MD5 Result value is computed by taking the MD5 [RFC1321] digest of the challenge string and the password string.
MD5结果信息元素的目的是为身份验证质询提供MD5响应。它携带UTF-8编码的质询结果。通过获取质询字符串和密码字符串的MD5[RFC1321]摘要来计算MD5结果值。
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.
如果接收到AUTHREQ或REGAUTH以及相应的质询，则MD5结果信息元素可以与IAX AUTHREP和REGREQ消息一起发送。除非响应质询，否则不得发送此信息元素。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded MD5 Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded MD5 Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RSA RESULT information element is to offer an RSA response to an authentication CHALLENGE. It carries the UTF-8- encoded challenge result. The result is computed as follows: first, compute the SHA1 digest [RFC3174] of the challenge string and second, RSA sign the SHA1 digest using the private RSA key as specified in PKCS #1 v2.0 [PKCS]. The RSA keys are stored locally.
RSA结果信息元素的目的是提供RSA对身份验证挑战的响应。它携带UTF-8编码的质询结果。计算结果如下：首先，计算质询字符串的SHA1摘要[RFC3174]，然后，RSA使用PKCS#1 v2.0[PKCS]中指定的RSA私钥对SHA1摘要进行签名。RSA密钥存储在本地。
Upon receiving an RSA RESULT information element, its value must be verified with the sender's public key to match the SHA1 digest [RFC3174] of the challenge string.
收到RSA结果信息元素后，必须使用发送方的公钥验证其值，以匹配质询字符串的SHA1摘要[RFC3174]。
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.
如果接收到AUTHREQ或REGAUTH以及相应的质询，则RSA结果信息元素可能会与IAX AUTHREP和REGREQ消息一起发送。除非响应质询，否则不得发送此信息元素。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded RSA Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded RSA Result :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the APPARENT ADDR information element is to indicate the perceived network connection information used to reach a peer, which may differ from the actual address when the peer is behind NAT. The APPARENT ADDR IE is populated using the source address values of the UDP and IP headers in the IAX message to which this response is generated. The data field of the APPARENT ADDR information element is the same as the POSIX sockaddr struct for the address family in use (i.e., sockaddr_in for IPv4, sockaddr_in6 for IPv6). The data length depends on the type of address being represented.
明显的ADDR信息元素的目的是指示用于到达对等方的感知网络连接信息，当对等方位于NAT之后时，该信息可能不同于实际地址。表观地址IE使用生成此响应的IAX消息中UDP和IP头的源地址值填充。表观地址信息元素的数据字段与正在使用的地址系列的POSIX sockaddr结构相同（即，对于IPv4为sockaddr_in，对于IPv6为sockaddr_in 6）。数据长度取决于所表示的地址类型。
The APPARENT ADDR information element MUST be sent with IAX TXREQ and REGACK messages. When used with a TXREQ message, the APPARENT ADDR MUST specify the address of the peer to which the local peer is trying to transfer its end of the connection. When used with a REGACK message, the APPARENT ADDR MUST specify the address it uses to reach the peer (which may be different than the address the peer perceives itself as in the case of NAT or multi-homed peer machines).
表观ADDR信息元素必须与IAX TXREQ和REGACK消息一起发送。当与TXREQ消息一起使用时，表观地址必须指定本地对等方试图将其连接结束传输到的对等方的地址。当与REGACK消息一起使用时，明显地址必须指定它用于到达对等方的地址（这可能不同于对等方在NAT或多宿主对等机的情况下认为自己的地址）。
The data field of the APPARENT ADDR information element is the same as the Linux struct sockaddr_in: two octets for the address family, two octets for the port number, four octets for the IPv4 address, and 8 octets of padding consisting of all bits set to 0. Thus, the total length of the APPARENT ADDR information element is 18 octets.
表观地址信息元素的数据字段与中的Linux struct sockaddr_相同：两个八位字节用于地址族，两个八位字节用于端口号，四个八位字节用于IPv4地址，以及8个八位字节的填充，包括所有设置为0的位。因此，表观ADDR信息元素的总长度为18个八位字节。
The following diagram demonstrates the generic APPARENT ADDR format:
下图演示了通用的表观ADDR格式：
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
下图演示了IPv4地址的外观ADDR格式：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x12 | 0x10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0200 | <- Address family (INET)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11d9 | <- Portno (default 4569)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IP address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 8 octets of all 0s |
| (padding in sockaddr_in) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x12 | 0x10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0200 | <- Address family (INET)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11d9 | <- Portno (default 4569)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IP address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 8 octets of all 0s |
| (padding in sockaddr_in) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram demonstrates the APPARENT ADDR format for an IPv6 address:
下图演示了IPv6地址的外观ADDR格式：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x12 | 0x1C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0A00 | <- Address family (INET6)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11d9 | <- Portno (default 4569)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits | <- Flow information
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit IP address | <- Ip6 Address
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits | <- Scope ID
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x12 | 0x1C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0A00 | <- Address family (INET6)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11d9 | <- Portno (default 4569)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits | <- Flow information
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit IP address | <- Ip6 Address
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits | <- Scope ID
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
刷新信息元素的目的是指示事件过期前的秒数。其数据字段为2个八位字节长。
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.
刷新信息元素与IAX REGREQ、REGACK和DPREP消息一起使用。当发送REGREQ时，它是一个请求，维护注册的对等方将超时设置为刷新秒。当用DPREP或ReCACK发送时，它是信息性的，并且当本地对等体不再考虑事件有效时，告诉远程对等体。与DPREP一起发送的刷新告诉对等方它应该存储收到的拨号计划响应多长时间。
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.
如果未使用DPREP接收到刷新信息元素，则假定缓存数据的过期时间为10分钟。如果刷新信息元素未通过重新打包接收，则假定注册过期在60秒后发生。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x13 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 octets specifying refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x13 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 octets specifying refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the DPSTATUS information element is to indicate the status of a CALLED NUMBER in a remote dialplan. Its data field is a 2-octet bitmask specifying flags from the table below. Exactly one of the low 3 bits MUST be set, and zero, 1, or 2 of the high 2 bits MAY be set.
DPSTATUS信息元素的用途是指示远程拨号计划中被叫号码的状态。其数据字段是一个2-octet位掩码，指定下表中的标志。必须精确设置低3位中的一位，并且可以设置高2位中的0、1或2位。
The DPSTATUS information element MUST be sent with IAX DPREP messages, as it is the payload of the dialplan response.
DPSTATUS信息元素必须与IAX DPREP消息一起发送，因为它是dialplan响应的有效负载。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x14 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| |N|C|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x14 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| |N|C|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following table lists the dialplan status flags:
下表列出了拨号计划状态标志：
+--------+------------------------------+
| FLAG | DESCRIPTION |
+--------+------------------------------+
| 0x0001 | Exists |
| | |
| 0x0002 | Can exist |
| | |
| 0x0004 | Non-existent |
| | |
| 0x4000 | Retain dialtone (ignorepat) |
| | |
| 0x8000 | More digits may match number |
+--------+------------------------------+
+--------+------------------------------+
| FLAG | DESCRIPTION |
+--------+------------------------------+
| 0x0001 | Exists |
| | |
| 0x0002 | Can exist |
| | |
| 0x0004 | Non-existent |
| | |
| 0x4000 | Retain dialtone (ignorepat) |
| | |
| 0x8000 | More digits may match number |
+--------+------------------------------+
Refer to the IANA Registry for additional IAX dialplan status values.
有关其他IAX拨号计划状态值，请参阅IANA注册表。
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.
CALLNO信息元素的目的是指示远程对等方需要使用的呼叫号码作为目标呼叫号码，以识别正在转接的呼叫。管理传输的对等方将一个传输端点的CALLNO发送到另一个传输端点，以便知道要为传输指定的呼叫号码。数据字段的长度为2个八位字节，指定呼叫号码的方式与在帧头中指定源呼叫号码或目标呼叫号码的方式相同。
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.
CALLNO信息元素必须与IAX TXREQ、TXREADY和TXREL消息一起发送。如果CALLNO IE未包含在相应的传输消息中，则传输无法成功。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x15 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Callno of transfer recipient |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x15 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Callno of transfer recipient |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the CAUSE information element is to indicate the reason an event occurred. It carries a description of the CAUSE of the event as UTF-8-encoded data. Notification of the event itself is handled at the message level.
原因信息元素的目的是指示事件发生的原因。它将事件原因描述为UTF-8编码数据。事件本身的通知在消息级别处理。
The CAUSE information element SHOULD be sent with IAX HANGUP, REJECT, REGREJ, and TXREJ messages.
原因信息元素应与IAX挂起、拒绝、重新加入和TXREJ消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x16 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CAUSE of event :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x16 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded CAUSE of event :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the IAX UNKNOWN information element is to indicate that a received IAX command was unknown or unrecognized. The 1-octet data field contains the subclass of the received frame that was unrecognized.
IAX UNKNOWN information元素的用途是指示接收到的IAX命令未知或无法识别。1-octet数据字段包含无法识别的接收帧的子类。
The IAX UNKNOWN information element MUST be sent with IAX UNSUPPORT messages.
IAX未知信息元素必须与IAX不支持消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x17 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec'd Subclass|
+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x17 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec'd Subclass|
+-+-+-+-+-+-+-+-+
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.
MSGCOUNT信息元素的用途是指示注册用户邮箱中有多少语音邮件正在等待。数据字段的长度为2个八位字节。如果将其设置为所有1，则至少存在一条消息。任何其他值指定高8位中的旧消息数和低8位中的新消息数。
The IAX MSGCOUNT information element MAY be sent with IAX REGACK messages.
IAX MSGCOUNT信息元素可以与IAX REGACK消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x18 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old messages | New messages |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x18 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old messages | New messages |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the AUTOANSWER information element is to request that a call be auto-answered upon receipt of a NEW message that includes the AUTOANSWER information element. Note that this is a request and may or may not be granted by the remote peer. There is no data field with this information element, as its presence alone indicates all necessary information.
自动应答信息元素的用途是请求在收到包含自动应答信息元素的新消息时自动应答呼叫。请注意，这是一个请求，远程对等方可能会也可能不会批准。没有包含此信息元素的数据字段，因为它的存在表示所有必要的信息。
The AUTOANSWER information element MAY be sent with IAX NEW messages.
自动应答信息元素可以与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x19 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x19 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the MUSICONHOLD information element is to request that music-on-hold be played while a call is in the QUELCH state. The optional data field specifies a music-on-hold class to be used, as UTF-8-encoded data. In the absence of a data field, no music-on-hold class is specified and the IE SHOULD be treated as a generic request for music-on-hold.
MUSICONHOLD信息元素的目的是请求在通话处于QUELCH状态时播放保留中的音乐。可选数据字段指定要使用的音乐保留类，如UTF-8编码数据。在没有数据字段的情况下，不指定音乐保留类，IE应被视为音乐保留的一般请求。
The MUSICONHOLD information element MAY be sent with IAX QUELCH messages.
MUSICONHOLD信息元素可以与IAX QUELCH消息一起发送。
If no MUSICONHOLD information element is received, music-on-hold is not requested.
如果未接收到MUSICONHOLD信息元素，则不请求保留音乐。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the TRANSFERID information element is to identify a transfer across all three peers participating in a transfer event. It carries a number, four octets long, that SHOULD be unique for the duration of the transfer process.
TRANSFERID信息元素的目的是识别参与传输事件的所有三个对等方之间的传输。它携带一个数字，四个八位字节长，在传输过程中应该是唯一的。
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.
TRANSFERID信息元素应与IAX TXREQ和TXCNT消息一起发送，以帮助参与传输的对等方识别正确的呼叫。只要传输对等方能够在不使用TRANSFERID的情况下肯定地识别参与传输的呼叫，就不需要使用TRANSFERID。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1b | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet transfer |
| identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1b | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet transfer |
| identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RDNIS (Redirected Dialed Number Identification Service) information element is to indicate the referring DNIS. It carries UTF-8-encoded data.
RDNIS（重定向拨号号码识别服务）信息元素的目的是指示参考的DNI。它携带UTF-8编码的数据。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1c | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded RDNIS :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1c | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UTF-8-encoded RDNIS :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DATETIME information element indicates the time a message is sent. This differs from the header time-stamp because that time-stamp begins at 0 for each call, while the DATETIME is a call-independent value representing the actual real-world time. The data field of a DATETIME information element is four octets long and stores the time as follows: the 5 least significant bits are seconds, the next 6 least significant bits are minutes, the next least significant 5 bits are hours, the next least significant 5 bits are the day of the month, the next least significant 4 bits are the month, and the most significant 7 bits are the year. The year is offset from 2000, and the month is a 1-based index (i.e., January == 1, February == 2, etc.). The timezone of the clock MUST be UTC to avoid confusion between the peers.
DATETIME信息元素指示消息的发送时间。这与标头时间戳不同，因为每个调用的时间戳都从0开始，而DATETIME是一个独立于调用的值，表示实际时间。DATETIME信息元素的数据字段为四个八位字节长，并按如下方式存储时间：5个最低有效位为秒，接下来的6个最低有效位为分钟，接下来的最低有效位为小时，接下来的最低有效位为月中的一天，接下来的最低有效位为月，最重要的7位是年份。年份与2000年相抵，月份是以1为基础的指数（即一月=1，二月=2，等等）。时钟的时区必须为UTC，以避免同级之间的混淆。
The DATETIME information element SHOULD be sent with IAX NEW and REGACK messages. However, it is strictly informational.
DATETIME信息元素应与IAX NEW和Reack消息一起发送。然而，它是严格的信息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
CALLINGPRES信息元素的目的是指示呼叫者的呼叫表示。数据字段的长度为1个八位字节，包含下表中的值。
The CALLINGPRES information element MUST be sent with IAX NEW messages.
CALLINGPRES信息元素必须与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x26 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Pres. |
+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x26 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Pres. |
+-+-+-+-+-+-+-+-+
The following table lists valid calling presentation values:
下表列出了有效的调用表示值：
+------+--------------------------------------+
| FLAG | PRESENTATION |
+------+--------------------------------------+
| 0x00 | Allowed user/number not screened |
| | |
| 0x01 | Allowed user/number passed screen |
| | |
| 0x02 | Allowed user/number failed screen |
| | |
| 0x03 | Allowed network number |
| | |
| 0x20 | Prohibited user/number not screened |
| | |
| 0x21 | Prohibited user/number passed screen |
| | |
| 0x22 | Prohibited user/number failed screen |
| | |
| 0x23 | Prohibited network number |
| | |
| 0x43 | Number not available |
+------+--------------------------------------+
+------+--------------------------------------+
| FLAG | PRESENTATION |
+------+--------------------------------------+
| 0x00 | Allowed user/number not screened |
| | |
| 0x01 | Allowed user/number passed screen |
| | |
| 0x02 | Allowed user/number failed screen |
| | |
| 0x03 | Allowed network number |
| | |
| 0x20 | Prohibited user/number not screened |
| | |
| 0x21 | Prohibited user/number passed screen |
| | |
| 0x22 | Prohibited user/number failed screen |
| | |
| 0x23 | Prohibited network number |
| | |
| 0x43 | Number not available |
+------+--------------------------------------+
Refer to the IANA Registry for additional IAX Calling Presentation values.
有关其他IAX调用表示值，请参阅IANA注册表。
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.
根据ITU-T建议Q.931规范，CALLINGTON信息元素的目的是指示呼叫方号码的呼叫类型。数据字段的长度为1个八位字节，包含下表中的数据。
The CALLINGTON information element MUST be sent with IAX NEW messages.
CALLINGTON信息元素必须与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x27 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling TON |
+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x27 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling TON |
+-+-+-+-+-+-+-+-+
The following table lists valid calling type of number values from ITU-T Recommendation Q.931:
下表列出了ITU-T建议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 |
+-------+-------------------------+
+-------+-------------------------+
| VALUE | DESCRIPTION |
+-------+-------------------------+
| 0x00 | Unknown |
| | |
| 0x10 | International Number |
| | |
| 0x20 | National Number |
| | |
| 0x30 | Network Specific Number |
| | |
| 0x40 | Subscriber Number |
| | |
| 0x60 | Abbreviated Number |
| | |
| 0x70 | Reserved for extension |
+-------+-------------------------+
Refer to the IANA Registry for any additional IAX Calling Type of Number values.
有关任何其他IAX调用类型的数值，请参阅IANA注册表。
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
CALLINGTNS信息元素表示为呼叫选择的呼叫转接网络。根据ITU-T建议Q.931规范选择值。数据字段的长度为两个八位字节。第一个八位组将网络标识计划存储在
least significant four bits according to the first table below, and the type of network in the next three least significant bits according to the second table below. The second octet stores the actual network identification in UTF-8-encoded data.
根据下表第一个表，最低有效位为四位，根据下表第二个表，下三个最低有效位中的网络类型。第二个八位组将实际网络标识存储在UTF-8编码数据中。
The CALLINGTNS information element MUST be sent with IAX NEW messages.
CALLINGTNS信息元素必须与IAX新消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x28 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TON | Plan | UTF-8 Net ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x28 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TON | Plan | UTF-8 Net ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following tables list the valid values for the data field of the 'calling tns' IE.
下表列出了“调用tns”IE的数据字段的有效值。
Q.931 Network Identification Plan Values:
Q.931网络标识计划值：
+------+----------------------------------+
| BITS | DESCRIPTION |
+------+----------------------------------+
| 0000 | Unknown |
| | |
| 0001 | Caller Identification Code |
| | |
| 0011 | Data Network Identification Code |
+------+----------------------------------+
+------+----------------------------------+
| BITS | DESCRIPTION |
+------+----------------------------------+
| 0000 | Unknown |
| | |
| 0001 | Caller Identification Code |
| | |
| 0011 | Data Network Identification Code |
+------+----------------------------------+
Refer to the IAX Transit Network Identification IANA Registry for any additional values.
有关任何其他值，请参阅IAX运输网络标识IANA注册表。
Q.931 Type of Network Values:
Q.931网络值的类型：
+------+--------------------------------------+
| BITS | DESCRIPTION |
+------+--------------------------------------+
| 000 | User Specified |
| | |
| 010 | National Network Identification |
| | |
| 011 | International Network Identification |
+------+--------------------------------------+
+------+--------------------------------------+
| BITS | DESCRIPTION |
+------+--------------------------------------+
| 000 | User Specified |
| | |
| 010 | National Network Identification |
| | |
| 011 | International Network Identification |
+------+--------------------------------------+
Refer to the IAX Type of Network IANA Registry for any additional values.
有关任何其他值，请参阅IAX类型的网络IANA注册表。
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.
SAMPLINGRATE信息元素的目的是向远程IAX对等方指定对等方在发送数据时将使用的音频数据的采样率（以赫兹为单位）。其数据字段为2个八位字节长。
If the SAMPLINGRATE information element is not specified, a default sampling rate of 8 kHz may be assumed.
如果未指定采样率信息元素，则可假定默认采样率为8 kHz。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x29 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sampling Rate in Hertz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x29 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sampling Rate in Hertz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
CAUSECODE信息元素的目的是指示呼叫被拒绝或挂断的原因。它源自ITU-T建议Q.931。数据字段的长度为一个八位字节，包含下表中的一个条目。
The CAUSECODE information element SHOULD be sent with IAX HANGUP, REJECT, REGREJ, and TXREJ messages.
CAUSECODE信息元素应与IAX挂起、拒绝、重新加入和TXREJ消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2a | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code |
+-+-+-+-+-+-+-+-+
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 |
| | |
| 29 | Facility rejected |
| | |
| 30 | Response to status enquiry |
| | |
| 31 | Normal, unspecified |
| | |
| 34 | No circuit/channel available |
| | |
| 38 | Network out of order |
| | |
| 41 | Temporary failure |
| | |
| 42 | Switch congestion |
| | |
| 43 | Access information discarded |
| | |
| 44 | Requested channel not available |
| | |
| 45 | Preempted (causes.h only) |
+--------+----------------------------------------------------------+
| NUMBER | CAUSE |
+--------+----------------------------------------------------------+
| 1 | Unassigned/unallocated number |
| | |
| 2 | No route to specified transit network |
| | |
| 3 | No route to destination |
| | |
| 6 | Channel unacceptable |
| | |
| 7 | Call awarded and delivered |
| | |
| 16 | Normal call clearing |
| | |
| 17 | User busy |
| | |
| 18 | No user response |
| | |
| 19 | No answer |
| | |
| 21 | Call rejected |
| | |
| 22 | Number changed |
| | |
| 27 | Destination out of order |
| | |
| 28 | Invalid number format/incomplete number |
| | |
| 29 | Facility rejected |
| | |
| 30 | Response to status enquiry |
| | |
| 31 | Normal, unspecified |
| | |
| 34 | No circuit/channel available |
| | |
| 38 | Network out of order |
| | |
| 41 | Temporary failure |
| | |
| 42 | Switch congestion |
| | |
| 43 | Access information discarded |
| | |
| 44 | Requested channel not available |
| | |
| 45 | Preempted (causes.h only) |
| | |
| 47 | Resource unavailable, unspecified (Q.931 only) |
| | |
| 50 | Facility not subscribed (causes.h only) |
| | |
| 52 | Outgoing call barred (causes.h only) |
| | |
| 54 | Incoming call barred (causes.h only) |
| | |
| 57 | Bearer capability not authorized |
| | |
| 58 | Bearer capability not available |
| | |
| 63 | Service or option not available (Q.931 only) |
| | |
| 65 | Bearer capability not implemented |
| | |
| 66 | Channel type not implemented |
| | |
| 69 | Facility not implemented |
| | |
| 70 | Only restricted digital information bearer capability is |
| | available (Q.931 only) |
| | |
| 79 | Service or option not available (Q.931 only) |
| | |
| 81 | Invalid call reference |
| | |
| 82 | Identified channel does not exist (Q.931 only) |
| | |
| 83 | A suspended call exists, but this call identity does not |
| | (Q.931 only) |
| | |
| 84 | Call identity in use (Q.931 only) |
| | |
| 85 | No call suspended (Q.931 only) |
| | |
| 86 | Call has been cleared (Q.931 only) |
| | |
| 88 | Incompatible destination |
| | |
| 91 | Invalid transit network selection (Q.931 only) |
| | |
| 95 | Invalid message, unspecified |
| | |
| 96 | Mandatory information element missing (Q.931 only) |
| | |
| 97 | Message type nonexistent/not implemented |
| | |
| 47 | Resource unavailable, unspecified (Q.931 only) |
| | |
| 50 | Facility not subscribed (causes.h only) |
| | |
| 52 | Outgoing call barred (causes.h only) |
| | |
| 54 | Incoming call barred (causes.h only) |
| | |
| 57 | Bearer capability not authorized |
| | |
| 58 | Bearer capability not available |
| | |
| 63 | Service or option not available (Q.931 only) |
| | |
| 65 | Bearer capability not implemented |
| | |
| 66 | Channel type not implemented |
| | |
| 69 | Facility not implemented |
| | |
| 70 | Only restricted digital information bearer capability is |
| | available (Q.931 only) |
| | |
| 79 | Service or option not available (Q.931 only) |
| | |
| 81 | Invalid call reference |
| | |
| 82 | Identified channel does not exist (Q.931 only) |
| | |
| 83 | A suspended call exists, but this call identity does not |
| | (Q.931 only) |
| | |
| 84 | Call identity in use (Q.931 only) |
| | |
| 85 | No call suspended (Q.931 only) |
| | |
| 86 | Call has been cleared (Q.931 only) |
| | |
| 88 | Incompatible destination |
| | |
| 91 | Invalid transit network selection (Q.931 only) |
| | |
| 95 | Invalid message, unspecified |
| | |
| 96 | Mandatory information element missing (Q.931 only) |
| | |
| 97 | Message type nonexistent/not implemented |
| | |
| 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 |
+--------+----------------------------------------------------------+
| | |
| 98 | Message not compatible with call state |
| | |
| 99 | Information element nonexistent |
| | |
| 100 | Invalid information element contents |
| | |
| 101 | Message not compatible with call state |
| | |
| 102 | Recovery on timer expiration |
| | |
| 103 | Mandatory information element length error (causes.h |
| | only) |
| | |
| 111 | Protocol error, unspecified |
| | |
| 127 | Internetworking, unspecified |
+--------+----------------------------------------------------------+
Refer to the IAX Cause Codes IANA Registry for any additional values.
有关任何其他值，请参阅IAX原因代码IANA注册表。
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.
加密信息元素的目的是指示IAX对等机接受哪些加密方法。数据字段是一个2-octet位掩码，指定接受下表中的哪些加密方法。
The ENCRYPTION information element MAY be sent with IAX NEW and AUTHREQ messages.
加密信息元素可以与IAX NEW和AUTHREQ消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2b | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Methods |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+--------+-------------+
+--------+-------------+
| METHOD | DESCRIPTION |
+--------+-------------+
| 0x0001 | AES-128 |
+--------+-------------+
Refer to the IAX Encryption Methods IANA Registry for any additional values.
有关任何其他值，请参阅IAX加密方法IANA注册表。
The purpose of the CODEC PREFS information element is to indicate the CODEC preferences of the calling peer. The data field consists of a list of CODECs in the peer's order of preference as UTF-8-encoded data.
CODEC PREFS信息元素的用途是指示呼叫对等方的编解码器首选项。数据字段由一系列编解码器组成，这些编解码器按照对等方的优先顺序排列为UTF-8编码数据。
The CODEC PREFS information element MAY be sent with IAX NEW messages.
CODEC PREFS信息元素可以与IAX新消息一起发送。
If the CODEC PREFS information element is absent, CODEC negotiation takes place via the CAPABILITY and FORMAT information elements.
如果缺少CODEC PREFS信息元素，则通过能力和格式信息元素进行编解码器协商。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: CODEC Prefs Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2d | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: CODEC Prefs Data :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the Receiver Report (RR) JITTER information element is to indicate the received jitter on a call, per [RFC3550]. The data field is 4 octets long and carries the current measured jitter.
接收器报告（RR）抖动信息元素的目的是根据[RFC3550]指示呼叫上接收到的抖动。数据字段为4个八位字节长，携带当前测量的抖动。
The RR JITTER information element MAY be sent with IAX PONG messages.
RR抖动信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2e | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Jitter |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2e | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received Jitter |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RR LOSS information element is to indicate the number of lost frames on a call, per [RFC3550]. The data field is 4 octets long and carries the percentage of frames lost in the first octet, and the count of lost frames in the next 3 octets.
RR丢失信息元素的目的是根据[RFC3550]指示通话中丢失的帧数。数据字段的长度为4个八位字节，包含第一个八位字节中丢失的帧的百分比，以及接下来3个八位字节中丢失的帧的计数。
The RR LOSS information element MAY be sent with IAX PONG messages.
RR丢失信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2f | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Percent | |
+-+-+-+-+-+-+-+-+ Loss Count |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2f | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Percent | |
+-+-+-+-+-+-+-+-+ Loss Count |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RR PKTS information element is to indicate the total number of frames received on a call, per [RFC3550]. The data field is 4 octets long and carries the count of frames received.
RR PKTS信息元素的目的是根据[RFC3550]指示在呼叫中接收的帧总数。数据字段的长度为4个八位字节，包含接收到的帧数。
The RR PKTS information element MAY be sent with IAX PONG messages.
RR PKTS信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x30 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frames Received Count |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x30 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frames Received Count |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RR DELAY information element is to indicate the maximum playout delay for a call, per [RFC3550]. The data field is 2 octets long and specifies the number of milliseconds a frame may be delayed before it MUST be discarded.
RR延迟信息元素的目的是根据[RFC3550]指示呼叫的最大播放延迟。数据字段的长度为2个八位字节，指定一帧在必须丢弃之前可能延迟的毫秒数。
The RR DELAY information element MAY be sent with IAX PONG messages.
RR延迟信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x31 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Playout Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x31 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Playout Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RR DROPPED information element is to indicate the total number of dropped frames for a call, per [RFC3550]. The data field is 4 octets long and carries the number of frames dropped.
RR丢弃信息元素的目的是根据[RFC3550]指示呼叫丢弃帧的总数。数据字段的长度为4个八位字节，包含丢弃的帧数。
The RR DROPPED information element MAY be sent with IAX PONG messages.
RR丢弃的信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x32 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Frames Dropped |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x32 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Frames Dropped |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the RR OOO information element is to indicate the number of frames received out of order for a call, per [RFC3550]. The data field is 4 octets long and carries the number of frames received out of order.
RR OOO信息元素的目的是根据[RFC3550]指示一次呼叫接收到的无序帧数。数据字段的长度为4个八位字节，包含无序接收的帧数。
The RR OOO information element MAY be sent with IAX PONG messages.
RR OOO信息元素可以与IAX PONG消息一起发送。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x33 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frames Received |
| Out of Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x33 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frames Received |
| Out of Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The purpose of the OSPTOKEN information element is to carry European Telecommunications Standards Institute (ETSI) Technical Specification 101 321 [OSP] (also referred to as the Open Settlement Protocol or OSP) tokens. The OSP tokens will be used to provide authorization, authentication and account support for IAX by using the OSP protocol. The first octet of the data field is the OSP token block index starting from 0.
OSPTOKEN信息元素的目的是携带欧洲电信标准协会（ETSI）技术规范101 321[OSP]（也称为开放式结算协议或OSP）令牌。OSP令牌将用于通过使用OSP协议为IAX提供授权、身份验证和帐户支持。数据字段的第一个八位字节是从0开始的OSP令牌块索引。
The OSPTOKEN information element MAY only be sent with IAX NEW messages. If the token is not supported by the receiver, it is ignored.
OSPTOKEN信息元素只能与IAX新消息一起发送。如果接收器不支持该令牌，则将忽略它。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x34 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Index | |
+-+-+-+-+-+-+-+-+ +
| OSP Token Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x34 | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Index | |
+-+-+-+-+-+-+-+-+ +
| OSP Token Block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Media Format Values
媒体格式值
+------------+-----------------+------------------------------------+
| SUBCLASS | DESCRIPTION | LENGTH CALCULATION |
+------------+-----------------+------------------------------------+
| 0x00000001 | G.723.1 | 4-, 20-, and 24-byte frames of 240 |
| | | samples |
| | | |
| 0x00000002 | GSM Full Rate | 33-byte chunks of 160 samples or |
| | | 65-byte chunks of 320 samples |
| | | |
| 0x00000004 | G.711 mu-law | 1 byte per sample |
| | | |
| 0x00000008 | G.711 a-law | 1 byte per sample |
| | | |
| 0x00000010 | G.726 | |
| | | |
| 0x00000020 | IMA ADPCM | 1 byte per 2 samples |
| | | |
| 0x00000040 | 16-bit linear | 2 bytes per sample |
| | little-endian | |
| | | |
+------------+-----------------+------------------------------------+
| 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-byte chunks of 172 samples |
| | | |
| 0x00000200 | Speex | Variable |
| | | |
| 0x00000400 | ILBC | 50 bytes per 240 samples |
| | | |
| 0x00000800 | G.726 AAL2 | |
| | | |
| 0x00001000 | G.722 | 16 kHz ADPCM |
| | | |
| 0x00002000 | AMR | Variable |
| | | |
| 0x00010000 | JPEG | |
| | | |
| 0x00020000 | PNG | |
| | | |
| 0x00040000 | H.261 | |
| | | |
| 0x00080000 | H.263 | |
| | | |
| 0x00100000 | H.263p | |
| | | |
| 0x00200000 | H.264 | |
+------------+-----------------+------------------------------------+
| 0x00000080 | LPC10 | Variable size frame of 172 samples |
| | | |
| 0x00000100 | G.729 | 20-byte chunks of 172 samples |
| | | |
| 0x00000200 | Speex | Variable |
| | | |
| 0x00000400 | ILBC | 50 bytes per 240 samples |
| | | |
| 0x00000800 | G.726 AAL2 | |
| | | |
| 0x00001000 | G.722 | 16 kHz ADPCM |
| | | |
| 0x00002000 | AMR | Variable |
| | | |
| 0x00010000 | JPEG | |
| | | |
| 0x00020000 | PNG | |
| | | |
| 0x00040000 | H.261 | |
| | | |
| 0x00080000 | H.263 | |
| | | |
| 0x00100000 | H.263p | |
| | | |
| 0x00200000 | H.264 | |
+------------+-----------------+------------------------------------+
Refer to the IANA Registry for any additional IAX Media Format values.
有关任何其他IAX媒体格式值，请参阅IANA注册表。
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.
本节包括一些可以进行的各种IAX调用的调用流程图。在每个图中，'='字符表示完整帧，'-'字符表示迷你帧。适用于一般调用的注释可与每个图表一起显示。
PING->PONG
乒乓球
Peer A Peer B
________________________________________
| |
T | |
i | ===PING============================> |
m | |
e | <============================PONG=== |Has same time-stamp
| | as received PING.
| | ===ACK=============================> |Has same time-stamp
| | | as received PONG
\ / |________________________________________| and original PING.
Peer A Peer B
________________________________________
| |
T | |
i | ===PING============================> |
m | |
e | <============================PONG=== |Has same time-stamp
| | as received PING.
| | ===ACK=============================> |Has same time-stamp
| | | as received PONG
\ / |________________________________________| and original PING.
LAGRQ->LAGRP
LAGRQ->LAGRP
Peer A Peer B
________________________________________
| |
T | |
i | ===LAGRQ===========================> |
m | |
e | <===========================LAGRP=== |Same time-stamp as
| | received LAGRQ.
| | ===ACK=============================> |Same time-stamp as
| | | received LAGRP and
\ / |________________________________________| original LAGRQ.
Peer A Peer B
________________________________________
| |
T | |
i | ===LAGRQ===========================> |
m | |
e | <===========================LAGRP=== |Same time-stamp as
| | received LAGRQ.
| | ===ACK=============================> |Same time-stamp as
| | | received LAGRP and
\ / |________________________________________| original LAGRQ.
Registration of an IAX Peer
IAX对等机的注册
Registrant A Registrar B
________________________________________
| |
T | ===REGREQ==========================> |
i | |
m | <=========================REGAUTH=== |
e | |
| ===REGREQ==========================> |
| | |
| | <==========================REGACK=== |
\ | / | |
\|/ | ===ACK=============================> |
| |
|________________________________________|
Registrant A Registrar B
________________________________________
| |
T | ===REGREQ==========================> |
i | |
m | <=========================REGAUTH=== |
e | |
| ===REGREQ==========================> |
| | |
| | <==========================REGACK=== |
\ | / | |
\|/ | ===ACK=============================> |
| |
|________________________________________|
Registration Release
登记放行
Registrant A Registrar B
________________________________________
| |
T | ===REGREL==========================> |
i | |
m | <=========================REGAUTH=== |
e | |
| ===REGREL==========================> |
| | |
| | <==========================REGACK=== |
\ | / | |
\|/ | ===ACK=============================> |
| |
|________________________________________|
Registrant A Registrar B
________________________________________
| |
T | ===REGREL==========================> |
i | |
m | <=========================REGAUTH=== |
e | |
| ===REGREL==========================> |
| | |
| | <==========================REGACK=== |
\ | / | |
\|/ | ===ACK=============================> |
| |
|________________________________________|
IAX Transfer
IAX传输
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
| |
|________________________________________|
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
| |
|________________________________________|
Complete end-to-end IAX media exchange
完成端到端IAX媒体交换
Peer A Peer B
________________________________________
| |
| ====NEW============================> |
T | <=========================AUTHREQ=== |If authentication
| | specified.
i | ====AUTHREP========================> |
m | <==========================ACCEPT=== |
e | ====ACK============================> |
| |
| | <=============Voice (Full Frame)=== |
| | ====ACK===========================> |
| | |
| | <---------Voice Mini Frame (ring)-- |
| | <---------Voice Mini Frame (ring)-- |
| | |
\ | / | <=========================RINGING=== |
\|/ | ====ACK============================> |
| |
| <---------Voice Mini Frame (ring)-- |
| <---------Voice Mini Frame (ring)-- |
| |
| <==========================ANSWER=== |
| ====ACK============================> |
| |
| ====Voice (Full Frame)=============> |
| <=============================ACK=== |
| |
| |
| <-----------Voice Mini Frames------> | exchange occurs
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====Voice (Full Frame)=============> | (note 1)
| <===ACK============================= | (note 2)
| | (every 65536 ms)
| <=============Voice (Full Frame)==== | (note 3)
| ====ACK============================> |
| |
| |
Peer A Peer B
________________________________________
| |
| ====NEW============================> |
T | <=========================AUTHREQ=== |If authentication
| | specified.
i | ====AUTHREP========================> |
m | <==========================ACCEPT=== |
e | ====ACK============================> |
| |
| | <=============Voice (Full Frame)=== |
| | ====ACK===========================> |
| | |
| | <---------Voice Mini Frame (ring)-- |
| | <---------Voice Mini Frame (ring)-- |
| | |
\ | / | <=========================RINGING=== |
\|/ | ====ACK============================> |
| |
| <---------Voice Mini Frame (ring)-- |
| <---------Voice Mini Frame (ring)-- |
| |
| <==========================ANSWER=== |
| ====ACK============================> |
| |
| ====Voice (Full Frame)=============> |
| <=============================ACK=== |
| |
| |
| <-----------Voice Mini Frames------> | exchange occurs
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====Voice (Full Frame)=============> | (note 1)
| <===ACK============================= | (note 2)
| | (every 65536 ms)
| <=============Voice (Full Frame)==== | (note 3)
| ====ACK============================> |
| |
| |
| <-----------Voice Mini Frames------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====HANGUP=========================> | Either can hangup
| <=============================ACK=== |
|________________________________________|
| <-----------Voice Mini Frames------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====HANGUP=========================> | Either can hangup
| <=============================ACK=== |
|________________________________________|
Note 1: Mini Frames carry the low 16 bits of the peer's 32-bit time-stamp. Note 2: Full frames resync the 32-bit time-stamp when the 16-bit time-stamp overflows. Note 3: Each side has its own 32-bit time-stamp so each side needs to sync at 16-bit overflow.
注1：小帧携带对等方32位时间戳的低16位。注2：当16位时间戳溢出时，全帧重新同步32位时间戳。注3：每边都有自己的32位时间戳，因此每边都需要在16位溢出时同步。
An IAX peer is not required to maintain a complete dialplan. In the event that a user wishes to dial from an IAX peer that does not switch its own calls, the following call flow diagram may represent the transaction:
IAX对等机不需要维护完整的拨号计划。如果用户希望从不切换自己呼叫的IAX对等方拨号，则以下呼叫流程图可能表示该事务：
Peer A (IAX Device) Peer B (Dialplan Server)
________________________________________
| |
| ====NEW============================> |
T | <=========================AUTHREQ=== | If auth specified
i | ====AUTHREP========================> |
m | <==========================ACCEPT=== |
e | ====ACK============================> |
| |
| ====DPREQ==========================> | (Note 1)
| | <===========================DPREP=== |
| | |
| | ====DIAL===========================> |
| | <========================PROGRESS=== |
| | ====ACK============================> |
\ | / | <==========================ANSWER=== |
\|/ | ====ACK============================> |
| |
| ====Voice (Full Frame)=============> |
| <=============================ACK=== |
| <=============Voice (Full Frame)==== |
| ====ACK============================> |
| |
| |
| <-----------Voice Mini Frames------> | Media exchange
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====Voice (Full Frame)=============> | (note 2)
| <===ACK============================= | (note 3)
| | (every 65536 ms)
| <=============Voice (Full Frame)==== | (Note 4)
| ====ACK============================> |
| |
| |
| <-----------Voice Mini Frames------> |
| <--- . ---> |
Peer A (IAX Device) Peer B (Dialplan Server)
________________________________________
| |
| ====NEW============================> |
T | <=========================AUTHREQ=== | If auth specified
i | ====AUTHREP========================> |
m | <==========================ACCEPT=== |
e | ====ACK============================> |
| |
| ====DPREQ==========================> | (Note 1)
| | <===========================DPREP=== |
| | |
| | ====DIAL===========================> |
| | <========================PROGRESS=== |
| | ====ACK============================> |
\ | / | <==========================ANSWER=== |
\|/ | ====ACK============================> |
| |
| ====Voice (Full Frame)=============> |
| <=============================ACK=== |
| <=============Voice (Full Frame)==== |
| ====ACK============================> |
| |
| |
| <-----------Voice Mini Frames------> | Media exchange
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====Voice (Full Frame)=============> | (note 2)
| <===ACK============================= | (note 3)
| | (every 65536 ms)
| <=============Voice (Full Frame)==== | (Note 4)
| ====ACK============================> |
| |
| |
| <-----------Voice Mini Frames------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====HANGUP=========================> | Either can hangup
| <=============================ACK=== |
|________________________________________|
| <--- . ---> |
| <--- . ---> |
| <-----------Voice Mini Frames------> |
| |
| |
| ====HANGUP=========================> | Either can hangup
| <=============================ACK=== |
|________________________________________|
Note 1: There will be multiple DPREQ/DPREPs per call unless dialed number is 1 digit long. Note 2: Mini Frames carry the low 16 bits of the peer's 32-bit time-stamp. Note 3: Full Frames resync the 32-bit time-stamp when the 16 bit time-stamp overflows. Note 4: Each side has its own 32-bit time-stamp so each side needs to sync at 16-bit overflow.
注1：除非所拨号码为1位数，否则每次通话将有多个DPREQ/DPREP。注2：小帧携带对等方32位时间戳的低16位。注3：当16位时间戳溢出时，全帧重新同步32位时间戳。注4：每侧都有自己的32位时间戳，因此每侧需要在16位溢出时同步。
IAX is a binary protocol for setting up point-to-point call legs that include both media and signaling. As such, it is simpler to secure than other more general purpose VoIP protocols; however, security remains a difficult task and various aspects of the protocol must be examined to identify risks.
IAX是一种二进制协议，用于设置包括媒体和信令的点对点呼叫分支。因此，它比其他更通用的VoIP协议更容易保护；然而，安全仍然是一项艰巨的任务，必须检查协议的各个方面，以确定风险。
IAX registration is an area that requires careful attention. Previous protocol versions supported cleartext passwords; this feature has been eliminated. The MD5 and RSA alternatives offer much higher security. Although not specified by the IAX protocol, some implementations limit the number of registrants per account to one. A subsequent registrant with the same credentials would overwrite the prior and receive the calls destined for that user. Theft of service is trivial once a malicious caller has the ability to authenticate. In addition, since distinct cause codes are returned to erroneous registration attempts, an attacker can distinguish between existent and nonexistent users in a registration system, thus resulting in a possible directory harvest attack.
IAX注册是一个需要仔细关注的领域。以前的协议版本支持明文密码；此功能已被删除。MD5和RSA替代方案提供了更高的安全性。虽然IAX协议没有规定，但一些实现将每个帐户的注册人数限制为一个。具有相同凭据的后续注册人将覆盖之前的注册人，并接收以该用户为目的地的呼叫。一旦恶意调用方能够进行身份验证，盗用服务就很容易了。此外，由于错误的注册尝试会返回不同的原因代码，因此攻击者可以区分注册系统中存在的用户和不存在的用户，从而导致可能的目录捕获攻击。
The IAX protocol protects against message replay by using a challenge response method. The IAX registrar or server challenges each call or registration with an arbitrary MD5 or RSA challenge. The response and subsequent authorization relies upon knowledge of a shared secret. Since the server typically chooses a challenges using a random-number-based technique, the challenge set is large, making replay highly unlikely.
IAX协议使用质询-响应方法防止消息重播。IAX注册器或服务器使用任意MD5或RSA质询对每个呼叫或注册进行质询。响应和后续授权依赖于对共享秘密的了解。由于服务器通常使用基于随机数的技术选择挑战，因此挑战集很大，使得重播极不可能。
Although operation in the following manner is not recommended, the IAX protocol does permit servers to forego the challenge process described above. This open approach is inherently insecure and does nothing to prevent unauthorized usage.
虽然不建议以以下方式操作，但IAX协议允许服务器放弃上述质询过程。这种开放式方法本质上是不安全的，不能防止未经授权的使用。
Call Encryption in IAX starts by utilizing static keys. Once negotiated, the key may be changed for the remainder of the call. Once the initial key is compromised, all subsequent calls are subject to interception. A more secure implementation would update the key frequently and as early as practical during each call.
IAX中的调用加密从使用静态密钥开始。一旦协商，就可以为剩余的调用更改密钥。一旦初始密钥被泄露，所有后续呼叫都会被拦截。更安全的实现将在每次调用过程中尽早频繁地更新密钥。
The IAX protocol is also susceptible to eavesdropping. Call Detail, i.e., who is calling whom, is sent in unencrypted binary whether or not the call is to be encrypted. Without encryption, call content, i.e., audio and video, may be easily intercepted. However, this content is protected if the call is encrypted.
IAX协议也容易被窃听。呼叫详细信息，即谁在呼叫谁，以未加密的二进制文件发送，无论呼叫是否要加密。如果不加密，通话内容（即音频和视频）可能很容易被截获。但是，如果呼叫被加密，则此内容将受到保护。
Man-in-the-middle attacks are a threat to IAX if encryption is not used. This form of attack permits message insertion, deletion, and modification such that a call may be redirected or the audio or video replaced in either or both directions for the complete or any portion of a call. If encryption is used, the call is protected end to end. Note: an initial NEW message in an encrypted call is unencrypted and could be changed; however, this is limited to a denial-of-service (DoS) attack because subsequent messages containing the same address information are redelivered in an encrypted form.
如果不使用加密，中间人攻击将对IAX构成威胁。这种形式的攻击允许插入、删除和修改消息，从而可以重定向呼叫，或者在呼叫的一个或两个方向上替换音频或视频，以完成呼叫或呼叫的任何部分。如果使用加密，则呼叫端到端受到保护。注意：加密呼叫中的初始新消息是未加密的，可以更改；但是，这仅限于拒绝服务（DoS）攻击，因为包含相同地址信息的后续邮件将以加密形式重新传递。
DoS attacks can take at least two forms in IAX. One is simply overloading the peers with bogus requests. A carefully implemented IAX peer would identify this situation and raise an alarm or take other protective action.
拒绝服务攻击在IAX中至少有两种形式。一种是简单地用虚假请求重载对等方。仔细实施的IAX对等方将识别这种情况并发出警报或采取其他保护措施。
Another form of DoS against an existing call is an engineered attack against an existing call. Injecting media, causing excess processing by inserting out-of-order packets, and sending commands such as hangup or transfer. These attacks require close monitoring of the binary channel to be successful as the message sequence numbers would need to be synchronized with the protocol exchange.
针对现有呼叫的另一种拒绝服务形式是针对现有呼叫的工程攻击。注入介质，通过插入无序数据包和发送诸如挂断或传输等命令，导致过度处理。这些攻击需要密切监视二进制通道才能成功，因为消息序列号需要与协议交换同步。
Of course, providing lower-layer security with Datagram Transport Layer Security (DTLS) [RFC4347], or IPsec [RFC4301], would address many of these potential issues.
当然，通过数据报传输层安全性（DTLS）[RFC4347]或IPsec[RFC4301]提供低层安全性可以解决许多潜在问题。
Unicode [RFC3629] and stringprep [RFC3454] security considerations also apply.
Unicode[RFC3629]和stringprep[RFC3454]安全注意事项也适用。
In order to facilitate the orderly extension of the IAX protocol, several IANA registries have been created. These registry requests are found in [RFC5457]. In addition, the "iax" URI scheme has been registered; see Section 5. Also, IAX has been assigned a well-known UDP port number (4569).
为了促进IAX协议的有序扩展，已经创建了几个IANA注册中心。这些注册表请求可在[RFC5457]中找到。此外，“iax”URI方案已经注册；见第5节。此外，IAX还被分配了一个众所周知的UDP端口号（4569）。
The original IAX implementation was in Asterisk, the open-source PBX, but [wikipedia] lists thirteen other publicly available implementations at the time of this writing. Some of these implementations used draft versions of this specification. Many others were developed using the Asterisk source code as the only specification. While this approach is definitive, it is very difficult to determine the protocol's higher-level logic and optimize it for the particular programming language or application environment. Interoperability of these implementations cannot be guaranteed.
最初的IAX实现是在开源PBX Asterisk中实现的，但在撰写本文时，[wikipedia]列出了13个其他公开可用的实现。其中一些实现使用了本规范的草稿版本。其他许多是使用星号源代码作为唯一规范开发的。虽然这种方法是确定的，但很难确定协议的高级逻辑并针对特定编程语言或应用程序环境对其进行优化。无法保证这些实现的互操作性。
Aside from the trials and tribulations of reverse engineering the source code to create a new implementation, the key lessons learned involve the use of threads, support of international character sets, security, and improved controls to limit interference during DoS attacks.
除了对源代码进行反向工程以创建新的实现的尝试和磨难之外，所学到的关键经验还包括使用线程、支持国际字符集、安全性以及改进控制以限制DoS攻击期间的干扰。
The current Asterisk implementation has a limited number of IAX worker threads and, as a result, its scalability is limited, but it can run on low end machines where threads may not be freely available. Improving the threading model will undoubtedly improve performance.
当前Asterisk实现的IAX工作线程数量有限，因此其可扩展性有限，但它可以在线程可能无法免费使用的低端计算机上运行。改进线程模型无疑会提高性能。
Internationalization and localization are issues that were not originally addressed by most implementations. It was always on the IAX developers' road map, but never a priority. While creating this document, we formalized support for UTF-8 encoding to better support internationalization and localization.
国际化和本地化是大多数实现最初没有解决的问题。它总是在IAX开发者的路线图上，但从来没有优先考虑。在创建本文档时，我们正式支持UTF-8编码，以更好地支持国际化和本地化。
With regards to security, many IAX implementations permit cleartext authentication. This method is not secure and should not be used.
关于安全性，许多IAX实现允许明文身份验证。此方法不安全，不应使用。
Recently, some issues have been raised regarding server robustness when under a DoS attack. IAX servers that support unauthenticated requests can receive the equivalent of a SYN attack. To mitigate the impact of these attacks, various controls to limit the number of unauthenticated calls and the number of calls per user may be added
最近，在受到DoS攻击时，出现了一些关于服务器健壮性的问题。支持未经验证的请求的IAX服务器可能会收到相当于SYN攻击的攻击。为了减轻这些攻击的影响，可能会添加各种控制来限制未经验证的呼叫数量和每个用户的呼叫数量
to the implementation. Other approaches, such as transferring the call to another, more protected port or using IP rate limiting when excessive failures are detected, are also suggested.
对执行的影响。还建议使用其他方法，例如将呼叫转移到另一个受保护的端口，或者在检测到过度故障时使用IP速率限制。
Lastly, given the open nature of the protocol and implementations, it is very easy to extend. This situation makes Postel's Robustness Principle, "Be conservative in what you do, be liberal in what you accept from others", essential to any successful IAX implementation.
最后，考虑到协议和实现的开放性，它很容易扩展。这种情况使得Postel的健壮性原则“在你所做的事情上保持保守，在你从他人那里接受的事情上保持自由”，对于任何成功的IAX实现都至关重要。
This work was supported by Internet Foundation Austria. The authors would like to thank Birgit Arkesteijn, Marc Blanchet, Mohamed Boucadair, Steve Kann, Olle Johansson, Alexander Mayrhofer, Tim Panton, and Peter Saint-Andre for their extensive review and technical input. We would also like to thank Jim Dalton, Christopher DeMarco, Frank Ellermann, Daniel Medeiros, Dimitri E. Prado, Leif Madson, and Tilghman Lesher for their support and suggestions.
这项工作得到了奥地利互联网基金会的支持。作者要感谢Birgit Arkesteijn、Marc Blanchet、Mohamed Boucadair、Steve Kann、Olle Johansson、Alexander Mayrhofer、Tim Panton和Peter Saint Andre的广泛评论和技术投入。我们还要感谢Jim Dalton、Christopher DeMarco、Frank Ellermann、Daniel Medeiros、Dimitri E.Prado、Leif Madson和Tilghman Lesher的支持和建议。
[AES] U.S. Department of Commerce/N.I.S.T., "FIPS-197, Announcing the Advanced Encryption Standard", November 2001.
[AES]美国商务部/N.I.S.T.，“FIPS-197，宣布高级加密标准”，2001年11月。
[E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[E164]ITU-T，“国际公共电信号码计划”，建议E.164，1997年5月。
[OSP] European Telecommunications Standards Institute, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization and usage exchange", November 2003.
[OSP]欧洲电信标准协会，“网络上的电信和互联网协议协调（TIPHON）第4版；域间定价、授权和使用交换的开放结算协议（OSP）”，2003年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995.
[RFC1851]Karn，P.，Metzger，P.，和W.Simpson，“ESP三重DES变换”，RFC 18511995年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，2003年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]Phillips，A.和M.Davis，“语言标记的匹配”，BCP 47，RFC 4647，2006年9月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.，Ed.，和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，2009年9月。
[html401] Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[html401]Jacobs，I.，Raggett，D.，和A.Hors，“HTML 4.01规范”，万维网联盟建议REC-html401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[PKCS] RSA Laboratories, "PKCS #1 v2.0: RSA Cryptography Standard", October 1998.
[PKCS]RSA实验室，“PKCS#1 v2.0：RSA加密标准”，1998年10月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435]Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）1.0版”，RFC 3435，2003年1月。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525]Groves，C.，Pantaleo，M.，Anderson，T.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733]Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年12月。
[RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.
[RFC4734]Schulzrinne，H.和T.Taylor，“调制解调器、传真和文本电话信号事件的定义”，RFC 47342006年12月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]Taylor，T.，“将RFC 3525重新分类为历史”，RFC 51252008年2月。
[RFC5457] Guy, E., "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", RFC 5457, February 2010.
[RFC5457]Guy，E.“IAX的IANA注意事项：星号间交换版本2”，RFC 5457，2010年2月。
[wikipedia] Wikipedia, "Inter-Asterisk eXchange", <http://en.wikipedia.org/wiki/IAX>.
[维基百科]维基百科，“星号交换”<http://en.wikipedia.org/wiki/IAX>.
Authors' Addresses
作者地址
Mark A. Spencer Digium, Inc. 445 Jan Davis Drive NW Huntsville, AL 35806 US
马克·斯宾塞·迪吉姆公司，地址：美国阿拉巴马州亨茨维尔西北詹戴维斯大道445号，邮编：35806
Phone: +1 256 428 6000
EMail: markster@digium.com
URI: http://www.digium.com/
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
Brian Capouch Saint Joseph学院邮政信箱909 Rensselaer，美国47978
Phone: +1 219 866 6114
EMail: brianc@saintjoe.edu
Phone: +1 219 866 6114
EMail: brianc@saintjoe.edu
Ed Guy (editor) Truphone 12 Williams Rd Chatham, NJ 07928 US
Ed Guy（编辑）美国新泽西州查塔姆威廉姆斯路12号Truphone 07928
Phone: +1 973 437 4519
EMail: edguy@emcsw.com
URI: http://www.truphone.com/
Phone: +1 973 437 4519
EMail: edguy@emcsw.com
URI: http://www.truphone.com/
Frank Miller Cornfed Systems, LLC 3476 Dayton Street Denver, CO 80238 US
Frank Miller Cornfed Systems，LLC美国科罗拉多州丹佛代顿街3476号，邮编80238
Phone: +1 410 404-8790
EMail: mail@frankwmiller.net
URI: http://www.sipuseragent.net
Phone: +1 410 404-8790
EMail: mail@frankwmiller.net
URI: http://www.sipuseragent.net
Kenneth C. Shumard 3818 N Lakegrove Way Boise, ID 83713 US
肯尼斯·C·舒马尔3818北莱克格罗夫路博伊西，美国身份证83713号
Phone: +1 208 724 7801
EMail: kshumard@gmail.com
Phone: +1 208 724 7801
EMail: kshumard@gmail.com