[要約] RFC 5456はIAX（Inter-Asterisk eXchange）バージョン2に関する仕様であり、IAXプロトコルの機能と動作を定義しています。目的は、異なるAsterisk PBXシステム間での音声通信や信号制御を可能にするための標準化です。
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プロトコル、インターネットプロトコル（IP）ネットワーク経由でマルチメディアセッションを作成、変更、および終了するためのアプリケーション層制御とメディアプロトコルについて説明します。 IAXは、Asterisk Private Branch Exchange（PBX）のオープンソースコミュニティによって開発され、主にVoice over Internet Protocol（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は、帯域幅の使用を減らすコンパクトなエンコーディングを採用しており、インターネットテレフォニーサービスに適しています。さらに、そのオープンな性質により、追加のサービスをサポートするために必要な新しいペイロードタイプを追加できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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 Note
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
この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、MUSIC、およびAVT WGで行われたIETF作業に関連していると考えていますが、これは公開を妨げるものではありません。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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]、Media Gateway Control Protocol（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は、従来の標準ベースの方法論ではなく、オープンソースの方法論によって作成されました。これは、Digiumのデュアルライセンスのオープンソースおよび商用PBXサーバーであるAsteriskによって最初に使用されたオープンプロトコルです。独立した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 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.
IAXは堅牢でフル機能を備えた、しかもシンプルなプロトコルです。ほとんどの一般的なタイプのメディアストリームを処理できるほど一般的です。ただし、プロトコルは、低オーバーヘッドと低帯域幅の消費が優先されるVoIPコール用に高度に最適化されています。この実用的な側面により、IAXは現在のニーズをはるかに超えた可能性を考慮し、ポイントツーポイントコールを説明または転送するために厳密に必要な詳細よりも多くの詳細を指定するプロトコルよりもVoIPに対して効率的です。さらに、IAXは軽量でVoIPに対応するように設計されているため、より一般的なアプローチよりも消費する帯域幅が少なくなります。 IAXは、特に音声ストリームに関して、オーバーヘッドを減らすように設計されたバイナリプロトコルです。帯域幅効率は、場所によっては、個々の音声通話の帯域幅効率と引き換えに犠牲になります。たとえば、20 msのパケット化で8 kbit / sに圧縮された音声ストリームを送信する場合、各データパケットは20バイトで構成されます。 IAXは、音声パケットの大部分で20％のオーバーヘッド、4バイトを追加しますが、RTPは、音声パケットあたり12バイトを追加して60％のオーバーヘッドを追加します。
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の基本構造は、2つのコンピューター間で単一の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の設計の強みの1つにも潜在的な問題があります。よく知られた単一のポートを使用することで、プロトコルはサービス拒否攻撃の標的となりやすくなります。 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
通話：通話とは、リアルタイムメディアを交換する目的で一定期間存在する2つ以上の関係者（デバイス、ユーザーエージェント、プログラムなどのリソース）間の関係です。このドキュメントのコンテキストでは、コールはエンドツーエンドの関係であり、コールパスの少なくとも1つのレッグはIAXプロトコルを使用して実装されます。
Calling Party: A device or program that initiates a call.
Calling Party：通話を開始するデバイスまたはプログラム。
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.
フレーム：2つの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.
登録者：AN登録者は、リソース（つまり、コールが転送されるデバイスまたはプログラム）のアドレスを通知するためにREGISTER要求を行うピアです。
Registrar: A registrar is a peer that processes REGISTER requests and places the information it receives in those requests into the location service. [RFC3261].
レジストラ：レジストラは、REGISTERリクエストを処理し、それらのリクエストで受信した情報をロケーションサービスに配置するピアです。 [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 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は、ピアツーピアのVoIP指向プロトコルです。 IAXには、制御機能とメディア機能の両方が含まれています。場所の登録、マルチメディアセッションの作成、変更、終了、および管理するセッションで指定された実際のメディアストリームの伝送を行うことができます。このプロトコルは、インターネットプロトコルを使用してマルチメディアコールを記述および転送するために設計および最適化されています。このドキュメントでは、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].
2つのホスト間の単一のUDPアソシエーションを介したIAX多重化シグナリングおよび複数のメディアストリームの基本設計アプローチ。これは、すべてのタイプのIAXトラフィックに対して同じ「既知の」UDPポート4569を使用することで実現されます。 IAXの統合シグナリングとメディアパスはNAT透過性を実現します。これは、SIP [RFC3261]などの代替メディアトランスポートプロトコルに対するIAXの利点です。
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はバイナリプロトコルとしてコード化されます。音声通話の品質は、消費される帯域幅の量に関連することが多いため、バイナリプロトコルを使用する主な利点の1つは、帯域幅の効率です。これは、個々の音声通話の帯域幅を効率的に使用するためにプロトコルが特に最適化される方法の1つです。他のストリームタイプの帯域幅効率は、個々の音声コールのために犠牲になります。バイナリプロトコルの他の利点は、バッファオーバーラン攻撃に対する堅牢性と、解析に関連する相互運用性の問題を軽減するコンパクトな実装機能です。
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）を囲みます。 IEは、さまざまなタイプのユーザー固有または呼び出し固有のデータを記述します。 「メタフレーム」は、コールトランキングまたはビデオストリーム伝送に使用されます。
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は、必ずしもエンドツーエンドの呼び出しではなく、完全な呼び出しパスの1つ以上のレッグを設定する責任があります。
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は、最適化されたピアツーピアプロトコルです。隣接する2つのコールレッグが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.
コール識別子：コールレッグは2つの一意の整数でマークされ、1つはコールレッグの作成に関与する各ピアによって割り当てられます。
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]に従ってそのダイヤルプランを定義してもよい（MAY）。ただし、これは必須ではありません。
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]]
where these tokens have the following meanings:
これらのトークンの意味は次のとおりです。
iax: The literal 'iax:'.
iax：文字通りの 'iax：'。
username: A string used for identification purposes.
username：識別のために使用される文字列。
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.
host：リソースのドメイン。ホスト部分には、完全修飾ドメイン名または数値のIPv4またはIPv6アドレスが含まれます。 [RFC3986]で定義されているように、IPv6アドレスは角かっこで囲む必要があります（つまり、[[2001：db8 :: 1] '）。可能な限り、完全修飾ドメイン名形式を使用することをお勧めします。
port: The numeric UDP port number.
port：数値のUDPポート番号。
number: The name or number identifying the resource on that host.
number：そのホスト上のリソースを識別する名前または番号。
context: The name of the host partition in which the service is identified or processed.
コンテキスト：サービスが識別または処理されるホストパーティションの名前。
Examples
iax:example.com/alice
iax:example.com:4569/alice
iax:example.com:4570/alice?friends
iax:192.0.2.4:4569/alice?friends
iax:[2001:db8::1]:4569/alice?friends
iax:example.com/12022561414
iax:johnQ@example.com/12022561414
ABNF Formal syntax is defined using ABNF [RFC5234]. Certain values are included by reference from [RFC3986]:
ABNF形式構文は、ABNF [RFC5234]を使用して定義されます。 [RFC3986]からの参照により、特定の値が含まれています。
iax-uri = "iax:" [ userinfo "@" ] host [ ":" port ]
[ "/" number [ "?" context ] ]
userinfo = <as specified in RFC 3986>
host = <as specified in RFC 3986>
port = <as specified in RFC 3986>
number = *(unreserved / sub-delims / pct-encoded )
context = *(unreserved / sub-delims / pct-encoded )
unreserved = <as specified in RFC 3986>
sub-delims = <as specified in RFC 3986>
pct-encoded = <as specified in RFC 3986>
URI Scheme Semantics:
うり Ｓちぇめ せまんちｃｓ：
An IAX URI identifies a communications resource capable of communicating using the IAX Version 2 protocol defined in this document. Within this document, we refer to IAX Version 2 protocol URI as IAX. An IAX URI contains enough information to initiate an IAX-based call with that resource.
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スキームは、前のセクションで説明したURIスキームコンポーネントを使用して新しい呼び出しを確立するために、IAXプロトコルが使用できる場所に変換されます。この新しい呼び出し関数は、定義されている唯一の操作です。
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.
このスキームは、IAMプロトコルをサポートするリソースを指定するためにENUM動的委任発見システム（DDDS）サービスによって使用されます。 IAXプロトコルは、インターネットプロトコル（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.
Ed Guy、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:
この仕様の一部の操作では、2つの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: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
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.
メッセージは、信頼性と非保証性の2つのカテゴリに分類されます。信頼性の高いメッセージは、「フルフレーム」と呼ばれます。信頼性を確保するためのメッセージタイプインジケータと機能に加えて、セクション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ピアに到達できるようにするには、呼び出し側ピアが受信側ピアのネットワークアドレスを必要とします。このアドレスは手動でプロビジョニングされ、共有ディレクトリを通じて決定されます。 ENUMのようなサービス、[RFC3761]、またはIAXプロトコルを使用して構成されます。 IAXは、1つのピアがそのアドレスと資格情報を別のピアに登録して、呼び出し元が登録者に到達できるようにする機能を提供します。 IAX登録機能はオプションです。実装される場合、IAX登録プロトコルは部分的に実行される場合があります。たとえば、アナログ電話アダプタは、プロトコルの登録者部分のみを実装できます（MAY）。
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
__________
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 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.
図1に示す登録は、ユーザー名と登録の「更新」期間をレジストラに送信する登録者によって実行されます。これは、REGREQメッセージで行われます。認証が必要な場合、レジストラは、レジストラがサポートする認証の種類を示すREGAUTHメッセージで応答します。応答として、登録者はサポートされている認証の1つでREGREQを再送信します。登録者が認証できない場合、それ以上のアクションは必要ありません。受け入れられた場合、レジストラはREGACKメッセージを送信します。このメッセージは、「見かけのアドレス」を示す必要があり、「更新」/有効期限を示す必要があります（SHOULD）。 'refresh'が送信されない場合、両方のピアがデフォルトの登録有効期限である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.
登録には、有効な有効期間が関連付けられています。この期間は、レジストラがREGACKメッセージを送信したときに始まります。登録者は、登録プロセスを繰り返すことにより、その期間を延長できます。登録者は、REGRELメッセージを送信することにより、レジストラでの有効期限も強制的に設定できます（MAY）。このメッセージはREGAUTHでチャレンジされる場合があります。十分な資格情報が含まれている場合は、REGACKで受け入れられます。 REGAUTHに応答して、REGRELメッセージは、指定された資格情報を使用して再送信する必要があります（SHOULD）。
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には「username」IEを含める必要があり、「refresh」IEを含める必要があります（SHOULD）。 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:
次の表は、このメッセージのIEを示しています。
+------------+----------------+-------------+-------------+
| 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への応答です。レジストラが登録を許可するために認証を必要とするときに送信されます。 REGAUTHメッセージには、「認証方法」と「ユーザー名」IE、および認証方法にMD5またはRSAが含まれている場合は「MD5チャレンジ」または「RSAチャレンジ」IEを含める必要があります。
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メッセージを受信すると、登録者は、指定された資格情報がある場合、要求された資格情報の1つを使用してREGREQまたはREGRELメッセージを再送信する必要があります。
Registrars MUST implement this message and registrants MUST be able to process it.
レジストラはこのメッセージを実装する必要があり、登録者はそれを処理できる必要があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+--------------+----------------+-------------+---------------+
| 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 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.
REGACKは、REGREQに応答して送信されます。 REGACKには通常、登録の有効期限が切れるまでの秒数を指定する「更新」IEが含まれています。 「リフレッシュ」IEがREGACKに含まれていない場合は、デフォルトの登録有効期限である60秒を想定する必要があります。 REGACKには、ピアが登録者を識別する方法を示す「ユーザー名」および「見かけのアドレス」IEも含まれる場合があります。発信者の識別または登録が行われた時間に関連するIEも送信される場合があります。
Receipt of a REGACK message requires an ACK in response.
REGACKメッセージの受信には、応答として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:
次の表は、このメッセージのIEを示しています。
+------------------+----------------+----------+----------+
| 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には、「原因コード」および「原因」IEを含めて、登録が拒否された理由を指定する必要があります。
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.
REGREJメッセージを受信すると、登録者は登録プロセスが失敗したことを考慮しなければならず、それ以上の対話は必要ありません。ピアは、レジストラまたは登録者の潜在的な構成変更を考慮して、後でプロセスを再開できます（MAY）。
Both registrants and registrars MUST be capable of sending and processing this message.
登録者とレジストラの両方がこのメッセージを送信および処理できる必要があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+------------+----------------+----------+----------+
| 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.
REGRELは、以前の登録を強制的に解除するために登録者によって使用されます。解放される登録者を識別するために「username」IEを含める必要があり、登録が解放される理由を指定するために「causecode」および「cause」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.
このメッセージを受信すると、ピアは、提供された資格情報を使用して送信者を認証するか、それらを要求するREGAUTHメッセージを送信する必要があります。認証された場合、指定された登録者の登録を直ちに削除するか、登録が見つからない場合はREGREJメッセージを送信する必要があります。
Registrants SHOULD be capable of sending this message and registrars MUST be able to process it.
登録者はこのメッセージを送信できなければならず（SHOULD）、レジストラはそれを処理できなければなりません（MUST）。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+----------+----------------+-------------+-------------------------+
| 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
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
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つのピア間に「リンク」または「コールレッグ」を設定するために使用できます。図2および図3に示すプロセスは、ピアがリモートピアの着信側の宛先「番号」（または名前）を示すNEWメッセージを送信すると開始されます。リモートピアは、クレデンシャルチャレンジ（AUTHREQ）、REJECTメッセージ、またはACCEPTメッセージのいずれかで応答できます。 AUTHREQメッセージは、許可された認証方式を示し、SHOULD結果として、要求された資格情報を含むAUTHREPメッセージを送信する必要があります。 REJECTメッセージは、現時点ではコールを確立できないことを示しています。 ACCEPTは、これらの2つのピア間のコールレッグが確立され、より高レベルのコールシグナリング（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.
ACCEPTメッセージ。コールレッグは「リンク」状態にあり、コールが完了するまでコール制御メッセージを渡すために使用されます。このプロセスで使用されるメッセージの詳細については、セクション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.
コールレッグは、1組の識別子でラベル付けされています。コールレッグの両端は、コールレッグの作成プロセス中に送信元または宛先の識別子を割り当てます。
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.
新しいメッセージが送信され、通話が開始されます。これは、2つのピア間の実際のメディア交換を開始するために送信される最初の通話固有のメッセージです。 「NEW」メッセージは、ヘッダーに宛先コールIDを必要としないという点で、他のコール監視メッセージと比較してユニークです。これは、このフレームを受信するまで、リモートピアのソースコール識別子が作成されないためです。 NEWメッセージを送信する前に、ローカルIAXピアは、現在別の呼び出しに使用されていないソース呼び出し識別子を割り当てる必要があります。タイムスタンプも呼び出しに割り当てられる必要があり、0から始まり、ミリ秒ごとに1ずつ増加します。トランスポートセクション（セクション7）で説明されているNEWメッセージのシーケンス番号は、両方とも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でなければなりません。他のIEの順序は指定されていません。 NEW SHOULDは一般に、たとえば「着番号」IEを介してリモートピアでのルーティングを示すため、またはピアパーティションまたはルールセット、「着コンテキスト」IEを示すためにIEを含みます。発信者識別とコーデック交渉IEも含まれる場合があります。
Upon receipt of a NEW message, the receiving peer examines the destination and MUST perform one of the following actions:
NEWメッセージを受信すると、受信ピアは宛先を調べ、次のいずれかのアクションを実行する必要があります。
Send a REJECT response,
REJECT応答を送信します。
Challenge the caller with an AUTHREQ response,
AUTHREQ応答で発信者にチャレンジし、
Accept the call using an ACCEPT message, or
ACCEPTメッセージを使用して通話を受け入れる、または
Abort the connection using a HANGUP message, although the REJECT message is preferred at this point in call.
HANGUPメッセージを使用して接続を中止しますが、この時点ではREJECTメッセージが優先されます。
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.
呼び出しが受け入れられた場合、ピアは呼び出しを進行し、ピア上の呼び出し先のステータスに応じて、PROCEEDING、RINGING、BUSY、またはANSWERのいずれかでさらに応答する必要があります。詳細については、セクション6.3を参照してください。
The following table specifies IEs for the NEW message:
次の表は、NEWメッセージのIEを示しています。
+--------------+----------------+-------------+---------------------+
| 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 | |
+--------------+----------------+-------------+---------------------+
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.
ACCEPT応答は、NEWメッセージが受信され、認証が行われたときに発行されます（必要な場合）。新しいメッセージの受信を確認し、コーデックの割り当てを含め、コールレッグが終端側でセットアップされたことを示します。 ACCEPTメッセージには、発信元のピアに目的のコーデックを示す「フォーマット」IEを含める必要があります。コーデック形式は、関連するNEWコマンドで送信される形式の1つでなければなりません。
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.
ACCEPTを受信すると、ACKを送信する必要があり、コールのコーデックは、受信したACCEPTからの「フォーマット」IEを使用して設定できます。その後、コールはANSWER、HANGUP、またはその他のコール制御信号を待ちます。 （セクション6.3を参照してください。）既に開始されている、またはNEWメッセージを送信していないコールに対して後続のACCEPTメッセージを受信した場合、メッセージは無視する必要があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+--------+---------------+----------+----------+
| 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.)
NEW、AUTHREP、DIAL、またはACCEPT要求が拒否されたことを示すREJECT応答が送信されます。これは、認証の失敗、無効なユーザー名、または発行されたチャレンジへのピアが有効なパスワードまたは応答を提供できない場合に発生する可能性があります。また、たとえば、IAXピアが使用するコーデックをネゴシエートできない場合に、コールセットアップの失敗をピアに通知するために使用される場合があります。 REJECTメッセージを受信すると、コールレッグは破棄され、それ以上のアクションは必要ありません。 （注：REJECTメッセージには明示的なACKが必要です。）
REJECT messages MAY include the 'causecode' and 'cause' IEs to indicate the rejection reason.
REJECTメッセージには、拒否の理由を示す「原因コード」および「原因」IEが含まれる場合があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+------------+----------------+----------+----------+
| 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.
HANGUPメッセージはいずれかのピアによって送信され、コールのティアダウンを示します。呼び出しを終了する理由を示すために、「原因コード」と「原因」IEを含めることができます。 HANGUPメッセージを受信すると、IAXピアはすぐにACKで応答し、最後にコールレッグを破棄する必要があります。コールレッグのHANGUPメッセージが受信された後、そのコールレッグを参照する（つまり、同じ送信元/宛先コール識別子を持つ）受信されたメッセージは、INVALメッセージで応答する必要があります。これは、コールが存在しないため、受信したメッセージが無効であることを示しています。
After sending a HANGUP message, the sender MUST destroy the call and respond to subsequent messages regarding this call with an INVAL message.
HANGUPメッセージを送信した後、送信者は呼び出しを破棄し、この呼び出しに関する後続のメッセージにINVALメッセージで応答する必要があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+------------+----------------+----------+----------+
| 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を含まなければならず（MUST）、AUTHREQに応答してのみ送信されます。 AUTHREPは、ACCEPTまたはREJECTのいずれかの応答を必要とします。
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:
次の表は、このメッセージのIEを示しています。
+------------+----------------+-------------+----------+
| 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メッセージはNEWメッセージに応答して送信されます。 「認証方法」と「ユーザー名」IE、およびMD5またはRSA認証が指定されている場合は「チャレンジ」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:
次の表は、このメッセージのIEを示しています。
+--------------+----------------+----------+----------+
| 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の呼制御メッセージは、他のテレフォニー制御プロトコルに共通のエンドツーエンドのシグナリング機能を提供します。メッセージには、RINGING、ANSWER、BUSY、およびPROCEEDINGが含まれます。これらのメッセージは、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.
NEWメッセージで始まる交換に応答して、通常、最初のコール制御メッセージはRINGINGです。ただし、PROCEEDINGメッセージが先行する場合や、呼び出しが直接ANSWERメッセージに進む場合があります。通話に応答すると、ANSWERメッセージが送信されます。その他の可能性としては、「ビジー」の表示があります。または、着信側のサービスに到達できない場合は、リンクレベルのHANGUPと適切な原因コードを使用して通話が切断されます。
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.
リンクがDIALメッセージで開始された場合、シーケンスはオプションのPROCEEDING、オプションのRINGING、次にANSWERまたはBUSYです。もちろん、リンクレベルHANGUPはいつでも発生する可能性があります。
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制御メッセージに対するさまざまなプライベート拡張が導入されています。そのような拡張機能の1つは、ハムラジオトランシーバーを制御するアプリケーションです。理解されていない制御メッセージを受信するIAXピアは、UNSUPPORTメッセージで応答する必要があります。
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.
PROCEEDINGメッセージは、呼び出し要求が別のネットワーク要素によって処理されているが、まだ呼び出し先に到達していないときに、呼び出し元に送信する必要があります（SHOULD）。
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.
PROCEEDINGメッセージを受信すると、ピアはプロトコル固有のアクションを実行して、この事実を発呼者に通知する必要があります（トーン、ISUP（ISDNユーザーパーツ）Proceedingメッセージなど）。前のコールレッグがIAXプロトコルを使用している場合、PROCEEDINGメッセージをそのピアに送信する必要があります。発信ピアまたはトランスコーディングピアでのこのメッセージの処理は指定されていません。ただし、可能であれば、ステータスが発呼者に表示される場合があります。
The PROCEEDING message does not require any IEs.
PROCEEDINGメッセージはIEを必要としません。
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 RINGINGメッセージは、ピアが着信側に警告していると、ピアが判断したとき、たとえば電話が鳴っているときに、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 RINGINGメッセージを受信すると、ピアは、発呼者がすでにそのような指示を受信していない限り、この指示を発呼者に渡す必要があります。開始ピアの場合、これは通常、リングバックトーンを開始することによって行われます。ただし、多くの実装では、ユーザーの期待に応えるために、リンギングの前にリングバックを開始します。発呼者がIAXプロトコルを使用している場合、RINGINGメッセージをこの呼び出し元に渡す必要があります。
The RINGING message does not require any IEs.
RINGINGメッセージにはIEは必要ありません。
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.
このメッセージは、着信側から送信され、その側が通話要求を受け入れ、発信側と通信していることを示します。このメッセージを受信したら、リングバックやその他の進行トーンを終了し、通信チャネルを開かなければなりません（MUST）。
The ANSWER message does not require any IEs.
ANSWERメッセージにはIEは必要ありません。
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.
FLASHメッセージは、通話中機能を示すために送信されます。その解釈はシステムに依存しており、予期されない場合は無視されるべきです。通常、このメッセージは、応答された通話中に短い回線の中断が発生した場合にのみアナログ電話アダプタから送信されます。
The FLASH message does not require any IEs.
FLASHメッセージはIEを必要としません。
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.
HOLDメッセージは、DIALメッセージを使用して開始されるIAX呼び出しでのみ送信されるべきです（SHOULD）。
The HOLD message does not require any IEs.
HOLDメッセージはIEを必要としません。
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.
UNHOLDメッセージは、HOLDメッセージの後のIAX呼び出しでのみ送信する必要があります（SHOULD）。
The UNHOLD message does not require any IEs.
UNHOLDメッセージはIEを必要としません。
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呼び出しでのみ送信される必要があります。 NEWメッセージを使用して開始される呼び出しでのみ使用する必要があります。
The QUELCH message does not require any IEs.
QUELCHメッセージはIEを必要としません。
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呼び出しでのみ送信する必要があります（SHOULD）。
The UNQUELCH message does not require any IEs.
UNQUELCHメッセージはIEを必要としません。
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.
TRANSFERメッセージにより、受信ピアは指定された別の番号を使用してコールを再開します。受信ピアはこのコールレッグの発信側にある必要があり、新しいコール動作は指定されていません。このメッセージを処理した後、HANGUPメッセージを送信して、コールレッグを切断する必要があります（SHOULD）。
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.
TRANSFERメッセージを送信する場合、コールの転送先の新しい番号をCALLED_NUMBER IEに含める必要があり、CALLED_CONTEXT IEを含める必要があります。コールレッグは他のものには使用しないでください。また、切断する必要があります。
The following table specifies IEs for this message:
次の表は、このメッセージのIEを示しています。
+-----------+---------------+----------+----------------------------+
| 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.
ピアが他の2つのIAXピア間の通話を処理していて、ピアが通話の進行状況、内容、または期間を監視する必要がなくなった場合、他の2つのピアに直接通信するように指示することで、通話から自分自身を削除できます。この呼び出しパスの最適化、つまり「監視付き転送」は、呼び出しがプロセスで失われないようにする方法で行われます。開始ピアは、他の2つのピアが通信していることを確認するまで、プロセスの制御を放棄しません。注：通話に関係する当事者は、この操作を認識していません。純粋にネットワーク操作です。
________________
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.
ピアがこの手順を開始するとき、両方のコールレッグがUP状態である必要があります。つまり、それらはそのコールレッグのACCEPTメッセージを送信または受信している必要があります。まず、他のリモートピアから各ネイバーにアドレスと情報を含むTXREQメッセージを送信します。この手順を実行できる場合は、すべてのチャネル情報を開始ピアと新しいリモートピアの両方に送信し始めます。また、コールレッグのパケット数を示すTXCNTメッセージを新しいリモートピアに送信します。各TXCNTメッセージは、TXACCメッセージで確認されます。ピアは、新しい通信パスを確認したことを示すTXREADYメッセージをイニシエーターに送信して応答します。すべてのリモートピアがイニシエーターにTXREADYメッセージを送信すると、転送は成功し、イニシエーターはTXRELで応答して、通話への関与を終了します。転送プロセス中に2つのリモートピアが通信できない場合、それらは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 | |
+------------------+----------------+----------+----------+
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アドレスデータ構造アドレスです。 Call Number IEは他のリモートピアによって使用されるcallidであり、Transfer 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メッセージを受信すると、ピアは新しく指定されたリモートピアとの通信を試行することによって応答する必要があります。このタスクは、Apparent Addressパラメータで指定されたアドレスのピアに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 IEを含める必要があります。このタイプのメッセージを受信すると、ピアがこのコールレッグの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. |
+----------+----------------+----------+----------------------------+
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 IEを含める必要があります。ピアがこのコールレッグを転送しようとしている場合、このタイプのメッセージを受信すると、ピアは開始ピアへのコール関連メディアの送信を停止し、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. |
+----------+----------------+----------+----------------------------+
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. |
+----------+----------------+----------+----------------------------+
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 | |
+-------------+----------------+----------+----------+
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メッセージは、MEDIA転送プロセスが正常に完了したことを示しています。送信後、このメッセージの処理後、フルフレームは元のシグナリングパスをたどり続けなければならず、メディアフレームは新しくネゴシエートされたパスをたどる必要があります。このスプリットパスプロセスは、コールがHANGUPで終了するか、ピアがコールレッグのTXRELメッセージを受信するまで続きます。ピアは、TXRELメッセージを送信することにより、パスを強制的に再結合できます（MAY）。
It MUST include the following Information Element:
次の情報要素を含める必要があります。
+-------------+----------------+----------+----------+
| 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メッセージはIEを必要としません。
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.
POKEメッセージは、リモート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.
このメッセージにはIEは必要ありません。
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エンドポイントの接続をテストします。 PINGの送信は、通話で着信メディアフレームを受信せずにピア定義の秒数が経過した場合、またはデフォルトで20秒ごとに発生する可能性があります。 PINGを受信するには、確認応答のPONGを送信する必要があります。
This message does not require any IEs.
このメッセージにはIEは必要ありません。
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.
PONGメッセージは、PINGまたはPOKEへの応答です。接続を確認します。レシーバーは、受信したPINGまたはPOKEのタイムスタンプとその時間を使用して、接続の往復時間を決定します。受信ジッター、受信フレーム、遅延、ドロップフレームなど、いくつかのレシーバーレポートIEがPONGに含まれる場合があります。 PONGの受信にはACKが必要です。
This message does not require any IEs.
このメッセージにはIEは必要ありません。
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はラグ要求です。これは、ジッターバッファー（存在する場合）を介してフレームを処理するために使用された時間を含む、2つのIAXエンドポイント間のラグを決定するために送信されます。それはクロックベースのタイムスタンプを必要とし、LAGRQのタイムスタンプをエコーしなければならないLAGRPで応答しなければなりません。 2つのピア間のラグは、LAGRQのタイムスタンプとLAGRPが受信された時間を比較することにより、LAGRQを送信するピアで計算できます。
This message does not require any IEs.
このメッセージにはIEは必要ありません。
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.
このメッセージにはIEは必要ありません。
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 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.
数字ダイヤルサポートは、独自のダイヤルプランを維持しないデバイス（アナログ電話アダプタ、ATAなど）をサポートするように設計されたIAXプロトコルのオプション部分です。 IAXプロトコルのダイヤル部分は、クライアント/電話側、サーバー側、またはすべてではなく実装される場合があります。交換は、一連のダイヤリングプランリクエスト（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は、サーバーが渡された着信番号を分析し、リモートピアに有効なダイヤルパターンがあるかどうかを判断するための要求です。照会する拡張子を指定するために、「着信番号」IEを含める必要があります。このコマンドは、ローカルピアが独自のダイヤルプラン/内線切り替えを処理しない場合に使用されます。ローカルピアは、リモートピアが「着信番号」をどのように認識するかを（ユーザーがダイヤルすると）問い合わせることができます。番号が有効であることを示すDPREPが受信されると、DIALが送信される場合があります。
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 | |
+-------------+----------------+----------+----------+
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の「着信番号」IEで要求されたダイヤルプランエントリのステータスを含むDPREQへの応答です。 「着信番号」、「dpstatus」、および「更新」IEを含める必要があります。着信番号は、DPREQの「着信番号」IEで受信したものと同じです。 「dpstatus」IEには、受信した着信番号によって参照されるダイヤルプランエントリのステータスが含まれています。ステータスは、着信番号が存在するか、存在できるか、さらに数字が必要か、または無効かを示します。詳細については、DPSTATUS情報要素の下のセクション8.6を参照してください。 「更新」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. |
+----------+----------------+----------+----------------------------+
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).
DIALメッセージは、独自のダイヤルプラン/内線ルーティングを維持しないIAXピアで使用されます。内線番号が1つ以上のDPREQ / DPREP交換によって検証されると、「着信番号」IEを使用して番号がDIALメッセージでダイヤルされ、到達しようとしている内線番号が指定される場合があります。次に、リモートピアは、内線を呼び出し、ローカルコマンドがNEWコマンドと同じ要件に従って応答されたときにローカルピアに通知する（セクション6.2.2）など、コールセットアップの残りの側面を処理します。
The following table specifies the IEs used by this message:
次の表は、このメッセージで使用されるIEを示しています。
+-----------+---------------+----------+----------------------------+
| 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 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は、IAXメッセージの受信を確認します。 ACKは、他のプロトコル定義の応答がないフルフレームを受信すると送信されます。 ACKには、送信元呼び出し番号と宛先呼び出し番号の両方が必要です。また、シーケンス番号カウンターを変更してはならず（MUST）、受け取ったのと同じタイムスタンプを返す必要があります。このタイムスタンプにより、発信ピアはACKが応答しているメッセージを判別できます。 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メッセージの送信を遅らせることができ、認証交換中のブルートフォースパスワード攻撃に対するセキュリティを強化できます。
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が代わりに送信される必要があります：NEW、HANGUP、REJECT、ACCEPT、PONG、AUTHREP、REGREL、REGACK、REGREJ、TXREL。 ACKはどのピアからも期待されるべきではなく（SHOULD）、それらの目的は純粋にトランスポート層を強制的に最新にすることです。
The ACK message does not requires any IEs.
ACKメッセージはIEを必要としません。
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ピアが通話でメッセージを送信したときに発生します。 INVALを受信すると、ピアは呼び出し側を破棄する必要があります。
The INVAL message does not requires any IEs.
INVALメッセージはIEを必要としません。
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メッセージにはIEは必要ありません。
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メッセージは、1つ以上のメッセージが待機していることをリモートピアに示すために使用されます。待機しているメッセージの数を指定するために、「msgcount」IEを含めることができます。
The following table specifies IEs used by this message:
次の表は、このメッセージで使用されるIEを示しています。
+----------+----------------+----------+-----------+
| 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.
UNSUPPORTメッセージは、IAXピアでサポートされていないメッセージへの応答として送信されます。これは、認識されない、またはサポートされていないサブクラスを持つIAXコマンドを受け取ったときに発生します。このメッセージの受信時にアクションは必要ありませんが、ピアは、オプションで含まれている「IAX不明」IEで参照されているメッセージがリモートピアでサポートされていないことに注意してください。
The following table specifies IEs used by this message:
次の表は、このメッセージで使用されるIEを示しています。
+---------+----------------+----------+-----------+
| 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ポートを介して転送されます。音声とビデオは、それぞれがサポート手順が異なる2つの異なるエンコーディングを使用するという点で独特です。省略された「ミニフレーム」は通常、オーディオとビデオに使用されます。ただし、タイムスタンプが32,768（16進数の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（Dual Tone Multi-Frequency）の1桁を運びます。 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.
このメッセージには単一の画像が含まれます。このバージョンのプロトコルでは、画像は1つのメッセージに収まる必要があります。
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 NOT SUPPORTEDを示すHTMLメッセージで応答する必要があります。
When a device that supports HTML completes loading the page, it SHOULD send a LOAD COMPLETE message
HTMLをサポートするデバイスがページの読み込みを完了すると、LOAD COMPLETEメッセージを送信する必要があります（SHOULD）
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.
トランスポートに関しては、信頼性のある「フルフレーム」と未確認の「ミニ」または「メタ」フレームの2つのメッセージ形式があります。特定の音声およびビデオメッセージを除くすべてのメッセージは信頼できます。信頼性のあるメッセージは、コールに関与する両方のピアのメッセージ数とタイムスタンプを維持するスキームによって転送されます。カウントはコールごとです。各ピアは、すべての信頼できるメッセージのタイマーを維持し、確認するか再試行制限を超えるまで、それらのメッセージを定期的に再送信する必要があります。
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）の後で確認応答が受信されない場合、コールレッグは使用不可と見なされるべきであり（SHOULD）、このコールレッグでのさらなる相互作用なしにコールを切断する必要があります。
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を使用すると、同じ2つのピア間の複数のメディア交換を、メディアペイロードを結合して単一のトランクコールに結合し、結合されたパケットにすることができます。これにより、送信されるパケットの総数が少なくなるため、帯域幅の使用量が減少します。トランキングは、IAX交換の一方または両方の方向で発生する場合があります。トランクは、トランクヘッダーと1つ以上のトランクIAX呼び出しで構成されます。トランクメッセージには、トランクフレームの送信時刻を指定するタイムスタンプが含まれています。トランクコールからのオーディオデータは、ヘッダーに続くトランクフレームにカプセル化されます。各トランクコールは、コールのソース番号を指定する2つのオクテット、メディアデータの長さをオクテットで指定する2つのオクテット、およびメディアデータ自体で構成されます。 IAXでは、カプセル化された各ミニフレームのタイムスタンプも送信できるため、ジッタバッファなどに正確なタイミング情報を使用できます。メタコマンドヘッダーのフラグは、カプセル化されたミニフレームが元のタイムスタンプを保持するかどうかを指定します。それらがそれらを保持しない場合、それらはトランクピアによって受信されたときにトランクヘッダーのタイムスタンプを想定しなければなりません。
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で説明します。呼び出しごとに、メッセージの確認応答を待機する時間のタイマーがあります。このタイマーは、最後のPING / PONGコマンドから測定されたラウンドトリップ時間の2倍で開始します。再送信が必要な場合は、境界値に達するまで指数関数的に増加します。最大再試行期間の境界は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.
登録は指定された期間有効です。期間が終了する前にこの登録を更新するのはクライアントの責任です。登録は、ネットワークの輻輳を防ぐためにランダムな間隔で更新する必要があります（SHOULD）。タイマーが経過する前にクライアント/登録者が登録を更新していない場合、レジストラはこの期間を監視し、登録を無効にする必要があります。
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ポートをサーバーに転送する必要があります。サーバーが登録者として機能する場合、NATゲートウェイでポートの関連付けを維持するには、デフォルトの60秒のREGREQリフレッシュタイマーで十分です。ただし、静的ポートマッピングが推奨されます。
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-Advanced Encryption Standardとも呼ばれます）を使用した通話の暗号化をサポートしています。 Rijndaelは、共有秘密を利用する128ビットのブロック暗号です。 IAXは、他のメッセージパラメータに加えて、コールを暗号化する必要があることを示すプレーンテキストのNEWメッセージで始まるコールごとに暗号化します。この指示は、暗号化IE（セクション8.6.34）をNEW要求メッセージで送信することによって提供されます。呼び出されたホストが暗号化をサポートしている場合、暗号化IEを含むプレーンテキストのAUTHREQメッセージで応答します。呼び出しの後続のメッセージはすべて暗号化する必要があります。呼び出されたホストが暗号化をサポートしていない場合、NEWへの応答として送信されるAUTHREQにENCRYPTION 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からCHALLENGE IE Section 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.
フルフレームは確実に送信されるため、すべてのフルフレームは受信時に即時の確認応答を必要とします。この確認応答は、「ACK」メッセージ（セクション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.
このビットは、フレームが再送信されているかどうかを指定します。 「R」ビットが0に設定されている場合、フレームは初めて送信されています。 1に設定されている場合、フレームは再送信されています。 IAXは再送信タイムアウトを指定しません。これは実装者に任されています。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
ミニフレームは、ヘッダーが最小4オクテットであるため、そのように呼ばれています。ミニフレームは、制御データやシグナリングデータを伝送しません。その唯一の目的は、すでに確立されているIAX呼び出しでメディアストリームを伝送することです。それらは信頼できない方法で送信されます。この決定は、信頼性を確保するために発生するオーバーヘッドによって帯域幅要件が増加し、スループットが低下する一方で、VoIPコールは通常、コール品質を大幅に低下させることなくいくつかのフレームを失う可能性があるために行われました。さらに、音声通話は通常リアルタイムで送信されるため、失われたフレームは古すぎて、再送信できるまでにオーディオストリームに再統合できません。
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秒後に折り返します。この時点で、タイムスタンプがリセットされたことをリモートピアに通知するためにフルフレームを送信する必要があります（SHOULD）。コールは、再同期の確認が受信されない場合でも、タイムスタンプ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オクテットヘッダー全体を構成します。このヘッダーに続くのは、ネットワークでサポートされている最大長までの任意の長さの実際のストリームデータです。
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を参照）として定義されています。サブクラスは、コールの最新の完全な音声フレームによって暗黙的に定義されます（つまり、音声フレームのサブクラスは、ストリームで使用されるコーデックを指定します）。コールの最初の音声フレームは、最初のコーデックネゴシエーションで合意されたコーデックを使用して送信する必要があります。オンザフライCODECネゴシエーションは、サブクラスフィールドで使用する新しいコーデックを指定する完全な音声フレームを送信することで許可されます。
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.
メタフレームは、2つの目的のいずれかを果たします。メタビデオフレームにより、最適化されたヘッダーを持つビデオストリームの送信が可能になります。それらはミニ音声フレームと目的が似ています。メタトランクフレームは、2つのピア間の複数のIAXメディアストリームを1つのヘッダーにトランキングして、帯域幅の消費をさらに最小限に抑えるために使用されます。
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にリセットされたことをリモートピアに通知する必要があります（SHOULD）。
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を参照）として定義されます。使用されるビデオCODECは、コールの最新の完全なビデオフレームのサブクラスによって暗黙的に定義されます。
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は、2つのピア間の複数のメディアストリームを単一の関連付けにトランキングする2つの方法をネイティブでサポートしています。最初の方法は、標準のメタヘッダーと、トランクフレームの送信時間を表す単一の32ビットタイムスタンプを送信します。タイムスタンプの後には、フレームに含まれるストリームデータの呼び出し番号とオクテット単位の長さで構成される1つ以上のメディアフレームがあります。
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.
トランキングの2番目の方法は、1番目の方法と非常に似ています。トランクフレームの送信時刻を表す32ビットのタイムスタンプを含む標準のメタヘッダーを送信します。ただし、トランクに含まれるメディアフレームは、実際には各コールの16ビットタイムスタンプを含む完全なミニフレームです。最初の方法はわずかに少ない帯域幅を使用します（トランクのコールあたり2オクテットが少ない）、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メタコマンド割り当てについては、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 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.
32ビットのタイムスタンプの後には、1つ以上のトランクコールが続きます。 「トランクタイムスタンプ」フラグが0に設定されている場合、各エントリは、コールのソースコール番号を指定する2オクテット、メディアデータの長さをオクテット単位で指定する2オクテット、そしてメディアデータで構成されます。 「トランクタイムスタンプ」フラグが1に設定されている場合、各エントリは、メディアデータの長さをオクテット単位で指定する2オクテットと、次にミニフレーム（2オクテットでソースコール番号を指定、2オクテットで16ビットの時間を指定）で構成されます。 -スタンプ、およびメディアデータ）。次の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|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 |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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で暗号化され、各ブロックは前のブロックとXORされます。データの前にパディングが追加されます。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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（Dual Tone Multi-Frequency）の1桁を伝送します。 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.
Null値を持つフレームは送信してはならない（MUST NOT）。
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.
サブクラスは、IAXイベントを説明するセクション8.4の値です。
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 | |
+------+-------------+--------------------------+-------------------+
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 |
+-------------+---------------+-------------------------------------+
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 |
| | | |
| 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 |
+--------+----------------------------+
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メッセージは、ユーザー固有または呼び出し固有のデータを指定する情報要素を運ぶ場合があります。情報要素は、データフィールドのフレームヘッダーに追加されます。ゼロ、1つ、または複数の情報要素を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.
情報要素の2番目のオクテットは「データ長」フィールドです。情報要素のデータフィールドの長さをオクテット単位で指定します。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| 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.
CALLED NUMBER情報要素の目的は、呼び出される番号または内線番号を示すことです。 UTF-8でエンコードされたデータを伝送します。 CALLED NUMBER情報要素は、宛先がE.164番号（[E164]）、国番号、さらには数字に限定されないため、数値データではなくUTF-8エンコーディングを使用する必要があります。番号または内線番号に数字以外の文字を含めることができます。 CALLED NUMBER IEには、SIP URI、[RFC3261]、またはその他の形式のURIが含まれる場合があります。 CALLED NUMBERを提供する機能はサーバーに依存します。
The CALLED NUMBER information element is generally sent with IAX NEW, DPREQ, DPREP, DIAL, and TRANSFER messages.
CALLED NUMBER情報要素は通常、IAX NEW、DPREQ、DPREP、DIAL、およびTRANSFERメッセージとともに送信されます。
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.
CALLING NUMBER情報要素の目的は、リモートピアへの呼び出し元エンティティの番号または内線を示すことです。 UTF-8でエンコードされたデータを伝送します。
The CALLING NUMBER information element is usually sent with IAX NEW messages.
CALLING NUMBER情報要素は通常、IAX NEWメッセージで送信されます。
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.
CALLING ANI情報要素の目的は、請求のための発番号ANI（自動番号識別）を示すことです。 UTF-8でエンコードされたデータを伝送します。
The CALLING ANI information element MAY be sent with an IAX NEW message, but it is not required.
CALLING ANI情報要素は、IAX NEWメッセージで送信できますが、必須ではありません。
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.
CALLING NAME情報要素の目的は、送信ピアの呼び出し名を示すことです。 UTF-8でエンコードされたデータを伝送します。
The CALLING NAME information element is usually sent with IAX NEW messages.
CALLING NAME情報要素は通常、IAX NEWメッセージで送信されます。
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.
CALLED CONTEXT情報要素の目的は、CALLED NUMBERが解釈されるリモートピアのダイヤルプランのコンテキスト（またはパーティション）を示すことです。 UTF-8でエンコードされたデータを伝送します。
The CALLED CONTEXT information element MAY be sent with IAX NEW or TRANSFER messages, though it is not required.
CALLED CONTEXT情報要素は、必須ではありませんが、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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージ交換に参加しているユーザーのIDを指定することです。 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.
USERNAME情報要素は、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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
CAPABILITY情報要素の目的は、IAXピアのメディアコーデック機能を示すことです。そのデータは、セクション8.7に従って4オクテットのビットマスクで表されます。複数のコーデックは、それらをCAPABILITY情報要素に論理ORすることによって指定できます。
The CAPABILITY information element is sent with IAX NEW messages if appropriate for the CODEC negotiation method the peer is using.
CAPABILITY情報要素は、ピアが使用しているコーデックネゴシエーション方式に適切な場合、IAX NEWメッセージとともに送信されます。
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.
FORMAT情報要素の目的は、単一の優先メディアコーデックを示すことです。 NEWメッセージで送信される場合、示されたコーデックは、IAXピアがコールに使用したいコーデックです。 ACCEPTメッセージとともに送信された場合、コールに選択された実際のコーデックを示します。そのデータは、セクション8.7に従って4オクテットのビットマスクで表されます。 FORMAT情報要素で指定できるコーデックは1つだけです。
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].
LANGUAGE情報要素の目的は、送信ピアがリモートピアにシグナリング情報を送信してほしい言語を示すことです。 UTF-8でエンコードされたデータを伝送し、[RFC5646]および[RFC4647]に従ってタグを選択する必要があります。
The LANGUAGE information element MAY be sent with an IAX NEW message.
LANGUAGE情報要素は、IAX NEWメッセージで送信される場合があります。
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.
VERSION情報要素の目的は、ピアが使用しているプロトコルバージョンを示すことです。通話の両端のピアは、同じプロトコルバージョンを使用する必要があります。現在、サポートされているバージョンは2のみです。VERSION情報要素のデータフィールドの長さは2オクテットです。
The VERSION information element MUST be sent with an IAX NEW message.
VERSION情報要素は、IAX NEWメッセージで送信する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 NEWメッセージで送信される場合があります。
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 NEWメッセージで送信される場合があります。
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情報要素の目的は、ピアが受け入れる認証方法を示すことです。 2オクテット長のビットマスクとして送信されます。次の表に、有効な認証方法を示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following table lists valid values for authentication:
次の表に、認証に有効な値を示します。
+--------+--------------------------+
| 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.
CHALLENGE情報要素の目的は、認証に使用されるMD5またはRSAチャレンジを提供することです。実際のUTF-8でエンコードされたチャレンジデータを伝送します。
The CHALLENGE information element MUST be sent with IAX AUTHREQ and REGAUTH messages.
CHALLENGE情報要素は、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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 RESULT情報要素の目的は、認証チャレンジに対するMD5応答を提供することです。 UTF-8でエンコードされたチャレンジ結果を伝送します。 MD5 Result値は、チャレンジ文字列とパスワード文字列のMD5 [RFC1321]ダイジェストを使用して計算されます。
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.
MD5 RESULT情報要素は、AUTHREQまたはREGAUTHおよび適切なCHALLENGEが受信された場合、IAX AUTHREPおよびREGREQメッセージとともに送信される場合があります。この情報要素は、チャレンジへの応答以外では送信してはならない（MUST NOT）。
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 RESULT情報要素の目的は、認証チャレンジに対する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 RESULT情報要素を受信したら、その値を送信者の公開鍵で検証して、チャレンジ文字列の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.
RSA RESULT情報要素は、AUTHREQまたはREGAUTHおよび適切なCHALLENGEが受信された場合、IAX AUTHREPおよびREGREQメッセージとともに送信される場合があります。この情報要素は、チャレンジへの応答以外では送信してはならない（MUST NOT）。
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.
APPARENT ADDR情報要素の目的は、ピアに到達するために使用される認識されたネットワーク接続情報を示すことです。これは、ピアがNATの背後にある場合、実際のアドレスとは異なる場合があります。 APPARENT ADDR IEは、この応答が生成されるIAXメッセージのUDPおよびIPヘッダーのソースアドレス値を使用して入力されます。 APPARENT ADDR情報要素のデータフィールドは、使用中のアドレスファミリのPOSIX sockaddr構造体と同じです（つまり、IPv4の場合はsockaddr_in、IPv6の場合はsockaddr_in6）。データ長は、表されるアドレスのタイプによって異なります。
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).
APPARENT ADDR情報要素は、IAX TXREQおよびREGACKメッセージと一緒に送信する必要があります。 TXREQメッセージで使用する場合、APPARENT ADDRは、ローカルピアが接続の終端を転送しようとしているピアのアドレスを指定する必要があります。 REGACKメッセージと共に使用する場合、APPARENT ADDRは、ピアに到達するために使用するアドレスを指定する必要があります（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.
APPARENT ADDR情報要素のデータフィールドは、Linuxのstruct sockaddr_inと同じです。アドレスファミリ用に2オクテット、ポート番号用に2オクテット、IPv4アドレス用に4オクテット、すべてのビットで構成される8オクテットのパディングしたがって、APPARENT ADDR情報要素の全長は18オクテットです。
The following diagram demonstrates the generic APPARENT ADDR format:
次の図は、一般的なAPPARENT 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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram demonstrates the APPARENT ADDR format for an IPv4 address:
以下の図は、IPv4アドレスのAPPARENT 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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram demonstrates the APPARENT ADDR format for an
IPv6 address:
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.
REFRESH情報要素の目的は、イベントが期限切れになるまでの秒数を示すことです。そのデータフィールドは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.
REFRESH情報要素は、IAX REGREQ、REGACK、およびDPREPメッセージで使用されます。 REGREQで送信される場合、登録を維持しているピアがタイムアウトをREFRESH秒に設定することが要求されます。 DPREPまたはREGACKで送信された場合、これは情報提供であり、ローカルピアがイベントを有効であると見なさなくなる場合にリモートピアに通知します。 DPREPで送信されたREFRESHは、受信したダイヤルプラン応答を保存する必要がある期間をピアに通知します。
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.
REFRESH情報要素がDPREPで受信されない場合、キャッシュデータの有効期限は10分と見なされます。 REFRESH情報要素がREGACKで受信されない場合、登録の有効期限は60秒後に発生すると見なされます。
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情報要素の目的は、リモートダイヤルプランのCALLED NUMBERのステータスを示すことです。そのデータフィールドは、以下の表のフラグを指定する2オクテットのビットマスクです。下位3ビットの1つだけを設定する必要があり、上位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メッセージとともに送信する必要があります。
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 |
+--------+------------------------------+
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情報要素の目的は、リモートピアが転送中のコールを識別するための宛先コール番号として使用する必要があるコール番号を示すことです。転送を管理するピアは、1つの転送エンドポイントの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
CAUSE情報要素の目的は、イベントが発生した理由を示すことです。イベントの原因の説明がUTF-8でエンコードされたデータとして含まれています。イベント自体の通知はメッセージレベルで処理されます。
The CAUSE information element SHOULD be sent with IAX HANGUP, REJECT, REGREJ, and TXREJ messages.
CAUSE情報要素は、IAX HANGUP、REJECT、REGREJ、およびTXREJメッセージとともに送信する必要があります（SHOULD）。
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情報要素の目的は、受信したIAXコマンドが不明または認識されなかったことを示すことです。 1オクテットのデータフィールドには、認識されなかった受信フレームのサブクラスが含まれています。
The IAX UNKNOWN information element MUST be sent with IAX UNSUPPORT messages.
IAX UNKNOWN情報要素は、IAX UNSUPPORTメッセージとともに送信する必要があります。
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に設定されている場合、少なくとも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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
AUTOANSWER情報要素の目的は、AUTOANSWER情報要素を含むNEWメッセージの受信時にコールに自動応答することを要求することです。これは要求であり、リモートピアによって許可される場合と許可されない場合があります。この情報要素の存在だけですべての必要な情報が示されるため、この情報要素のデータフィールドはありません。
The AUTOANSWER information element MAY be sent with IAX NEW messages.
AUTOANSWER情報要素は、IAX NEWメッセージとともに送信される場合があります。
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は保留音の一般的な要求として扱われる必要があります（SHOULD）。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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情報要素の目的は、転送イベントに参加している3つすべてのピアにわたる転送を識別することです。 4オクテットの長さの数値が含まれ、転送プロセスの期間中一意である必要があります。
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メッセージと共に送信して、適切なコールを識別する際に転送に関与するピアを支援する必要があります（SHOULD）。転送するピアがTRANSFERIDなしで転送に参加しているコールを明確に識別できる限り、これは必要ありません。
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（Redirected Dialed Number Identification Service）情報要素の目的は、参照するDNISを示すことです。 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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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情報要素のデータフィールドは4オクテット長であり、次のように時間を格納します。最下位5ビットは秒、次の最下位6ビットは分、次の最下位5ビットは時間、次の最下位5ビットは日、次の最下位4ビットは月、最上位7ビットは年です。年は2000年からオフセットされ、月は1から始まるインデックスです（つまり、1月== 1、2月== 2など）。ピア間の混乱を避けるために、クロックのタイムゾーンはUTCでなければなりません。
The DATETIME information element SHOULD be sent with IAX NEW and REGACK messages. However, it is strictly informational.
DATETIME情報要素は、IAX NEWおよびREGACKメッセージとともに送信する必要があります（SHOULD）。ただし、これは情報提供のみを目的としています。
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 NEWメッセージで送信する必要があります。
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 |
+------+--------------------------------------+
Refer to the IANA Registry for additional IAX Calling Presentation values.
追加のIAX Calling Presentation値については、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.
CALLINGTON情報要素の目的は、ITU-T勧告Q.931仕様に従って、発信者の番号の発信タイプを示すことです。データフィールドの長さは1オクテットで、次の表のデータが含まれています。
The CALLINGTON information element MUST be sent with IAX NEW messages.
CALLINGTON情報要素は、IAX NEWメッセージで送信する必要があります。
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 |
+-------+-------------------------+
Refer to the IANA Registry for any additional IAX Calling Type of Number values.
追加のIAX Calling Type of Number値については、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 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.
CALLINGTNS情報要素は、通話用に選択された発呼中継ネットワークを示します。値は、ITU-T勧告Q.931仕様に従って選択されます。データフィールドの長さは2オクテットです。最初のオクテットは、下の最初の表に従って最下位4ビットにネットワーク識別プランを格納し、下の2番目の表に従って次の3つの最下位ビットにネットワークのタイプを格納します。 2番目のオクテットは、実際のネットワークIDをUTF-8でエンコードされたデータに格納します。
The CALLINGTNS information element MUST be sent with IAX NEW messages.
CALLINGTNS情報要素は、IAX NEWメッセージで送信する必要があります。
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.
次の表は、「calling tns」IEのデータフィールドの有効な値を示しています。
Q.931 Network Identification Plan Values:
Q.931ネットワーク識別計画の値：
+------+----------------------------------+
| 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 Transit Network Identification IANA Registryを参照してください。
Q.931 Type of Network Values:
Q.931ネットワーク値のタイプ：
+------+--------------------------------------+
| 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.
その他の値については、ネットワークIANAレジストリのIAXタイプを参照してください。
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.
SAMPLINGRATE情報要素が指定されていない場合、デフォルトのサンプリングレートである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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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から派生しています。データフィールドの長さは1オクテットで、次の表のエントリが含まれています。
The CAUSECODE information element SHOULD be sent with IAX HANGUP, REJECT, REGREJ, and TXREJ messages.
CAUSECODE情報要素は、IAX HANGUP、REJECT、REGREJ、およびTXREJメッセージとともに送信する必要があります（SHOULD）。
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) |
| | |
| 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 |
+--------+----------------------------------------------------------+
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.
ENCRYPTION情報要素の目的は、IAXピアで受け入れられる暗号化方式を示すことです。データフィールドは2オクテットのビットマスクで、以下の表のどの暗号化方式を受け入れるかを指定します。
The ENCRYPTION information element MAY be sent with IAX NEW and AUTHREQ messages.
ENCRYPTION情報要素は、IAX NEWおよびAUTHREQメッセージとともに送信される場合があります。
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 |
+--------+-------------+
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 NEWメッセージとともに送信される場合があります。
If the CODEC PREFS information element is absent, CODEC negotiation takes place via the CAPABILITY and FORMAT information elements.
CODEC PREFS情報要素が存在しない場合、CODECネゴシエーションはCAPABILITYおよびFORMAT情報要素を介して行われます。
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.
[RFC3550]に従い、Receiver Report（RR）JITTER情報要素の目的は、コールで受信されたジッタを示すことです。データフィールドの長さは4オクテットで、現在測定されているジッターを伝送します。
The RR JITTER information element MAY be sent with IAX PONG messages.
RR JITTER情報要素は、IAX PONGメッセージとともに送信される場合があります。
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 LOSS情報要素の目的は、[RFC3550]ごとに、コールで失われたフレームの数を示すことです。データフィールドの長さは4オクテットで、最初のオクテットで失われたフレームの割合と、次の3オクテットで失われたフレームの数を示します。
The RR LOSS information element MAY be sent with IAX PONG messages.
RR LOSS情報要素は、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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 DELAY情報要素の目的は、[RFC3550]に従って、コールの最大プレイアウト遅延を示すことです。データフィールドの長さは2オクテットで、フレームが破棄される前にフレームが遅延するミリ秒数を指定します。
The RR DELAY information element MAY be sent with IAX PONG messages.
RR DELAY情報要素は、IAX PONGメッセージとともに送信される場合があります。
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 DROPPED情報要素の目的は、[RFC3550]ごとに、コールでドロップされたフレームの総数を示すことです。データフィールドは4オクテット長で、ドロップされたフレームの数を伝送します。
The RR DROPPED information element MAY be sent with IAX PONG messages.
RR DROPPED情報要素は、IAX PONGメッセージとともに送信される場合があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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情報要素の目的は、European Telecommunications Standards Institute（ETSI）技術仕様101 321 [OSP]（Open Settlement Protocolまたは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 NEWメッセージでのみ送信される場合があります。トークンがレシーバーでサポートされていない場合は、無視されます。
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 | |
| | | |
| 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 Media Format値については、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
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.
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.
Registration of an IAX Peer
IAXピアの登録
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=============================> |
| |
|________________________________________|
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
| |
|________________________________________|
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============================> |
| |
| |
| <-----------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------> |
| <--- . ---> |
| <--- . ---> |
| <--- . ---> |
| <-----------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プロトコルでは指定されていませんが、一部の実装では、アカウントごとの登録者の数を1つに制限しています。同じ資格情報を持つ後続の登録者は、以前のユーザーを上書きし、そのユーザー宛ての呼び出しを受信します。悪意のある発信者が認証できるようになると、サービスの盗難は簡単になります。さらに、誤った登録試行に対して個別の原因コードが返されるため、攻撃者は登録システム内に存在するユーザーと存在しないユーザーを区別できるため、ディレクトリ獲得攻撃の可能性があります。
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に対する脅威です。この形式の攻撃では、メッセージの挿入、削除、および変更が可能になるため、通話をリダイレクトしたり、通話の全体または一部に対して音声またはビデオを片方向または双方向に置き換えることができます。暗号化が使用されている場合、通話はエンドツーエンドで保護されます。注：暗号化された呼び出しの最初のNEWメッセージは暗号化されておらず、変更される可能性があります。ただし、同じアドレス情報を含む後続のメッセージは暗号化された形式で再配信されるため、これはサービス拒否（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.
DoS攻撃は、IAXで少なくとも2つの形式をとることができます。 1つは、偽のリクエストでピアをオーバーロードすることです。注意深く実装された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.
既存のコールに対するDoSの別の形式は、既存のコールに対する設計された攻撃です。メディアを注入し、順序の乱れたパケットを挿入して過剰な処理を引き起こし、ハングアップや転送などのコマンドを送信します。メッセージのシーケンス番号をプロトコル交換と同期させる必要があるため、これらの攻撃では、成功するためにバイナリチャネルを注意深く監視する必要があります。
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 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.
最近、DoS攻撃を受けたときのサーバーの堅牢性に関していくつかの問題が発生しています。認証されていない要求をサポートするIAXサーバーは、SYN攻撃に相当するものを受信できます。これらの攻撃の影響を緩和するために、認証されていない呼び出しの数とユーザーごとの呼び出しの数を制限するさまざまな制御を実装に追加できます。コールを別のより保護されたポートに転送したり、過度の障害が検出されたときに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、Advanced Encryption Standardの発表」、2001年11月。
[E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[E164] ITU-T、「The International Public Telecommunication Number Plan」、Recommendation 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] European Telecommunications Standards Institute、「Telecommunications and Internet Protocol Harmonization Over Networks（TIPHON）Release 4; Open Settlement Protocol（OSP）for Inter-Domain料金、承認、使用法の交換」、2003年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年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、「The ESP Triple DES Transform」、RFC 1851、1995年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：Session Initiation Protocol」 、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、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 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、「Preparation of Internationalized Strings（ "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：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Datagram Transport Layer Security」、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、「Matching of Language Tags」、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。、「Tags for Identificationing Languages」、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 Specification」、World Wide Web Consortium Recommendation 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 Laboratories、「PKCS＃1 v2.0：RSA Cryptography Standard」、1998年10月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 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、「Media Gateway Control Protocol（MGCP）Version 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.、and T. Taylor、 "Gateway Control Protocol Version 1"、RFC 3525、June 2003。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P。およびM. Mealling、「E.164からUniform Resource Identifiers（URI）Dynamic Delegation Discovery System（DDDS）Application（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 4301、2005年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：Session Description Protocol」、RFC 4566、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 4733、2006年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、「Definition of Events for Modem、Fax、and Text Telephony Signals」、RFC 4734、2006年12月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]テイラーT。、「RFC 3525の歴史的分類への再分類」、RFC 5125、2008年2月。
[RFC5457] Guy, E., "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", RFC 5457, February 2010.
[RFC5457]ガイ、E。、「IAXに関するIANAの考慮事項：Inter-Asterisk eXchangeバージョン2」、RFC 5457、2010年2月。
[wikipedia] Wikipedia, "Inter-Asterisk eXchange", <http://en.wikipedia.org/wiki/IAX>.
[wikipedia] Wikipedia、「Inter-Asterisk eXchange」、<http://en.wikipedia.org/wiki/IAX>。
Authors' Addresses
著者のアドレス
Mark A. Spencer Digium, Inc. 445 Jan Davis Drive NW Huntsville, AL 35806 US
Mark A. Spencer Digium、Inc. 445 Jan Davis Drive NW Huntsville、AL 35806 US
Phone: +1 256 428 6000
EMail: markster@digium.com
URI: http://www.digium.com/
Brian Capouch Saint Joseph's College PO Box 909 Rensselaer, IN 47978 US
ブライアンキャポーチセントジョセフカレッジ私書箱909レンセラー、IN 47978 US
Phone: +1 219 866 6114
EMail: brianc@saintjoe.edu
Ed Guy (editor) Truphone 12 Williams Rd Chatham, NJ 07928 US
Ed Guy（編集者）Truphone 12 Williams Rd Chatham、NJ 07928 US
Phone: +1 973 437 4519
EMail: edguy@emcsw.com
URI: http://www.truphone.com/
Frank Miller Cornfed Systems, LLC 3476 Dayton Street Denver, CO 80238 US
Frank Miller Cornfed Systems、LLC 3476 Dayton Street Denver、CO 80238 US
Phone: +1 410 404-8790
EMail: mail@frankwmiller.net
URI: http://www.sipuseragent.net
Kenneth C. Shumard 3818 N Lakegrove Way Boise, ID 83713 US
ケネスC.シュマード3818 N Lakegrove Way Boise、ID 83713 US
Phone: +1 208 724 7801
EMail: kshumard@gmail.com