idnits 2.17.1 draft-guy-iax-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.2b on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4502. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 573 has weird spacing: '... snd ack ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2008) is 5680 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 M. Spencer 3 Internet-Draft Digium, Inc. 4 Intended status: Informational B. Capouch 5 Expires: April 9, 2009 Saint Joseph's College 6 E. Guy, Ed. 7 TruPhone 8 F. Miller 9 Cornfed Systems, Inc. 10 K. Shumard 11 October 6, 2008 13 IAX: Inter-Asterisk eXchange Version 2 14 draft-guy-iax-05 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 This document may not be modified, and derivative works of it may not 23 be created. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 9, 2009. 43 Abstract 45 This document describes IAX, the Inter-Asterisk eXchange protocol, an 46 application-layer control and media protocol for creating, modifying, 47 and terminating multimedia sessions over Internet Protocol (IP) 48 networks. IAX was developed by the open source community for the 49 Asterisk PBX and is targeted primarily at Voice over Internet 50 Protocol (VoIP) call control, but it can be used with streaming video 51 or any other type of multimedia. 53 IAX is an "all in one" protocol for handling multimedia in IP 54 networks. It combines both control and media services in the same 55 protocol. In addition, IAX uses a single UDP data stream on a static 56 port greatly simplifying Network Address Translation (NAT) gateway 57 traversal, eliminating the need for other protocols to work around 58 NAT, and simplifying network and firewall management. IAX employs a 59 compact encoding which decreases bandwidth usage and is well suited 60 for Internet telephony service. In addition, its open nature permits 61 new payload types additions needed to support additional services. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.1. Basic Properties . . . . . . . . . . . . . . . . . . . . 5 67 1.2. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. IAX Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Overview of IAX Protocol . . . . . . . . . . . . . . . . . . 8 70 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 10 71 5. IAX Uniform Resource Identifiers . . . . . . . . . . . . . . 11 72 5.1. IAX URI Scheme Registration . . . . . . . . . . . . . . . 11 73 5.2. URI Comparison . . . . . . . . . . . . . . . . . . . . . 13 74 6. Peer Behavior and Related Messages . . . . . . . . . . . . . 15 75 6.1. Registration (OPTIONAL) . . . . . . . . . . . . . . . . . 15 76 6.2. Call Leg Management . . . . . . . . . . . . . . . . . . . 22 77 6.3. Call Control . . . . . . . . . . . . . . . . . . . . . . 28 78 6.4. Mid-Call Link Operations . . . . . . . . . . . . . . . . 30 79 6.5. Call Path Optimization . . . . . . . . . . . . . . . . . 32 80 6.6. Call Tear Down . . . . . . . . . . . . . . . . . . . . . 37 81 6.7. Network Monitoring . . . . . . . . . . . . . . . . . . . 37 82 6.8. Digit Dialing . . . . . . . . . . . . . . . . . . . . . . 38 83 6.9. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 40 84 6.10. Media Messages . . . . . . . . . . . . . . . . . . . . . 42 85 7. Message Transport . . . . . . . . . . . . . . . . . . . . . . 44 86 7.1. Trunking . . . . . . . . . . . . . . . . . . . . . . . . 44 87 7.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 45 88 7.3. NAT Considerations . . . . . . . . . . . . . . . . . . . 45 89 7.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 46 90 8. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 47 91 8.1. Frame Structure . . . . . . . . . . . . . . . . . . . . . 47 92 8.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 57 93 8.3. Control Frames Subclasses . . . . . . . . . . . . . . . . 60 94 8.4. IAX Frames . . . . . . . . . . . . . . . . . . . . . . . 61 95 8.5. HTML Command Subclasses . . . . . . . . . . . . . . . . . 63 96 8.6. Information Elements . . . . . . . . . . . . . . . . . . 63 97 8.7. Media Formats . . . . . . . . . . . . . . . . . . . . . . 92 98 9. Example Message Flows . . . . . . . . . . . . . . . . . . . . 95 99 9.1. Ping/Pong . . . . . . . . . . . . . . . . . . . . . . . . 95 100 9.2. Lagrq/Lagrp . . . . . . . . . . . . . . . . . . . . . . . 95 101 9.3. Registration . . . . . . . . . . . . . . . . . . . . . . 96 102 9.4. Registration Release . . . . . . . . . . . . . . . . . . 96 103 9.5. Call Path Optimization . . . . . . . . . . . . . . . . . 97 104 9.6. IAX Media Call . . . . . . . . . . . . . . . . . . . . . 97 105 9.7. IAX Media Call via an IAX Device . . . . . . . . . . . . 99 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 101 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 108 12. Implementation Notes . . . . . . . . . . . . . . . . . . . . 104 109 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 111 14.1. Normative References . . . . . . . . . . . . . . . . . . 106 112 14.2. Informative References . . . . . . . . . . . . . . . . . 107 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 114 Intellectual Property and Copyright Statements . . . . . . . . . 111 116 1. Introduction 118 Numerous protocols have been specified by the Internet community to 119 support control or signaling of multimedia sessions, for instance, 120 SIP [RFC3261], MGCP [RFC3435], and MEGACO/H.248 [RFC3525]. In 121 general, these protocols are designed to offer full support for many 122 types of media transmission. This flexible approach adds some 123 overhead to the protocol headers, but allows for the protocol use 124 well beyond the current application. Typically, these protocols 125 reference, but do not specify, the media transmission protocol used 126 to carry the actual stream. SIP commonly uses Session Description 127 Protocol (SDP) [RFC4566] to specify Real-Time Transport Protocol 128 (RTP) [RFC3550] streams. This method allows for great flexibility, 129 but again leads to more overhead. Furthermore, multimedia solutions 130 which use different, perhaps dynamic, network addresses for signaling 131 and media transmission frequently suffer from Network Address 132 Translation (NAT) traversal and security challenges. 134 IAX is the Inter-Asterisk eXchange protocol which facilitates VoIP 135 connections between servers, and between servers and clients that 136 also use the IAX protocol. IAX was created through an open source 137 methodology rather than through a traditional standards based 138 methodology. It is an open protocol originally used by Asterisk, a 139 dual licensed open source and commercial PBX server from Digium. 140 Independent IAX implementations may be open, proprietary, or licensed 141 in anyway the author seems fit without royalty to the protocol 142 creators. 144 1.1. Basic Properties 146 IAX is a robust and full featured, yet, simple protocol. It is 147 general enough that it can handle most common types of media streams. 148 However, the protocol is highly optimized for VoIP calls where low 149 overhead and low bandwidth consumption are priorities. This 150 pragmatic aspect makes IAX more efficient for VoIP than protocols 151 which consider possibilities far beyond current needs and specify 152 many more details than are strictly necessary to describe or 153 transport a point-to-point call. Furthermore, because IAX is 154 designed to be lightweight and VoIP-friendly, it consumes less 155 bandwidth than more general approaches. IAX is a binary protocol, 156 designed to reduce overhead, especially in regards to voice streams. 157 Bandwidth efficiency, in some places, is sacrificed in exchange for 158 bandwidth efficiency for individual voice calls. For example, when 159 transmitting a voice stream compressed to 8kbs with a 20ms 160 packetization, each data packet consists of 20 bytes. IAX adds 20% 161 overhead, 4 bytes, on the majority of voice packets while RTP adds 162 60% overhead with 12 additional bytes per voice packet. 164 In addition to efficiency, IAX's single static UDP port approach 165 makes IAX traffic easy for network managers to shape, prioritize, and 166 pass through firewalls. IAX's basic structure is that it multiplexes 167 signaling and multiple media streams over a single UDP stream between 168 two computers. IAX also uses the same UDP port for both its 169 signaling and media messages, and because all communications 170 regarding a call are done over a the same point-to-point path, NAT 171 traversal is much simpler for IAX than for other commonly deployed 172 protocols. 174 1.2. Drawbacks 176 While IAX is very effective, addressing many of today's 177 communications needs, it does have a few limitations. For instance, 178 IAX uses a point-to-point codec negotiation mechanism that limits 179 extensibility because every IAX node in a call path must support 180 every used codec to some degree. In addition, the codec definition 181 is controlled by an internally defined 32-bit mask, so the codecs 182 must be defined in the protocol, and the maximum number of 183 simultaneous codecs is, therefore, limited. 185 One of IAX's design strengths also presents a potential problem. The 186 use of a single, well-known, port makes the protocol an easier target 187 for denial of service attacks. Real time systems like VoIP are 188 particularly sensitive to these attacks. 190 The protocol is typically deployed with all signaling and media going 191 to a centralized server. While this combined path approach provides 192 a great deal of control, it limits the overall system scalability. 193 IAX now provides the ability to split the media from the signaling 194 stream which overcomes this limitation of earlier IAX versions. 196 Most IAX drawbacks are due to implementation issues rather than 197 protocol issues. Threading presents a series of problems. Many 198 implementations have a limited number of threads available to process 199 IAX traffic and can become overwhelmed by high use or denial of 200 service attacks. Newer implementations have additional controls to 201 minimize the impact of these challenges. 203 2. IAX Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 Additionally, this document uses the following terminology: 211 Peer: A host or device that implements the IAX protocol. 213 Call: A call is a relationship between two or more parties (i.e., 214 resources such as devices, user agents, or programs) that exists 215 for some time for the purpose of exchanging real-time media. In 216 the context of this document, a call is an end to end relationship 217 where at least the one leg of call path is implemented using the 218 IAX protocol. 220 Calling Party: A device or program that initiates a call. 222 Called Party: A device or program to which a call is directed. 224 Context: A context is a named partition of a Dialplan. 226 Dialplan: A Dialplan is a set of rules for associating provided 227 names and numbers with a particular called party. 229 Frame: The atomic communication unit between two IAX peers. All IAX 230 messages are carried within frames. 232 Information Element (IE): A discrete data unit appended to an IAX 233 frame which specifies user or call-specific data. 235 Registrant: A registrant is a peer that makes REGISTER requests in 236 order to advertise the address of a resource, i.e., a device or 237 program to which a call may be directed. 239 Registrar: A registrar is a peer that processes REGISTER requests 240 and places the information it receives in those requests into the 241 location service. [RFC3261]. 243 3. Overview of IAX Protocol 245 IAX is a peer-to-peer, VoIP-oriented, protocol. IAX includes both 246 control and media functions. It can register locations, create, 247 modify, terminate multimedia sessions, and carry the actual media 248 streams specified by the sessions it manages. The protocol is 249 designed and optimized for describing and transporting multimedia 250 calls using Internet Protocol. This document describes version 2 of 251 IAX; Version 1, although somewhat similar in design, utilized a 252 different port and was not widely deployed. 254 The basic design approach for IAX multiplexes signaling and multiple 255 media streams over a single UDP association between two hosts. This 256 is accomplished by using the same "well-known" UDP port, 4569, for 257 all types of IAX traffic. IAX's unified signaling and media paths 258 achieve NAT transparency, which is an advantage of IAX over 259 alternative media transport protocols such as SIP [RFC3261]. 261 IAX is coded as a binary protocol. One major benefit of using a 262 binary protocol is bandwidth efficiency because the quality of voice 263 calls is frequently related to the amount of bandwidth consumed. 264 This is one way the protocol is specifically optimized to make 265 efficient use of bandwidth for individual voice calls. The bandwidth 266 efficiency for other stream types is sacrificed for the sake of 267 individual voice calls. Other benefits of a binary protocol are 268 robustness against buffer overrun attacks, and compact implementation 269 capability, which reduces interoperability issues related to parsing. 271 The atomic communication unit in IAX is the "Frame". There are 272 multiple classes of Frames, each of which is described below. In 273 general, "Full Frames" carry signaling/control data, while "Mini 274 Frames" carry media stream data. Full Frames enclose optional 275 'Information Elements' (IEs). IEs describe various types of user- or 276 call-specific data. "Meta Frames" are used for call trunking or 277 video stream transmission. 279 An IAX-based call may consist of many call legs, or segments. Each 280 call leg may be implemented using different protocols, e.g., SIP to 281 IAX to ISDN (Integrated Services Digital Network). IAX is 282 responsible for setting up one or more legs of a complete call path, 283 not necessarily the end-to-end call. 285 IAX is an optimized peer-to-peer protocol. If two adjacent call legs 286 utilize the IAX protocol and if the intermediate peer determines that 287 it does not need to remain in the call path, it can supervise a 288 calling path change such that it removes itself from the path. This 289 supervision is complete, a call path is not changed until all peers 290 in the optimized call path confirm they can properly communicate. 292 IAX supports security features by allowing multiple methods of user 293 authentication and authorization, as well as during peer 294 registration. IAX also specifies a generic framework for native 295 encryption. 297 4. Naming Conventions 299 Call Identifier: A call leg is marked with two unique integers, one 300 assigned by each peer involved in creating the call leg. 302 Number: The Calling and Called Numbers are a set of digits and 303 letters identifying a call originator and the desired terminating 304 resource. The term 'Number' is historic and has been expanded to 305 include letters. A peer is responsible for defining its own 306 dialplan. A peer MAY define its dialplan according to ITU-T 307 Recommendation E.164. [E164] However, this is not required. 309 Username: A username is a string used for identification purposes. 311 5. IAX Uniform Resource Identifiers 313 5.1. IAX URI Scheme Registration 315 This section registers IAX according to the guidelines in [RFC4395]. 317 URI scheme name: 319 iax. 321 Status: 323 Permanent. 325 URI scheme syntax: 327 The "iax:" scheme follows the guidelines in [RFC3986]. 329 The general form is as follows: 331 iax:[username@]host[:port][/number[?context]] 333 where these tokens have the following meanings: 335 iax: The literal 'iax:'. 337 username: A string used for identification purposes. 339 host: The domain of the resource. The host part contains 340 either a fully-qualified domain name or numeric IPv4 or IPv6 341 address. An IPv6 address must be enclosed within brackets 342 (i.e., '[2001:db8::1]') as defined in [RFC3986]. Using the 343 fully-qualified domain name form is RECOMMENDED whenever 344 possible. 346 port: The numeric UDP port number. 348 number: The name or number identifying the resource on that 349 host. 351 context: The name of the host partition in which the service 352 is identified or processed. 354 Examples 355 iax:example.com/alice 356 iax:example.com:4569/alice 357 iax:example.com:4570/alice?friends 358 iax:192.0.2.4:4569/alice?friends 359 iax:[2001:db8::1]:4569/alice?friends 360 iax:example.com/12022561414 361 iax:johnQ@example.com/12022561414 363 ABNF Certain values are included by reference from [RFC3986]: 365 iax-uri = "iax:" [userinfo "@" ]host[":" port][ "/" number[ "?" 366 context]] 368 userinfo = 370 host = 372 port = 374 number = *(unreserved | sub-delims | pct-encoded ) 376 context = *(unreserved | sub-delims | pct-encoded ) 378 unreserved = 380 sub-delims = 382 pct-encoded = 384 URI Scheme Semantics: 386 An IAX URI identifies a communications resource capable of 387 communicating using the IAX Version 2 protocol defined in this 388 document. Within this document, we refer to IAX Version 2 389 protocol URI as IAX. An IAX URI contains enough information to 390 initiate an IAX-based call with that resource. 392 IAX URIs are associated with server resources to which calls may 393 be routed. For instance, an IAX URI may represent an appearance 394 on a phone, a voice-mail box on a messaging service, an 395 interactive program, a PSTN address or gateway, or any group of 396 the above. 398 The iax uri scheme translates into a location that may be used by 399 the iax protocol to establish a new call using the uri scheme 400 components described in the previous section. This new call 401 function is the only defined operation. 403 Encoding considerations: 405 IAX URI scheme encoding conforms to the encoding rules established 406 for URIs in [RFC3986]. 408 Applications/protocols that use this URI scheme name: 410 The scheme is used by ENUM Dynamic Delegation Discovery System 411 (DDDS) services to specify resources that support the IAX 412 protocol. The IAX protocol provides application-layer control and 413 media protocol for creating, modifying, and terminating multimedia 414 sessions over Internet Protocol (IP) networks. 416 Interoperability considerations: 418 None. 420 Security considerations: 422 The IAX URI Scheme does not introduce any new security concerns 423 except that it provides a uniform syntax for describing IAX 424 resources and that, when published, these addresses are subject to 425 various denial of service attacks. 427 Contact: 429 Ed Guy, edguy@emcsw.com, +1.973.437.4519. 431 Author/Change controller 433 Not Applicable. 435 References: 437 Spencer, M., Shumard, K., Capouch, B., and E. Guy, 'IAX: Inter- 438 Asterisk eXchange Version 2,' (This Document), March 2008. 440 5.2. URI Comparison 442 Some operations in this specification require determining whether two 443 IAX URIs are equivalent. IAX URIs are compared for equality 444 according to the following rules: 446 All components of the URI MUST be identical except: 448 The port, if omitted, is considered to be the same as the default, 449 4569. 451 All URI components, except the username field, are case 452 insensitive, and MUST be normalized to lower case as per Section 453 6.2.2.1 of [RFC3986] before comparison. 455 The URIs within each of the following sets are equivalent: 457 iax:atlanta.com/alice 458 iax:AtLaNtA.com/ALicE 459 iax:atlanta.com:4569/alice 461 iax:alice@atlanta.com/alice 462 iax:alice@AtLaNtA.com:4569/ALicE 464 The URIs within the following set are not equivalent: 466 iax:ALICE@atlanta.com/alice 467 iax:alice@atlanta.com/alice 469 NOTE: A host in domain form and in IP address form are NOT considered 470 identical even if the host name resolves to an address record that 471 matches the given IP address. 473 6. Peer Behavior and Related Messages 475 Messages are divided into two categories: reliable and non- 476 guaranteed. The reliable messages are referred to as "Full Frames." 477 In addition to a message type indicator and facilities to ensure 478 reliability, see Section 7, they include the full call identifier. 479 It consists of each of peer's identifiers for the call. Additional 480 attributes, "Information Elements" or "IEs", may be associated with 481 the Full Frame messages. 483 The non-guaranteed messages are referred to as "Mini-Frames" and 484 "Meta Frames" and these more compact messages only have the 485 originating peer's call identifier and MUST NOT have any "Information 486 Elements." 488 Peer behavior is presented in several partitions divided by the 489 following functional areas: 491 Registration (OPTIONAL) 493 Call Link Management 495 Call Path Optimization (OPTIONAL) 497 Mid-Call Behavior 499 Call Tear Down 501 Network Monitoring 503 Digit Dialing (OPTIONAL) 505 Miscellaneous 507 Media Messages 509 Each of these behavior topics and the messages involved are described 510 in the sections which follow. 512 6.1. Registration (OPTIONAL) 514 6.1.1. Overview 516 In order for one IAX peer to be reachable by another IAX peer, the 517 calling peer needs the network address of the receiving peer. This 518 address may be manually provisioned, determined through a shared 519 directory, e.g. an ENUM-like service, [RFC3761] or configured using 520 the IAX protocol. IAX provides a facility for one peer to register 521 its address and credentials with another so that callers can reach 522 the registrant. The IAX registration facility is optional. If 523 implemented, the IAX registration protocol MAY be done in parts, 524 e.g., an analog telephone adapter MAY only implement the registrant 525 portion of the protocol. 527 IAX allows user authentication via multiple methods. MD5 Message- 528 Digest authentication [RFC1321] uses a md5 sum arrangement, but still 529 requires that both ends have plaintext access to the secret. (See 530 section Section 8.6.15.) Rivest, Shamir and Adleman's (RSA) 531 algorithm [RFC3447] allows unidirectional secret knowledge through 532 public/private key pairs. IAX Private keys SHOULD always be Triple 533 Data Encryption Standard (3DES) encrypted [RFC1851]. (See section 534 Section 8.6.16.) 535 ________________ 536 | | 537 | Unregistered |<--------------------------\ 538 |________________| | 539 | | 540 /Init | | 541 ------------ | | 542 snd REGREQ | +--------+ | 543 | | | rec REGAUTH | 544 _______V____V___ | ----------- | 545 | | | snd REGREQ | 546 | Reg Sent +----+ | 547 |________________+----------+ | 548 | ^ | rec REGAUTH | 549 rec REGACK | | | /No Credentials| 550 ------------ | | REG timeout | -------------- | 551 snd ack | | ------- | snd ack | 552 | | REGREQ __V___ | 553 _______V____|___ | | | 554 | | | No | | 555 | Registered | | Auth | | 556 |________________| |______| | 557 | ^ | 558 | | rec REGAUTH | 559 | release | /No Credentials| 560 | ------- | -------------- | 561 +-------+ | snd REGREL | snd ack | 562 rec REGAUTH | | | | | 563 ----------- | _V_____V________ | | 564 snd REGREL | | |----------+ | 565 +-----+ Releasing |---------------------------+ 566 |________________| rec ACK 567 ------- 568 x 570 __________ 571 rec REGREJ | | 572 ---------- *->| Rejected | 573 snd ack |__________| 575 Figure 1: Registrant State Diagram 577 Registration, illustrated in Figure 1, is performed by a registrant 578 that sends a username and a registration 'refresh' period to the 579 registrar. This is accomplished with a REGREQ message. If 580 authentication is required, the registrar responds with the REGAUTH 581 message which indicates the types of authentication supported by the 582 registrar. In response, the registrant resends a REGREQ with one of 583 the supported authentications. If the registrant can not 584 authenticate, no further action is necessary. If accepted, the 585 registrar sends a REGACK message which MUST indicate the 'apparent 586 address' and SHOULD indicate the 'refresh'/expire time. If no 587 'refresh' is sent a default registration expiration of 60 seconds 588 MUST be assumed by both peers. At any time during this exchange, the 589 registrar may send a REGREJ message to indicate a failure. 591 A registration has a specified time period associated with it for 592 which it is valid. This time period begins when the registrar sends 593 a REGACK message. A registrant may extend that time period be 594 repeating the registration process. A registrant MAY also force an 595 expiration in the registrar by sending the REGREL message. This 596 message may be challenged with REGAUTH or if sufficient credentials 597 were included, it will be accepted with REGACK. In response to a 598 REGAUTH, a REGREL message SHOULD be resent using the specified 599 credentials. 601 See Section 9.3 and Section 9.4 for example call flows. 603 6.1.2. REGREQ Registration Request Message 605 The REGREQ occurs independently of any media-carrying call. A REGREQ 606 MUST include the 'username' IE and SHOULD include the 'refresh' IE. 607 A REGREQ is used both for an initial registration request as well as 608 for a reply to a REGAUTH. As a reply to a REGAUTH message, it MUST 609 include credentials such as a response to a REGAUTH's challenge. 611 Upon receipt of a REGREQ message which has credentials, a registrar 612 MUST determine their validity. If valid, it MUST respond with a 613 REGACK message indicating the time period for which this registration 614 is valid. If the provided credentials are not valid or the registrar 615 cannot validate the credentials, the registrar MUST respond with a 616 REGREJ message. If credentials are not provided, the registrar MUST 617 respond with a REGAUTH message that indicates the available 618 authentication methods. 620 Registrants MUST implement this message and registrars MUST be able 621 to process it. 623 The following table specifies IEs for this message: 625 +------------+----------------+-------------+-------------+ 626 | IE | Section | Status | Comments | 627 +------------+----------------+-------------+-------------+ 628 | Username | Section 8.6.6 | Required | | 629 | | | | | 630 | MD5 Result | Section 8.6.15 | Conditional | per REGAUTH | 631 | | | | | 632 | RSA Result | Section 8.6.16 | Conditional | per REGAUTH | 633 | | | | | 634 | Refresh | Section 8.6.18 | Optional | | 635 +------------+----------------+-------------+-------------+ 637 6.1.3. REGAUTH Registration Authentication Response Message 639 A REGAUTH is a response to a REGREQ or REGREL. It is sent when a 640 registrar requires authentication to permit registration. A REGAUTH 641 message MUST include the 'authentication methods' and 'username' IEs, 642 and the 'MD5 challenge' or 'RSA challenge' IE if the authentication 643 methods include MD5 or RSA. 645 Upon receipt of a REGAUTH message, the registrant MUST resend the 646 REGREQ or REGREL message with one of the requested credentials, if it 647 has the specified credentials. 649 Registrars MUST implement this message and registrants MUST be able 650 to process it. 652 The following table specifies IEs for this message: 654 +--------------+----------------+-------------+---------------+ 655 | IE | Section | Status | Comments | 656 +--------------+----------------+-------------+---------------+ 657 | Username | Section 8.6.6 | Required | | 658 | | | | | 659 | Auth Methods | Section 8.6.13 | Required | | 660 | | | | | 661 | Challenge | Section 8.6.14 | Conditional | If RSA or MD5 | 662 +--------------+----------------+-------------+---------------+ 664 6.1.4. REGACK Registration Acknowledgment Message 666 A REGACK is sent in response to a REGREQ. A REGACK typically 667 includes the 'refresh' IE specifying the number of seconds before the 668 registration will expire. If the 'refresh' IE is not included with a 669 REGACK, a default registration expiration of 60 seconds MUST be 670 assumed. A REGACK MAY also include the 'username' and 'apparent 671 address' IEs to indicate how the peer identifies the registrant. IEs 672 related to caller identification or the time the registration 673 occurred MAY be sent as well. 675 Receipt of a REGACK message requires an ACK in response. 677 Registrars MUST be able to send this message and registrants MUST be 678 able to process it. 680 The following table specifies IEs for this message: 682 +------------------+----------------+----------+----------+ 683 | IE | Section | Status | Comments | 684 +------------------+----------------+----------+----------+ 685 | Username | Section 8.6.6 | Required | | 686 | | | | | 687 | Date Time | Section 8.6.28 | Required | | 688 | | | | | 689 | Apparent Address | Section 8.6.17 | Required | | 690 | | | | | 691 | Message Count | Section 8.6.23 | Optional | | 692 | | | | | 693 | Calling Number | Section 8.6.2 | Optional | | 694 | | | | | 695 | Calling Name | Section 8.6.4 | Optional | | 696 | | | | | 697 | Refresh | Section 8.6.18 | Optional | | 698 +------------------+----------------+----------+----------+ 700 6.1.5. REGREJ Registration Rejection Message 702 A REGREJ indicates that a registration request has been rejected. 703 This rejection can occur for several reasons. A REGREJ MUST include 704 the 'causecode' and 'cause' IEs to specify why registration was 705 rejected. 707 Upon receipt of a REGREJ message, the registrant MUST consider 708 registration process unsuccessful and no further interaction is 709 required. A peer MAY reinitiate the process at later time accounting 710 for potential configuration changes on the registrar or registrant. 712 Both registrants and registrars MUST be capable of sending and 713 processing this message. 715 The following table specifies IEs for this message: 717 +------------+----------------+----------+----------+ 718 | IE | Section | Status | Comments | 719 +------------+----------------+----------+----------+ 720 | Cause | Section 8.6.21 | Required | | 721 | | | | | 722 | Cause Code | Section 8.6.33 | Required | | 723 +------------+----------------+----------+----------+ 725 6.1.6. REGREL Registration Release Request Message 727 A REGREL is used by a registrant for a forced release of a prior 728 registration. It MUST include the 'username' IE to identify the 729 registrant to be released, and MAY include the 'causecode' and 730 'cause' IEs to specify why registration is being released. 732 Upon receipt of this message, a peer MUST authenticate the sender 733 using the provided credentials or send a REGAUTH message requesting 734 them. If authenticated it MUST immediately purge its registration of 735 the specified registrant or send a REGREJ message if the registration 736 is not found. 738 Registrants SHOULD be capable of sending this message and registrars 739 MUST be able to process it. 741 The following table specifies IEs for this message: 743 +----------+----------------+-------------+-------------------------+ 744 | IE | Section | Status | Comments | 745 +----------+----------------+-------------+-------------------------+ 746 | Username | Section 8.6.6 | Required | | 747 | | | | | 748 | MD5 | Section 8.6.15 | Conditional | MD5 or RSA Result is | 749 | Result | | | required | 750 | | | | | 751 | RSA | Section 8.6.16 | Conditional | | 752 | Result | | | | 753 | | | | | 754 | Cause | Section 8.6.21 | Optional | | 755 | | | | | 756 | Cause | Section 8.6.33 | Optional | | 757 | Code | | | | 758 +----------+----------------+-------------+-------------------------+ 760 6.2. Call Leg Management 762 +--------+ HANGUP/ack 763 | | 764 _____________|__ | 765 | | | 766 +--------->| Initial |<----+ 767 | |________________|<---------------------+ 768 | | ^ 769 | start call | | 770 | ---------- | | 771 | send NEW | +-------+ | 772 | | | | rec AUTHREQ | 773 | _____V__V__ | ----------- | 774 | | | | snd AUTHREP | 775 +------------| Waiting |----+ | 776 rec REJECT |___________|------------------------>+ 777 ---------- | | 778 ack | rec HANGUP | 779 | --------- | 780 | snd ack | 781 | | 782 rec ACCEPT | | 783 ---------- | +------+ | 784 snd ack | | | PROCEEDING / ack | 785 _________V___V | RINGING / ack | 786 | | | | 787 | Linked |-----+ | 788 |______________|------------------------>+ 789 | rec HANGUP | 790 rec ANSWER | ---------- | 791 ----------- | snd ack | 792 snd ack | | 793 | | 794 | rec HANGUP | 795 _______V________ --------- | 796 | | snd ack | 797 | UP |--------------------->+ 798 |________________|--------------------->+ 799 finish 800 ------ 801 snd HANGUP 803 Figure 2: Call Origination State Diagram 804 +--------+ rec HANGUP/ack 805 | | 806 _____________V__ | rec NEW(no Auth)/snd AUTHREQ 807 | | | 808 | Initial |-----+ rec NEW(not Auth)/snd REJECT 809 | | 810 |________________|<--------------------+ 811 | | 812 rec NEW | | 813 (valid credentials)| | 814 ---------- | +------+ | 815 snd ACCEPT | | | snd PROCEEDING | 816 _________V___V | snd RINGING | 817 | | | | 818 | Linked |-----+ | 819 | | 820 |______________|------------------------>+ 821 | rec HANGUP | 822 /answered | ---------- | 823 ----------- | snd ack | 824 snd ANSWER | | 825 | rec HANGUP | 826 _______V________ --------- | 827 | | snd ack | 828 | UP |--------------------->+ 829 |________________|--------------------->+ 830 finish 831 ------ 832 snd HANGUP 834 Figure 3: Call Termination State Diagram 836 6.2.1. Overview 838 The IAX protocol can be used to setup 'links' or 'call legs' between 839 two peers for the purposes of placing a call. The process, 840 illustrated in Figure 2 and Figure 3, starts when a peer sends a NEW 841 message indicating the destination 'number' (or name) of a Called 842 Party on the remote peer. The remote peer can respond with either a 843 credentials challenge (AUTHREQ), a REJECT message, or an ACCEPT 844 message. The AUTHREQ message indicates the permitted authentication 845 schemes and SHOULD result in the sending of an AUTHREP message with 846 the requested credentials. The REJECT message indicates the call 847 cannot be established at this time. And ACCEPT indicates that the 848 call leg between these two peers is established and that Higher level 849 call signaling (Section 6.3) MAY proceed. After sending or receiving 850 the ACCEPT message, the Call Leg is in the 'Linked' state and is used 851 to pass call control message until the call is completed. Further 852 detail on messages used for this process can be found in Section 6.3. 854 Call Legs are labeled with a pair of identifiers. Each end of the 855 call leg assigns the source or destination identifier during the call 856 leg creation process. 858 6.2.2. NEW Request Message 860 A NEW message is sent to initiate a call. It is the first call- 861 specific message sent to initiate an actual media exchange between 862 two peers. 'NEW' messages are unique compared to other Call 863 Supervision messages in that they do not require a destination call 864 identifier in their header. This absence is because the remote 865 peer's source call identifier is not created until after receipt of 866 this frame. Before sending a NEW message, the local IAX peer MUST 867 assign a source call identifier that is not currently being used for 868 another call. A time-stamp MUST also be assigned for the call, 869 beginning at zero and incrementing by one each millisecond. Sequence 870 numbers for a NEW message, described in the transport section, 871 (Section 7) are both set to 0. 873 A NEW message MUST include the 'version' IE, and it MUST be the first 874 IE; the order of other IEs is unspecified. A NEW SHOULD generally 875 include IEs to indicate routing on the remote peer, e.g., via the 876 'called number' IE or to indicate a peer partition or ruleset, the 877 'called context' IE. Caller identification and CODEC negotiation IEs 878 MAY also be included. 880 Upon receipt of a NEW message, the receiving peer examines the 881 destination and MUST perform one of the following actions: 883 Send a REJECT response, 885 Challenge the caller with an AUTHREQ response, 887 Accept the call using an ACCEPT message, or 889 Abort the connection using a HANGUP message, although the REJECT 890 message is preferred at this point in call. 892 If the call is accepted, the peer MUST progress the call and further 893 respond with one of PROCEEDING, RINGING, BUSY or ANSWER depending on 894 the status of the called party on the peer. See Section 6.3 for 895 further detail. 897 The following table specifies IEs for the NEW message: 899 +--------------+----------------+-------------+---------------------+ 900 | IE | Section | Status | Comments | 901 +--------------+----------------+-------------+---------------------+ 902 | Version | Section 8.6.10 | Required | | 903 | | | | | 904 | Called | Section 8.6.1 | Required | | 905 | Number | | | | 906 | | | | | 907 | Auto Answer | Section 8.6.24 | Optional | | 908 | | | | | 909 | Codecs Prefs | Section 8.6.35 | Required | | 910 | | | | | 911 | Calling | Section 8.6.29 | Required | | 912 | Presentation | | | | 913 | | | | | 914 | Calling | Section 8.6.2 | Optional | | 915 | Number | | | | 916 | | | | | 917 | Calling TON | Section 8.6.30 | Required | | 918 | | | | | 919 | Calling TNS | Section 8.6.31 | Required | | 920 | | | | | 921 | Calling Name | Section 8.6.4 | Optional | | 922 | | | | | 923 | ANI | Section 8.6.3 | Optional | | 924 | | | | | 925 | Language | Section 8.6.9 | Optional | | 926 | | | | | 927 | DNID | Section 8.6.12 | Optional | | 928 | | | | | 929 | Called | Section 8.6.5 | Conditional | 'Default' assumed | 930 | Context | | | if IE excluded | 931 | | | | | 932 | Username | Section 8.6.6 | Optional | | 933 | | | | | 934 | RSA Result | Section 8.6.16 | Conditional | If challenged with | 935 | | | | RSA. | 936 | | | | | 937 | MD5 Result | Section 8.6.15 | Conditional | If challenged with | 938 | | | | MD5 | 939 | | | | | 940 | Format | Section 8.6.8 | Required | | 941 | | | | | 942 | Capability | Section 8.6.7 | Conditional | | 943 | | | | | 944 | ADSICPE | Section 8.6.11 | Optional | | 945 | | | | | 946 | Date Time | Section 8.6.28 | Optional | Suggested | 947 | Encryption | Section 8.6.34 | Optional | | 948 | | | | | 949 | OSP Token | Section 8.6.42 | Optional | | 950 +--------------+----------------+-------------+---------------------+ 952 6.2.3. ACCEPT Response Message 954 An ACCEPT response is issued when a NEW message is received, and 955 authentication has taken place (if required). It acknowledges 956 receipt of a NEW message and indicates that the call leg has been 957 setup on the terminating side, including assigning a CODEC. An 958 ACCEPT message MUST include the 'format' IE to indicate its desired 959 CODEC to the originating peer. The CODEC format MUST be one of the 960 formats sent in the associated NEW command. 962 Upon receipt of an ACCEPT, an ACK MUST be sent and the CODEC for the 963 call MAY be configured using the 'format' IE from the received 964 ACCEPT. The call then waits for an ANSWER, HANGUP or other call 965 control signal. (See Section 6.3.) If a subsequent ACCEPT message 966 is received for a call which has already started, or has not sent a 967 NEW message, the message MUST be ignored. 969 The following table specifies IEs for this message: 971 +--------+---------------+----------+----------+ 972 | IE | Section | Status | Comments | 973 +--------+---------------+----------+----------+ 974 | Format | Section 8.6.8 | Required | | 975 +--------+---------------+----------+----------+ 977 6.2.4. REJECT Response Message 979 A REJECT response is sent to indicate that a NEW, AUTHREP, DIAL, or 980 ACCEPT request has been denied. It MAY be due to an authentication 981 failure, an invalid username, or if a peer cannot provide a valid 982 password or response to an issued challenge. It MAY also be used to 983 notify a peer of a call setup failure, e.g., when IAX peers cannot 984 negotiate a CODEC to use. Upon receipt of a REJECT message, the call 985 leg is destroyed and no further action is required. (Note: REJECT 986 messages require an explicit ACK.) 988 REJECT messages MAY include the 'causecode' and 'cause' IEs to 989 indicate the rejection reason. 991 The following table specifies IEs for this message: 993 +------------+----------------+----------+----------+ 994 | IE | Section | Status | Comments | 995 +------------+----------------+----------+----------+ 996 | Cause | Section 8.6.21 | Optional | | 997 | | | | | 998 | Cause Code | Section 8.6.33 | Optional | | 999 +------------+----------------+----------+----------+ 1001 6.2.5. HANGUP Request Message 1003 A HANGUP message is sent by either peer and indicates a call tear- 1004 down. It MAY include the 'causecode' and 'cause' IEs to indicate the 1005 reason for terminating the call. Upon receipt of a HANGUP message, 1006 an IAX peer MUST immediately respond with an ACK, and then destroy 1007 the call leg at its end. After a HANGUP message has been received 1008 for a call leg, any messages received which reference that call leg 1009 (i.e., have the same source/destination call identifiers) MUST be 1010 answered with an INVAL message. This indicates that the received 1011 message is invalid because the call no longer exists. 1013 After sending a HANGUP message, the sender MUST destroy the call and 1014 respond to subsequent messages regarding this call with an INVAL 1015 message. 1017 The following table specifies IEs for this message: 1019 +------------+----------------+----------+----------+ 1020 | IE | Section | Status | Comments | 1021 +------------+----------------+----------+----------+ 1022 | Cause | Section 8.6.21 | Optional | | 1023 | | | | | 1024 | Cause Code | Section 8.6.33 | Optional | | 1025 +------------+----------------+----------+----------+ 1027 6.2.6. AUTHREP Authentication Reply Message 1029 An AUTHREP MUST include the appropriate challenge response or 1030 password IE, and is only sent in response to an AUTHREQ. An AUTHREP 1031 requires a response of either an ACCEPT or a REJECT. 1033 Typical reasons for rejecting an AUTHREP include 'destination does 1034 not exist' and 'suitable bearer not found'. 1036 The following table specifies IEs for this message: 1038 +------------+----------------+-------------+----------+ 1039 | IE | Section | Status | Comments | 1040 +------------+----------------+-------------+----------+ 1041 | RSA Result | Section 8.6.16 | Conditional | If RSA | 1042 | | | | | 1043 | MD5 Result | Section 8.6.15 | Conditional | If MD5 | 1044 +------------+----------------+-------------+----------+ 1046 6.2.7. AUTHREQ Authentication Request Message 1048 The AUTHREQ message is sent in response to a NEW message if 1049 authentication is required for the call to be accepted. It MUST 1050 include the 'authentication methods' and 'username' IEs, and the 1051 'challenge' IE if MD5 or RSA authentication is specified. 1053 Upon receiving an AUTHREQ message, the receiver MUST respond with an 1054 AUTHREP or HANGUP message. 1056 The following table specifies IEs for this message: 1058 +--------------+----------------+----------+----------+ 1059 | IE | Section | Status | Comments | 1060 +--------------+----------------+----------+----------+ 1061 | Username | Section 8.6.6 | Required | | 1062 | | | | | 1063 | Auth Methods | Section 8.6.13 | Required | | 1064 | | | | | 1065 | Challenge | Section 8.6.14 | Required | | 1066 +--------------+----------------+----------+----------+ 1068 6.3. Call Control 1070 6.3.1. Overview 1072 IAX's call control messages provide end-to-end signaling functions 1073 common to other telephony control protocols. The messages include 1074 RINGING, ANSWER, BUSY, and PROCEEDING. These messages MUST only be 1075 sent after an IAX call leg has been ACCEPTed. 1077 In response to an exchange starting with a NEW message, typically, 1078 the first call control message is RINGING, however, a PROCEEDING 1079 message MAY precede it or the call MAY proceed directly to the ANSWER 1080 message. If the call is answered, an ANSWER message will be sent. 1081 Other possibilities include a "BUSY" indication, or if the called 1082 party's service cannot be reached, the call will be torn down using 1083 the link-level HANGUP and an appropriate cause code. 1085 If the link was started with a DIAL message, the sequence is an 1086 optional PROCEEDING, then optional RINGING, then ANSWER or BUSY. Of 1087 course, a link level HANGUP MAY occur at any time. 1089 Various private extensions to IAX Control messages have been deployed 1090 for passing application-specific data over IAX control link. One 1091 such extension is an application that controls ham radio 1092 transceivers. An IAX peer that receives a control message that is 1093 not understood MUST respond with the UNSUPPORT message. 1095 The mandatory IAX control messages are explained below. 1097 6.3.2. PROCEEDING Response Message 1099 The PROCEEDING message SHOULD be sent to a calling party when their 1100 call request is being processed by a further network element but has 1101 not yet reached the called party. 1103 Upon receipt of a PROCEEDING message, the peer SHOULD perform 1104 protocol-specific actions to indicate this fact to the calling party, 1105 e.g., tones, an ISUP Proceeding message, etc. If the prior call leg 1106 is utilizing the IAX protocol, a PROCEEDING message MUST be sent to 1107 that peer. The processing of this message at an originating or 1108 transcoding peer is not specified, however, if possible, the status 1109 may be displayed to the calling party. 1111 The PROCEEDING message does not require any IEs. 1113 6.3.3. RINGING Response Message 1115 This message is sent from a terminating party to indicate that that 1116 the called party's service has processed the call request and is 1117 being alerted to the call. A IAX RINGING message MUST be sent to an 1118 IAX-based calling party when the peer determines that the called 1119 party is being alerted, e.g., when their phone is ringing. 1121 Upon receipt of an IAX RINGING message, the peer MUST pass this 1122 indication to the calling party, unless the calling party has already 1123 received such indication. For an initiating peer, this is typically 1124 done by starting the ring-back tone, however, many implementations 1125 start ringback before ringing in order to meet user expectations. If 1126 the calling party is using the IAX protocol, a RINGING message MUST 1127 be passed to this caller. 1129 The RINGING message does not require any IEs. 1131 6.3.4. ANSWER Response Message 1133 This message is sent from the called party to indicate that the party 1134 has accepted the call request and is communicating with the calling 1135 party. Upon receipt of this message, any ring-back or other progress 1136 tones MUST be terminated and the communications channel MUST be 1137 opened. 1139 The ANSWER message does not require any IEs. 1141 6.4. Mid-Call Link Operations 1143 6.4.1. FLASH Request Message 1145 The FLASH message is sent to indicate a mid call feature. Its 1146 interpretation is system dependent and if it is not expected, it 1147 SHOULD be ignored. Typically, this message is only sent from Analog 1148 Telephone adapters when a brief circuit interruption is made during 1149 an answered call. 1151 The FLASH message does not require any IEs. 1153 6.4.2. HOLD Request Message 1155 The HOLD message is sent to cause the remote system to stop 1156 transmitting audio on this channel, and optionally replace the audio 1157 with music or other sounds. If the remote system cannot perform this 1158 request, it SHOULD be ignored. 1160 The HOLD message SHOULD only be sent in IAX calls which are started 1161 using the DIAL message. 1163 The HOLD message does not require any IEs. 1165 6.4.3. UNHOLD Request Message 1167 The UNHOLD message is sent to cause the remote system to resume 1168 transmitting audio on this channel. If the remote system cannot 1169 perform this request, it SHOULD be ignored. 1171 The UNHOLD message SHOULD only be sent in IAX calls after the HOLD 1172 message. 1174 The UNHOLD message does not require any IEs. 1176 6.4.4. QUELCH Request Message 1178 The QUELCH message is sent to cause the remote peer to squelch or 1179 stop transmitting audio on this channel. It MAY replace the audio 1180 sent to the further party with music or other sounds. If the remote 1181 system cannot perform this request, it SHOULD be ignored. 1183 The QUELCH message MUST only be sent in IAX calls after an ACCEPT is 1184 sent or received; it SHOULD only be used on calls which are started 1185 using the NEW message. 1187 The QUELCH message does not require any IEs. 1189 6.4.5. UNQUELCH Request Message 1191 The UNQUELCH message is sent to cause the remote system to resume 1192 transmitting audio on this channel. If it previously replaced the 1193 audio with music or other sounds, it MUST discontinue it immediately. 1194 If the remote system cannot perform this request, it SHOULD be 1195 ignored. 1197 The UNQUELCH message SHOULD only be sent in IAX calls after the 1198 QUELCH message. 1200 The UNQUELCH message does not require any IEs. 1202 6.4.6. TRANSFER Request Message 1204 The TRANSFER message causes the receiving peer to restart the call 1205 using another specified number. The receiving peer MUST be on the 1206 calling side of this call leg and the new call behavior is 1207 unspecified. After processing this message, a HANGUP message SHOULD 1208 be sent and the call leg torn down. 1210 When sending a TRANSFER message, the new number to which the call is 1211 being transferred MUST be included in the CALLED_NUMBER IE and a 1212 CALLED_CONTEXT IE MAY be included. The call leg MUST NOT be used for 1213 anything else and MAY be torn down. 1215 The following table specifies IEs for this message: 1217 +-----------+---------------+----------+----------------------------+ 1218 | IE | Section | Status | Comments | 1219 +-----------+---------------+----------+----------------------------+ 1220 | Called | Section 8.6.1 | Required | | 1221 | Number | | | | 1222 | | | | | 1223 | Called | Section 8.6.5 | Optional | Use this IE if context is | 1224 | Context | | | other than default. | 1225 +-----------+---------------+----------+----------------------------+ 1227 6.5. Call Path Optimization 1229 If a peer is handling a call between two other IAX peers and the peer 1230 no longer has any need to monitor the progress, content, or duration 1231 of the call, it MAY remove itself from the call by directing the 1232 other two peers to communicate directly. This call path 1233 optimization, or "supervised transfer," is done in a manner that 1234 ensures the call will not be lost in the process; the initiating peer 1235 does not give up control of the process until it has confirmed the 1236 other two peers are communicating. Note: the parties involved in the 1237 call are not aware of this operation; it is purely a network 1238 operation. 1240 ________________ 1241 rec TXREJ | | rec TXREL 1242 ---------- *--------->| None |<-----------------+ 1243 snd TXREJ |________________| ack ^ 1244 to other | | | 1245 | V | 1246 | | 1247 | * (From All) | 1248 /Init Transfer | | rec TXREQ | 1249 ------------ | | --------- | 1250 snd TXREQ | | snd TXCNT | 1251 to both | | | 1252 _v___________v__ | 1253 | | | 1254 | Begin |----------------->+ 1255 |________________| | 1256 | | | 1257 rec TXACC | | rec TXREADY | 1258 --------- | | --------- | 1259 snd TXREADY | | x | 1260 | | | 1261 _v___________v__ | 1262 | |----------------->+ 1263 ----------| Ready |---------- | 1264 | |________________| | | 1265 | | | | 1266 /Both Legs Ready| /Both Legs Ready| rec TXMEDIA| | 1267 and not media-only| and media-only | | | 1268 ------------ | ------------ | -----------| | 1269 snd TXREL | snd TXMEDIA | x | | 1270 | | | | 1271 ____V____ _____V___ ___V_____ | 1272 | | | | | | | 1273 | Release | | Media | | Media | | 1274 |_________| |_________| | Pass | | 1275 | |_________| | 1276 | | | 1277 V V | 1278 rec TXCNT +------------------------->+ 1279 ---------- (In any state) 1280 snd TXACC 1282 Figure 4: Call Path Optimization State Diagram 1284 When a peer initiates this procedure, both call legs MUST be in the 1285 UP state, i.e., they MUST have sent or received the ACCEPT message 1286 for that call leg. To start, it sends a TXREQ message with the 1287 addresses and information from the other remote peers to each its 1288 neighbors. If capable of performing this procedure, they begin 1289 transmitting all channel information to both the initiating peer and 1290 the new remote peer. They also send a TXCNT message indicating 1291 packet counts for the call leg to the new remote peer. Each TXCNT 1292 message is acknowledged with a TXACC message. The peers respond by 1293 sending a TXREADY message to the initiator indicating that they have 1294 confirmed the new communications path. When all remote peers have 1295 sent the initiator a TXREADY message, the transfer is successful and 1296 the initiator responds with a TXREL and has finished its involvement 1297 with the call. If during the transfer process, the two remote peers 1298 cannot communicate, they send a TXREJ message to the initiator. An 1299 example is shown in Section 9.5. 1301 These messages are described in the sections which follow: 1303 6.5.1. TXREQ Transfer Request Message 1305 The TXREQ message is sent by a peer to initiate the transfer process. 1306 When sent, It MUST be sent to both adjacent peers involved in the 1307 call. 1309 It MUST include the following Information Elements: 1311 +------------------+----------------+----------+----------+ 1312 | IE | Section | Status | Comments | 1313 +------------------+----------------+----------+----------+ 1314 | Apparent Address | Section 8.6.17 | Required | | 1315 | | | | | 1316 | Call Number | Section 8.6.20 | Required | | 1317 | | | | | 1318 | Transfer ID | Section 8.6.26 | Required | | 1319 +------------------+----------------+----------+----------+ 1321 The Apparent Address is the IP address data structure address for the 1322 other remote peer. The Call Number IE is The callid used by the 1323 other remote peer and the Transfer ID is a unique number assigned by 1324 the initiator. 1326 Upon receipt of a TXREQ message for a valid call from the 1327 corresponding remote peer, a peer MUST respond by attempting to 1328 communicate with the newly specified remote peer. This task is 1329 accomplished by sending a TXCNT message directly to the peer at the 1330 address specified in the Apparent Address parameter. 1332 6.5.2. TXCNT Transfer Connectivity Response Message 1334 The TXCNT message is used to verify connectivity with a potential 1335 replacement peer for a call. It MUST include the TRANSFERID IE. 1336 Upon receipt on a message of this type, and if the peer has 1337 previously received a TXREQ for this call leg, the peer MUST respond 1338 with a TXACC message. 1340 If the TXCNT Message is not successfully transmitted or if a TXACC 1341 message is not received in response to it, the transfer process MUST 1342 be aborted by sending a TXREJ message to the initiating host. 1344 It MUST include the following Information Element: 1346 +----------+----------------+----------+----------------------------+ 1347 | IE | Section | Status | Comments | 1348 +----------+----------------+----------+----------------------------+ 1349 | Transfer | Section 8.6.26 | Required | A unique number assigned | 1350 | ID | | | by the initiator. | 1351 +----------+----------------+----------+----------------------------+ 1353 6.5.3. TXACC Response Message 1355 Like the TXCNT message, the TXACC message is used to verify 1356 connectivity with a potential replacement peer. It MUST include the 1357 TRANSFERID IE. Upon receipt on a message of this type if the peer is 1358 attempting to transfer this call leg, the peer stops sending call 1359 related media to the initiating peer and sends a TXREADY message to 1360 it. 1362 It MUST include the following Information Element: 1364 +----------+----------------+----------+----------------------------+ 1365 | IE | Section | Status | Comments | 1366 +----------+----------------+----------+----------------------------+ 1367 | Transfer | Section 8.6.26 | Required | A unique number assigned | 1368 | ID | | | by the initiator. | 1369 +----------+----------------+----------+----------------------------+ 1371 6.5.4. TXREADY Transfer Ready Response Message 1373 The TXREADY message indicates that the sending peer has verified 1374 connectivity with the peer which it was instructed to transfer the 1375 call. It MUST include the TRANSFERID IE. When TXREADY messages are 1376 received from both remote peers, it MUST discontinue media transport 1377 and send a TXREL message to each peer. 1379 It MUST include the following Information Element: 1381 +----------+----------------+----------+----------------------------+ 1382 | IE | Section | Status | Comments | 1383 +----------+----------------+----------+----------------------------+ 1384 | Transfer | Section 8.6.26 | Required | A unique number assigned | 1385 | ID | | | by the initiator. | 1386 +----------+----------------+----------+----------------------------+ 1388 6.5.5. TXREL Transfer Release Response Message 1390 The TXREL message indicates that the transfer process has 1391 successfully completed. After sending and upon receipt of this 1392 message, no further interaction (other than an ACK, of course) is 1393 needed between the peers on this call-leg. The TXREL is also used to 1394 revert a split-media call (one where the media and signaling follow 1395 different paths) to a call where the media and signaling follow the 1396 same path. 1398 It MUST include the following Information Element: 1400 +-------------+----------------+----------+----------+ 1401 | IE | Section | Status | Comments | 1402 +-------------+----------------+----------+----------+ 1403 | Call Number | Section 8.6.20 | Required | | 1404 +-------------+----------------+----------+----------+ 1406 6.5.6. TXMEDIA Transfer Media Message 1408 The TXREL message indicates that the MEDIA transfer process has 1409 successfully completed. After sending and upon processing of this 1410 message, full frames MUST continue to follow the original signaling 1411 path and media frames MUST follow the newly negotiated path. This 1412 split-path process continues until the call ends with a HANGUP or 1413 peer receives a TXREL message for the call leg. A peer MAY force the 1414 paths to rejoin by sending a TXREL message. 1416 It MUST include the following Information Element: 1418 +-------------+----------------+----------+----------+ 1419 | IE | Section | Status | Comments | 1420 +-------------+----------------+----------+----------+ 1421 | Call Number | Section 8.6.20 | Required | | 1422 +-------------+----------------+----------+----------+ 1424 6.5.7. TXREJ Transfer Rejection Response Message 1426 The TXREJ MAY be sent at anytime during the transfer process to 1427 indicate that the transfer cannot proceed. Upon receiving a TXREJ 1428 message, if the receiver is the initiating peer, it MUST form a TXREJ 1429 message and send it to the other remote peer. 1431 The TXREJ message does not require any IEs. 1433 6.6. Call Tear Down 1435 The messages used to finish a call vary depending on the particular 1436 process the call is in at the time. The terminal messages for a call 1437 are: 1439 HANGUP. See Section 6.2.5. 1441 REJECT. See Section 6.2.4. 1443 TRANSFER. See Section 6.4.6. 1445 TXREADY. See Section 6.5.4. 1447 These messages are discussed in their respective sections. Also, if 1448 the reliable transport procedures determines that messaging cannot be 1449 maintained, the call leg MUST be torn down without any other 1450 indications over the errant IAX call leg. 1452 6.7. Network Monitoring 1454 The IAX protocol has various tools to determine the network load. It 1455 uses the POKE message to monitor reachability of remote peer and the 1456 LAGRQ message to measure the quality of a current call leg including 1457 the jitter buffer delay. 1459 6.7.1. POKE Request Message 1461 A POKE message is sent to test connectivity of a remote IAX peer. It 1462 is similar to a PING message, except that it MUST be sent when there 1463 is no existing call to the remote endpoint. It MAY also be used to 1464 "qualify" a user to a remote peer, so that the remote peer can 1465 maintain awareness of the state of the user. A POKE MUST have 0 as 1466 its destination call number. 1468 Upon receiving a POKE message, the peer MUST respond with a PONG 1469 message. 1471 This message does not require any IEs. 1473 6.7.2. PING Request Message 1475 A PING message is sent to test connectivity of the remote IAX 1476 endpoint on an existing call. Transmission of a PING MAY occur when 1477 a peer-defined number of seconds have passed without receiving an 1478 incoming media frame on a call, or by default every 20 seconds. 1479 Receipt of a PING requires an acknowledging PONG be sent. 1481 This message does not require any IEs. 1483 6.7.3. PONG Response Message 1485 A PONG message is a response to a PING or a POKE. It acknowledges 1486 the connection. The receiver uses the time-stamp of the received 1487 PING or POKE and its times to determine the Round Trip Time of the 1488 connection. Several receiver report IEs MAY be included with a PONG, 1489 including received jitter, received frames, delay, and dropped 1490 frames. Receipt of a PONG requires an ACK. 1492 This message does not require any IEs. 1494 6.7.4. LAGRQ Lag Request Message 1496 A LAGRQ is a lag request. It is sent to determine the lag between 1497 two IAX endpoints, including the amount of time used to process a 1498 frame through a jitter buffer (if any). It requires a clock-based 1499 time-stamp, and MUST be answered with a LAGRP, which MUST echo the 1500 LAGRQ's time-stamp. The lag between the two peers can be computed on 1501 the peer sending the LAGRQ by comparing the time-stamp of the LAGRQ 1502 and the time the LAGRP was received. 1504 This message does not require any IEs. 1506 6.7.5. LAGRP Lag Response Message 1508 A LAGRP is a lag reply, sent in response to a LAGRQ message. It MUST 1509 send the same time-stamp it received in the LAGRQ after passing the 1510 received frame through any jitter buffer the peer has configured. 1512 This message does not require any IEs. 1514 6.8. Digit Dialing 1516 Digit Dialing support is an optional portion of the IAX protocol 1517 designed to support devices that do not maintain their own dial 1518 plans, for instance, analog telephone adapters, or ATAs. The dialing 1519 portion of the IAX protocol MAY be implemented for the client/ 1520 phone-side, server side or not all. The exchanges work as a series 1521 of Dialing Plan requests (DPREQ) each followed by a response (DPREP) 1522 indicating if additional digits SHOULD be collected before sending 1523 the call. The sections that follow describe these messages and the 1524 rules associated with them. 1526 6.8.1. DPREQ Dial Plan Request Message 1528 A DPREQ is a request for the server to analyze the passed called 1529 number and determine if there is a valid dialing pattern on the 1530 remote peer. It MUST include the 'called number' IE to specify what 1531 extension is being queried. This command is used in the case where a 1532 local peer does not handle its own dialplan/extension switching. The 1533 local peer can inquire (as a user dials) how the remote peer 1534 perceives the 'called number'. If a DPREP is received indicating 1535 that the number is valid, a DIAL MAY be sent. 1537 This message MAY be sent by the client and MUST be implemented on 1538 servers which provide IAX dialing support. 1540 It MUST include the following Information Element: 1542 +-------------+----------------+----------+----------+ 1543 | IE | Section | Status | Comments | 1544 +-------------+----------------+----------+----------+ 1545 | Call Number | Section 8.6.20 | Required | | 1546 +-------------+----------------+----------+----------+ 1548 6.8.2. DPREP Dial Plan Response Message 1550 A DPREP is a reply to a DPREQ, containing the status of the dialplan 1551 entry requested in the 'called number' IE of the DPREQ. It MUST 1552 include the 'called number', 'dpstatus', and 'refresh' IEs. The 1553 called number is the same one received in the 'called number' IE of 1554 the DPREQ. The 'dpstatus' IE contains the status of the dialplan 1555 entry referenced by the received called number. The status indicates 1556 whether the called number exists, can exist, needs more digits, or is 1557 invalid. More information can be found in Section 8.6 under the 1558 DPSTATUS information element. The 'refresh' IE specifies the number 1559 of minutes the 'dpstatus' is valid. If the 'refresh' IE is not 1560 present, a default 10 minutes period is assumed. 1562 The sending of this message MUST be implemented by servers which 1563 support IAX dialing. Clients which support IAX dialing MUST be 1564 capable of receiving such messages. 1566 It MUST include the following Information Elements: 1568 +----------+----------------+----------+----------------------------+ 1569 | IE | Section | Status | Comments | 1570 +----------+----------------+----------+----------------------------+ 1571 | Call | Section 8.6.20 | Required | | 1572 | Number | | | | 1573 | | | | | 1574 | Dial | Section 8.6.20 | Required | Indicates if number | 1575 | Plan | | | exists, is a partial | 1576 | Status | | | match, etc. | 1577 | | | | | 1578 | Dial | Section 8.6.20 | Optional | Inclusion is strongly | 1579 | Plan | | | suggested. The default is | 1580 | Refresh | | | 10 minutes. | 1581 +----------+----------------+----------+----------------------------+ 1583 6.8.3. DIAL Request Message 1585 The DIAL message is used with IAX peers that do not maintain their 1586 own dialplan/extension routing. Once an extension is validated by 1587 one or more DPREQ/DPREP exchanges, the number MAY be dialed in a DIAL 1588 message, using the 'called number' IE to specify the extension it is 1589 attempting to reach. The remote peer then handles the remaining 1590 aspects of call setup, including ringing the extension and notifying 1591 the local peer when it has been answered following the same 1592 requirements as the NEW command (Section 6.2.2). 1594 The following table specifies the IEs used by this message: 1596 +-----------+---------------+----------+----------------------------+ 1597 | IE | Section | Status | Comments | 1598 +-----------+---------------+----------+----------------------------+ 1599 | Called | Section 8.6.1 | Required | | 1600 | Number | | | | 1601 | | | | | 1602 | Called | Section 8.6.5 | Optional | Use this IE if context is | 1603 | Context | | | other than default. | 1604 +-----------+---------------+----------+----------------------------+ 1606 6.9. Miscellaneous 1608 6.9.1. ACK acknowledgement Message 1610 An ACK acknowledges the receipt of an IAX message. An ACK is sent 1611 upon receipt of a full frame which does not have any other protocol- 1612 defined response. An ACK MUST have both a source call number and 1613 destination call number. It MUST also not change the sequence number 1614 counters, and MUST return the same time-stamp it received. This 1615 time-stamp allows the originating peer to determine to which message 1616 the ACK is responding. Receipt of an ACK requires no action. 1618 An ACK MAY also be sent as an initial acknowledgment of an IAX 1619 message which requires some other protocol-defined message 1620 acknowledgment, as long as the required message is also sent within 1621 some peer-defined amount of time. This allows the acknowledging peer 1622 to delay transmission of the proper IAX message, which may add 1623 security against brute-force password attacks during authentication 1624 exchanges. 1626 When the following messages are received, an ACK MUST be sent in 1627 return: NEW, HANGUP, REJECT, ACCEPT, PONG, AUTHREP, REGREL, REGACK, 1628 REGREJ, TXREL. ACKs SHOULD not be expected by any peer and their 1629 purpose is purely to force the transport layer to be up to date. 1631 The ACK message does not requires any IEs. 1633 6.9.2. INVAL Invalid Response Message 1635 An INVAL is sent as a response to a received message that is not 1636 valid. This occurs when an IAX peer sends a message on a call after 1637 the remote peer has hungup its end. Upon receipt of an INVAL, a peer 1638 MUST destroy its side of a call. 1640 The INVAL message does not requires any IEs. 1642 6.9.3. VNAK Voice Negative Acknowledgement Message 1644 A VNAK is sent when a message is received out of order, particularly 1645 when a mini frame is received before the first full voice frame on a 1646 call. It is a request for retransmission of dropped messages. A 1647 message is considered out of sequence if the received iseqno is 1648 different than the expected iseqno. On receipt of a VNAK, a peer 1649 MUST retransmit all frames with a higher sequence number than the 1650 VNAK message's iseqno. 1652 The VNAK message does not requires any IEs. 1654 6.9.4. MWI Message Waiting Indicator Request Message 1656 An MWI message is used to indicate to a remote peer that it has one 1657 or more messages waiting. It MAY include the 'msgcount' IE to 1658 specify how many messages are waiting. 1660 The following table specifies IEs used by this message 1662 +----------+----------------+----------+------------+ 1663 | IE | Section | Status | Comments | 1664 +----------+----------------+----------+------------+ 1665 | MSGCOUNT | Section 8.6.23 | Optional | Suggested. | 1666 +----------+----------------+----------+------------+ 1668 6.9.5. UNSUPPORT Unsupported Response Message 1670 An UNSUPPORT message is sent in response to a message that is not 1671 supported by an IAX peer. This occurs when an IAX command with an 1672 unrecognized or unsupported subclass is received. No action is 1673 required upon receipt of this message, though the peer SHOULD be 1674 aware that the message referred to in the optionally included 'IAX 1675 unknown' IE is not supported by the remote peer. 1677 The following table specifies IEs used by this message 1679 +---------+----------------+----------+------------+ 1680 | IE | Section | Status | Comments | 1681 +---------+----------------+----------+------------+ 1682 | UNKNOWN | Section 8.6.22 | Optional | Suggested. | 1683 +---------+----------------+----------+------------+ 1685 6.10. Media Messages 1687 The IAX protocol supports many types of media and these are 1688 transported through the same UDP port as other IAX messages. Voice 1689 and video are unique in that they utilize two different encodings 1690 each with a different support procedures. Abbreviated 'Mini frames' 1691 are normally used for audio and video, however, each time the time- 1692 stamp is a multiple of 32,768 (0x8000 hex), a standard or 'Full 1693 Frame' MUST be sent. This approach facilitates efficiency and 1694 reliability by sending compressed packets, without guaranteed 1695 delivery, most of the time while periodically forcing reliable 1696 exchanges with the peer. If communication fails, call tear-down 1697 procedures are invoked. 1699 Upon receiving any media message, except the abbreviated audio and 1700 video mini frames, an ACK message MUST be sent. The content SHOULD 1701 be passed to an associated application, device, or call leg. The 1702 data MAY be buffered before it is presented to the user. 1704 6.10.1. DTMF Media Message 1706 The message carries a single digit of DTMF (Dual Tone Multiple 1707 Frequency). Useful background information about DTMF can be found in 1709 [RFC4733] and [RFC4734], but, note that IAX does not use the RTP 1710 protocol. 1712 6.10.2. Voice Media Message 1714 The message carries voice data and indicates the CODEC used. 1716 6.10.3. Video Media Message 1718 The frame carries video data and indicates the video format of the 1719 data. 1721 6.10.4. Text Media Message 1723 The frame carries a text message in UTF-8 [RFC3629] format. 1725 6.10.5. Image Media Message 1727 This message carries a single image. The image MUST fit in one 1728 message in this version of the protocol. 1730 6.10.6. HTML Media Message 1732 The HTML message class carries HTML and related data as well as 1733 status about the display of that HTML page. The subclass parameter 1734 indicates the HTML content type. It MAY be a URL, the start, middle 1735 or end of a data block. HTML data MUST be in the format described in 1736 [html401]. 1738 If a peer receives an HTML message for a channel that does not 1739 support HTML, it MUST respond with an HTML message that has the HTML 1740 NOT SUPPORTED indication. 1742 When a devices that supports HTML completes loading the page, it 1743 SHOULD send a LOAD COMPLETE message 1745 6.10.7. Comfort Noise Media Message 1747 This message indicates that comfort noise SHOULD be played. It has a 1748 parameter that indicates the level. The noise is to be locally 1749 generated. 1751 7. Message Transport 1753 IAX is sent over UDP and uses an application level protocol to 1754 provide reliable transport where needed. 1756 With respect to transport, there are two message formats: reliable or 1757 'Full Frames' and unacknowledged 'Mini' or 'Meta' frames. All 1758 messages except certain voice and video messages are reliable. 1759 Reliable messages are transported by a scheme which maintains message 1760 counts and time stamps for both peers involved in the call. The 1761 counts are per call. Each peer maintains a timer for all reliable 1762 messages and MUST periodically retransmit those messages until they 1763 acknowledge or the retry limit is exceeded. 1765 When starting a call, the outgoing and incoming message sequence 1766 numbers MUST both be set to zero. Each reliable message that is sent 1767 increments the message count by one except the ACK, INVAL, TXCNT, 1768 TXACC, and VNAK messages which do not change the message count. The 1769 message includes the outgoing message count and the highest numbered 1770 incoming message which has been received. In addition, it contains a 1771 time-stamp which represents the number of milliseconds since the call 1772 started. Or, in the case of certain network timing messages, it 1773 contains a copy of the time-stamp sent to it. Time-stamps MAY be 1774 approximate, but, MUST be in order. 1776 When any message is received, the time-stamps MUST be checked to make 1777 sure that they are in order. If a message is received out of order, 1778 it MUST be ignored and a VNAK message sent to resynchronize the 1779 peers. And if the message is a reliable message, the incoming 1780 message counter MUST be used to acknowledge all the messages up to 1781 that sequence number which have been sent. 1783 If no acknowledgment is received after a locally configured number of 1784 retries (default 4) the call leg SHOULD be considered unusable and 1785 the call MUST be torn down without any further interaction on this 1786 call leg. 1788 7.1. Trunking 1790 IAX allows multiple media exchanges between the same two peers to be 1791 multiplexed into a single trunk call coalescing media payload into a 1792 combined packet. This decreases bandwidth usage as there are fewer 1793 total packets being transmitted. Trunking MAY occur in one or both 1794 directions of an IAX exchange. A trunk consists of a trunk header 1795 and one or more trunked IAX calls. The trunk message contains a 1796 time-stamp specifying the time of transmission of the trunk frame. 1797 The audio data from the trunked calls are encapsulated in the trunk 1798 frame following the header. Each trunked call consists of two octets 1799 specifying the call's source number, two octets specifying the length 1800 in octets of the media data, and the media data itself. IAX permits 1801 transmitting the time-stamps of each encapsulated mini frame as well, 1802 so that accurate timing information can be used for jitter buffers, 1803 etc. A flag in the meta command header specifies whether the 1804 encapsulated mini frames retain their original time-stamps. If they 1805 do not retain them, they MUST assume the time-stamp in the trunk 1806 header upon being received by the trunk peer. 1808 7.2. Timers 1810 There are various timers in the IAX protocol. There are other 1811 application level timers, such as the call timer and ring timer, 1812 which are beyond the scope of this document. This section describes 1813 the IAX timers and specifies their default values and behavior. 1815 7.2.1. Retransmission Timer 1817 The message retransmission procedures are described in Section 7. On 1818 each call, there is a timer for how long to wait for an 1819 acknowledgment of a message. This timer starts at twice the measured 1820 round trip time from the last PING/PONG command. If a retransmission 1821 is needed, it is exponentially increased until it meets a boundary 1822 value. The maximum retry time period boundary is 10 seconds. 1824 7.2.2. Registration Period Timer 1826 Registrations are valid for a specified time period. It is the 1827 client's responsibility to renew this registration before the time 1828 period expires. The registrations SHOULD be renewed at random 1829 intervals to prevent network congestion. A registrar MUST monitor 1830 this time period and invalidate the registration if the client/ 1831 registrant has not renewed their registration before the timer 1832 elapses. 1834 7.3. NAT Considerations 1836 IAX is very well suited to operating behind NAT due to its single 1837 port approach. This approach eliminates any start of call media 1838 stream delays while the NAT gateway establishes a bidirectional port 1839 association. Deploying a single IAX server behind a NAT gateway 1840 requires little effort. If the server acts as a registrar, the IAX 1841 UDP port on the NAT gateway must be forwarded to the server. If the 1842 server acts as a registrant, the default, 60 second, REGREQ refresh 1843 timer should be sufficient to maintain a port association in the NAT 1844 gateway, however, a static port mapping is preferred. 1846 If multiple servers are to be deployed behind a single NAT gateway, 1847 most NAT gateways require each IAX server to use different UDP ports. 1848 Of course, there may be NAT implementations which recognize when 1849 multiple devices utilize the same private port and and manage it 1850 appropriately. 1852 7.4. Encryption 1854 IAX supports call encryption using the symmetric key, Rijndael [AES] 1855 block cipher (also called AES---Advanced Encryption Standard). 1856 Rijndael is a 128-bit block cipher utilizing a shared secret. IAX 1857 encrypts on a call-by-call basis starting with a plain-text NEW 1858 message indicating, in addition to the other message parameters, that 1859 the call should be encrypted. This indication is given by sending 1860 the ENCRYPTION IE (Section 8.6.34) in the NEW request message. If 1861 the called host supports encryption, it will respond with a plain- 1862 text AUTHREQ message which also includes the ENCRYPTION IE. All 1863 subsequent messages in the call MUST be encrypted. If the called 1864 host does not support encryption, the AUTHREQ sent in response to the 1865 NEW must not include the ENCRYPTION IE and the calling host MUST 1866 either HANGUP the request or continue with the unencrypted call. 1868 The key to use in encrypting the messages is computed by taking the 1869 CHALLENGE IE Section 8.6.14 from the AUTHREQ and concatenating any 1870 one of the shared passwords then computing the 128-bit MD5 digest of 1871 this combination. To decrypt, if there is more than one password for 1872 the peer, each must be tried until the message is successfully 1873 decoded. The key remains constant for the duration of the call. 1874 Only the data portion of the messages are encoded. 1876 8. Message Encoding 1878 8.1. Frame Structure 1880 This section contains the specification for each type of frame that 1881 IAX defines. 1883 8.1.1. Full Frames 1885 Full frames can send signaling or media data. Generally full frames 1886 are used to control initiation, setup, and termination of an IAX 1887 call, but they can also be used to carry stream data (though this is 1888 generally not optimal). 1890 Full frames are sent reliably, so all full frames require an 1891 immediate acknowledgment upon receipt. This acknowledgment can be 1892 explicit via an 'ACK' message (see Section 8.4) or implicit based 1893 upon receipt of an appropriate response to the full frame issued. 1895 The standard full frame header length is 12 octets. 1897 Field descriptions: 1899 'F' bit 1901 This bit specifies whether the frame is a full frame or not. If 1902 the 'F' bit is set to 1 the frame is a full frame. If it is set 1903 to 0 it is not a full frame. 1905 Source call number 1907 This 15-bit value specifies the call number the transmitting 1908 client uses to identify this call. The source call number for an 1909 active call MUST NOT be in use by another call on the same client. 1910 Call numbers MAY be reused once a call is no longer active, i.e. 1911 when either there is positive acknowledgment that the call has 1912 been destroyed or when all possible timeouts for the call have 1913 expired. 1915 'R' bit 1917 This bit specifies whether the frame is being retransmitted or 1918 not. If the 'R' bit is set to 0 the frame is being transmitted 1919 for the first time. If it is set to 1 the frame is being 1920 retransmitted. IAX does not specify a retransmit timeout; this is 1921 left to the implementor. 1923 Destination call number 1924 This 15-bit value specifies the call number the transmitting 1925 client uses to reference the call at the remote peer. This number 1926 is the same as the remote peer's source call number. The 1927 destination call number uniquely identifies a call on the remote 1928 peer. The source call number uniquely identifies the call on the 1929 local peer. 1931 Time-stamp 1933 The time-stamp field contains a 32-bit time-stamp maintained by an 1934 IAX peer for a given call. The time-stamp is an incrementally 1935 increasing representation of the number of milliseconds since the 1936 first transmission of the call. 1938 OSeqno 1940 The 8-bit OSeqno field is the outbound stream sequence number. 1941 Upon initialization of a call, its value is 0. It increases 1942 incrementally as full frames are sent. When the counter 1943 overflows, it silently resets to 0. 1945 ISeqno 1947 The 8-bit ISeqno field is the inbound stream sequence number. 1948 Upon initialization of a call its value is 0. It increases 1949 incrementally as full frames are received. At any time the ISeqno 1950 of a call represents the next expected inbound stream sequence 1951 number. When the counter overflows, it silently resets to 0. 1953 Frametype 1955 The Frametype field identifies the type of message carried by the 1956 frame. See Section 8.2 for more information. 1958 'C' bit 1960 This bit determines how the remaining 7 bits of the Subclass field 1961 are coded. If the 'C' bit is set to 1, the Subclass value is 1962 interpreted as a power of 2. If it is not set, the Subclass value 1963 is interpreted as a simple seven-bit unsigned integer. 1965 1 2 3 1966 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 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 |F| Source Call Number |R| Destination Call Number | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | time-stamp | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | OSeqno | ISeqno | Frame Type |C| Subclass | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | | 1975 : Data : 1976 | | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 Figure 5: Full Frame Binary Format 1981 8.1.2. Mini frames 1983 Mini Frames are so named because their header is a minimal 4 octets. 1984 Mini frames carry no control or signaling data; their sole purpose is 1985 to carry a media stream on an already-established IAX call. They are 1986 sent unreliably. This decision was made because VoIP calls typically 1987 can miss several frames without significant degradation in call 1988 quality while the incurred overhead in ensuring reliability increases 1989 bandwidth requirements and decreases throughput. Further, because 1990 voice calls are typically sent in real time, lost frames are too old 1991 to be reintegrated into the audio stream by the time they can be 1992 retransmitted. 1994 Field descriptions: 1996 'F' bit 1998 Mini frames MUST have the 'F' bit set to 0 to specify that they 1999 are not full frames. 2001 Source call number 2003 The source call number is the number that is used by the 2004 transmitting peer to identify the current call. 2006 time-stamp 2008 Mini frames carry a 16-bit time-stamp, which is the lower 16 bits 2009 of the transmitting peer's full 32-bit time-stamp for the call. 2010 The time-stamp allows synchronization of incoming frames so that 2011 they MAY be processed in chronological order instead of the 2012 (possibly different) order in which they are received. The 16-bit 2013 time-stamp wraps after 65.536 seconds, at which point a full frame 2014 SHOULD be sent to notify the remote peer that its time-stamp has 2015 been reset. A call MUST continue to send mini frames starting 2016 with time-stamp 0 even if acknowledgment of the resynchronization 2017 is not received. 2019 The F bit, source call number, and 16-bit time-stamp comprise the 2020 entire four octet header for a full frame. Following this header is 2021 the actual stream data, of arbitrary length, up to the maximum 2022 supported by the network. 2024 Mini frames are implicitly defined to be of type 'voice frame' 2025 (frametype 2; see Section 8.2). The subclass is implicitly defined 2026 by the most recent full voice frame of a call (i.e. the subclass for 2027 a voice frame specifies the CODEC used with the stream). The first 2028 voice frame of a call SHOULD be sent using the CODEC agreed upon in 2029 the initial CODEC negotiation. On-the-fly CODEC negotiation is 2030 permitted by sending a full voice frame specifying the new CODEC to 2031 use in the subclass field. 2033 1 2 3 2034 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 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 |F| Source call number | time-stamp | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | | 2039 : Data : 2040 | | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 Figure 6: Mini Frame Binary Format 2045 8.1.3. Meta frames 2047 Meta frames serve one of two purposes. Meta video frames allow the 2048 transmission of video streams with an optimized header. They are 2049 similar in purpose to mini voice frames. Meta trunk frames are used 2050 for trunking multiple IAX media streams between two peers into one 2051 header, to further minimize bandwidth consumption. 2053 8.1.3.1. Meta Video Frames 2055 Field descriptions: 2057 'F' bit 2058 Meta video frames MUST have the 'F' bit set to 0 to indicate that 2059 they are not full frames. 2061 Meta Indicator 2063 The meta indicator is a 15-bit field of all zeroes, used to 2064 indicate that the frame is a meta frame. Meta frames are 2065 identifiable because the first 16 bits will always be zero in any 2066 meta frame, whereas full or mini frames will have either the 'F' 2067 bit set or some (nonzero) value for the source call number (or 2068 both). 2070 'V' bit 2072 The 'V' bit in a meta video frame is set to 1 to specify that the 2073 frame is a meta video frame. 2075 Source call number 2077 The call number that is used by the transmitting peer to identify 2078 this video call. 2080 time-stamp 2082 Meta video frames carry a 16-bit time-stamp, which is the lower 16 2083 bits of the transmitting peer's full 32-bit time-stamp for the 2084 call. When this time-stamp wraps, a full frame SHOULD be sent to 2085 notify the remote peer that the time-stamp has been reset to 0. 2087 Following the time-stamp is the actual video stream data. Meta video 2088 frames are implicitly defined to be of type 'video frame' (frametype 2089 3; see Section 8.2). The video CODEC used is implicitly defined by 2090 the subclass of the most recent full video frame of a call. 2092 1 2 3 2093 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 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 |F| Meta Indicator |V| Source Call Number | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 |?| time-stamp | | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2099 | Data | 2100 : : 2101 | | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 Figure 7: Meta Video Frame Binary Format 2105 8.1.3.2. Meta Trunk Frames 2107 IAX natively supports two methods of trunking multiple media streams 2108 between two peers into a single association. The first method sends 2109 a standard meta header, along with a single 32-bit time-stamp 2110 describing the transmission time of the trunk frame. Following the 2111 time-stamp are one or more media frames consisting of the call number 2112 and the length in octets of the stream data included in the frame. 2114 The second method of trunking is very similar to the first. It sends 2115 a standard meta header, including the 32-bit time-stamp describing 2116 the time of transmission of the trunk frame. But the media frames 2117 included in the trunk are actually complete mini frames, including 2118 the 16-bit time-stamp for each call. The first method uses slightly 2119 less bandwidth (2 fewer octets per call in the trunk), while the 2120 second method maintains the individual time-stamps for each call so 2121 that jitter buffering can use the actual time-stamps associated with 2122 a call instead of the (less accurate) time-stamp representing the 2123 entire trunk. Either method is permissible for trunking. 2125 Field descriptions: 2127 'F' bit 2129 Meta trunk frames MUST have the 'F' bit set to 0 to indicate that 2130 they are not full frames. 2132 Meta Indicator 2134 The meta indicator is a 15-bit field of all zeroes, used to 2135 indicate that the frame is a meta frame. Meta frames are 2136 identifiable because the first 16 bits will always be zero in any 2137 meta frame, whereas full or mini frames will have either the 'F' 2138 bit set or some (nonzero) value for the source call number (or 2139 both). 2141 'V' bit 2143 The 'V' bit in a meta trunk frame is set to 0 to specify that the 2144 frame is not a meta video frame. 2146 Meta Command 2148 This seven bit field identifies whether the meta frame is a trunk 2149 or not. A value of '1' indicates that the frame is a meta trunk 2150 frame. All other values are reserved for future use. See the 2151 IANA Registry for additional IAX Meta Command Assignments. 2153 Command Data 2155 This 8-bit field specifies flags for options which apply to a 2156 trunked call. The least significant bit of the field is the 2157 'trunk time-stamps' flag. A value of 0 indicates that the calls 2158 in the trunk do not include their individual time-stamps. A value 2159 of 1 indicates that the calls do each include their own time- 2160 stamp. All other bits are reserved for future use. 2162 Time-stamp 2164 Meta trunk frames carry a 32-bit time-stamp, which represents the 2165 actual time of transmission of the trunk frame. This is distinct 2166 from the time-stamps of the calls included in the trunk. 2168 Following the 32-bit time-stamp is one or more trunked calls. If the 2169 'trunk time-stamps' flag is set to 0, each entry consists of 2 octets 2170 specifying the source call number of the call, 2 octets specifying 2171 the length in octets of the media data, and then the media data. If 2172 the 'trunk time-stamps' flag is set to 1, each entry consists of 2 2173 octets specifying the length in octets of the media data, and then a 2174 mini frame (2 octets specifying source call number, 2 octets 2175 specifying 16-bit time-stamp, and the media data). The following two 2176 diagrams help illustrate pictorially this structure. 2178 1 2 3 2179 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 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 |F| Meta Indicator |V|Meta Command | Cmd Data (0) | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | time-stamp | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 |R| Source Call Number | Data Length (in octets) | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | | 2188 : Data : 2189 | | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 . 2192 . 2193 . 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 |R| Source Call Number | Data Length (in octets) | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | | 2198 : Data : 2199 | | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 Figure 8: Meta Trunk Frame Binary Format (trunk time-stamps 0) 2203 1 2 3 2204 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 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 |F| Meta Indicator |V|Meta Command | Cmd Data (1) | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | time-stamp | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | Data Length (in octets) |R| Source Call Number | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | time-stamp | | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2214 | Data | 2215 : : 2216 | | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 . 2219 . 2220 . 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Data Length (in octets) |R| Source Call Number | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | time-stamp | | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2226 | Data | 2227 : : 2228 | | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 Figure 9: Meta Trunk Frame Binary Format (trunk time-stamps 1) 2233 8.1.4. Encrypted Frames 2235 All of the above frames may be encrypted. The header call numbers 2236 are passed through in the clear, first 4 bytes for a full frame or 2 2237 bytes for a mini frame. The remainder of the frame is padded with 2238 between 16 and 32 bytes of random data, then encrypted with AES each 2239 block being xor'd with the previous block. The padding is added at 2240 the front of the data. 2242 Figure 10 shows a padded full frame before encryption. and Figure 11 2243 shows the frame after encryption. Other frame types follows the same 2244 procedure, except the clear text portion is shorter, as described 2245 above. 2247 1 2 3 2248 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 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 |F| Source Call Number |R| Destination Call Number | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | 12 Random bytes | 2253 | | 2254 | | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | 28 Random bits |padding| 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | | 2259 : between 0 and 15 (as indicated by the padding field above) : 2260 : Random bytes : 2261 | | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | | 2264 : Remainder of Actual Frame : 2265 | | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 Figure 10: Full Frame before encryption 2270 Since AES requires a 16 byte block size, some padding is essential. 2271 This padding has been placed at the beginning of the payload because 2272 it makes it more difficult to take advantage of the predictability of 2273 the IAX frame header. For example, the first encrypted Frame an IAX 2274 client sends within an incoming IAX call is entirely predictable: It 2275 is always an ACK - where even the time-stamp is guessable as it is 2276 the time the AUTHREP packet was sent. 2278 1 2 3 2279 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 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 |F| Source Call Number |R| Destination Call Number | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | Encrypted data | 2284 | Multiple of 16 bytes | 2285 | | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 Figure 11: Frame after encryption 2290 The same encryption rules apply to the miniframes, except that the 2291 initial unencrypted portion is only 2 bytes. 2293 8.2. Frame Types 2295 The IAX protocol specifies 10 types of possible frames for the 2296 "frametype" field of a full frame. They are: 2298 8.2.1. DTMF Frame 2300 The frame carries a single digit of DTMF (Dual Tone Multiple 2301 Frequency). More information about DTMF can be found in RFC 2302 4733[RFC4733] and [RFC4734]. 2304 For DTMF frames, the subclass is the actual DTMF digit carried by the 2305 frame. 2307 8.2.2. Voice Frame 2309 The frame carries voice data. 2311 The subclass specifies the audio format of the data. Predefined 2312 voice formats can be found in Section 8.7 below. 2314 8.2.3. Video Frame 2316 The frame carries video data. 2318 The subclass specifies the video format of the data. Predefined 2319 video formats can be found in Section 8.7 below. 2321 8.2.4. Control Frame 2323 The frame carries session control data, i.e. it refers to control of 2324 a device connected to an IAX endpoint. 2326 The subclass is a value from Section 8.3 describing the device 2327 control signal. 2329 8.2.5. Null Frame 2331 Frames with the Null value MUST NOT be transmitted. 2333 8.2.6. IAX Frame 2335 The frame carries control data that provides IAX protocol specific 2336 endpoint management. This frametype is used to manage IAX protocol 2337 interactions that are generally independent of the type of endpoints. 2339 The subclass is a value from Section 8.4 describing an IAX event. 2341 8.2.7. Text Frame 2343 The frame carries a non-control text message in UTF-8 [RFC3629] 2344 format. 2346 All text frames have a subclass of 0. 2348 8.2.8. Image Frame 2350 The frame carries a single image. 2352 The subclass describes the format of the image from Section 8.7 2353 below. 2355 8.2.9. HTML Frame 2357 The frame carries HTML data. 2359 The subclass is a value from the HTML Subclasses table in 2360 Section 8.5. 2362 8.2.10. Comfort Noise Frame 2364 The frame carries comfort noise. 2366 The subclass is the level of comfort noise in -dBov. 2368 The following table specifies valid Frame Type Values: 2370 +------+-------------+--------------------------+-------------------+ 2371 | TYPE | Description | Subclass Description | Data Description | 2372 +------+-------------+--------------------------+-------------------+ 2373 | 0x01 | DTMF | 0-9, A-D, *, # | Undefined | 2374 | | | | | 2375 | 0x02 | Voice | Audio Compression Format | Data | 2376 | | | | | 2377 | 0x03 | Video | Video Compression Format | Data | 2378 | | | | | 2379 | 0x04 | Control | See Control Frame Types | Varies with | 2380 | | | | subclass | 2381 | | | | | 2382 | 0x05 | Null | Undefined | Undefined | 2383 | | | | | 2384 | 0x06 | IAX Control | See IAX Protocol | Information | 2385 | | | Messages | Elements | 2386 | | | | | 2387 | 0x07 | Text | Always 0 | Raw Text | 2388 | | | | | 2389 | 0x08 | Image | Image Compression Format | Raw image | 2390 | | | | | 2391 | 0x09 | HTML | See HTML Frame Types | Message Specific | 2392 | | | | | 2393 | 0x0A | Comfort | Level in -dBov of | None | 2394 | | Noise | comfort noise | | 2395 +------+-------------+--------------------------+-------------------+ 2397 Refer to the IANA Registry for additional IAX Frame Type values. 2399 8.3. Control Frames Subclasses 2401 The following table specifies valid Control Frame Subclasses: 2403 +-------------+---------------+-------------------------------------+ 2404 | VALUE | Name | Description | 2405 +-------------+---------------+-------------------------------------+ 2406 | 0x01 | Hangup | The call has been hungup at the | 2407 | | | remote end. | 2408 | | | | 2409 | 0x02 | Reserved | Reserved for future use | 2410 | | | | 2411 | 0x03 | Ringing | Remote end is ringing (ringback) | 2412 | | | | 2413 | 0x04 | Answer | Remote end has answered | 2414 | | | | 2415 | 0x05 | Busy | Remote end is busy | 2416 | | | | 2417 | 0x06 | Reserved | Reserved for future use | 2418 | | | | 2419 | 0x07 | Reserved | Reserved for future use | 2420 | | | | 2421 | 0x08 | Congestion | The call is congested. | 2422 | | | | 2423 | 0x09 | Flash Hook | Flash hook | 2424 | | | | 2425 | 0x0a | Reserved | Reserved for future use | 2426 | | | | 2427 | 0x0b | Option | Device-specific options are being | 2428 | | | transmitted | 2429 | | | | 2430 | 0x0c | Key Radio | Key Radio | 2431 | | | | 2432 | 0x0d | Unkey Radio | Unkey Radio | 2433 | | | | 2434 | 0x0e | Call Progress | Call is in progress | 2435 | | | | 2436 | 0x0f | Call | Call is proceeding | 2437 | | Proceeding | | 2438 | | | | 2439 | 0x10 | Hold | Call is placed on hold | 2440 | | | | 2441 | 0x11 | Unhold | Call is taken off hold | 2442 +-------------+---------------+-------------------------------------+ 2444 Refer to the IANA Registry for additional IAX Control Frame Subclass 2445 values. 2447 8.4. IAX Frames 2449 Frames of type 'IAX' are used to provide management of IAX endpoints. 2450 They handle IAX signaling (e.g. call setup, maintenance, and tear- 2451 down). They MAY also handle direct transmission of media data, but 2452 this is not optimal for VoIP calls. They do not carry session- 2453 specific control (e.g., device state), as this is the purpose of 2454 Control Frames. The IAX commands are listed and described below. 2456 The following table specifies all valid IAX Frame values: 2458 +------+-----------+-----------------------------------------+ 2459 | Hex | Name | Description | 2460 +------+-----------+-----------------------------------------+ 2461 | 0x01 | NEW | Initiate a new call | 2462 | | | | 2463 | 0x02 | PING | Ping request | 2464 | | | | 2465 | 0x03 | PONG | Ping or poke reply | 2466 | | | | 2467 | 0x04 | ACK | Explicit acknowledgment | 2468 | | | | 2469 | 0x05 | HANGUP | Initiate call tear-down | 2470 | | | | 2471 | 0x06 | REJECT | Reject a call | 2472 | | | | 2473 | 0x07 | ACCEPT | Accept a call | 2474 | | | | 2475 | 0x08 | AUTHREQ | Authentication request | 2476 | | | | 2477 | 0x09 | AUTHREP | Authentication reply | 2478 | | | | 2479 | 0x0a | INVAL | Invalid message | 2480 | | | | 2481 | 0x0b | LAGRQ | Lag request | 2482 | | | | 2483 | 0x0c | LAGRP | Lag reply | 2484 | | | | 2485 | 0x0d | REGREQ | Registration request | 2486 | | | | 2487 | 0x0e | REGAUTH | Registration authentication | 2488 | | | | 2489 | 0x0f | REGACK | Registration acknowledgement | 2490 | | | | 2491 | 0x10 | REGREJ | Registration reject | 2492 | | | | 2493 | 0x11 | REGREL | Registration release | 2494 | | | | 2495 | 0x12 | VNAK | Video/Voice retransmit request | 2496 | | | | 2497 | 0x13 | DPREQ | Dialplan request | 2498 | | | | 2499 | 0x14 | DPREP | Dialplan reply | 2500 | | | | 2501 | 0x15 | DIAL | Dial | 2502 | | | | 2503 | 0x16 | TXREQ | Transfer request | 2504 | | | | 2505 | 0x17 | TXCNT | Transfer connect | 2506 | | | | 2507 | 0x18 | TXACC | Transfer accept | 2508 | | | | 2509 | 0x19 | TXREADY | Transfer ready | 2510 | | | | 2511 | 0x1a | TXREL | Transfer release | 2512 | | | | 2513 | 0x1b | TXREJ | Transfer reject | 2514 | | | | 2515 | 0x1c | QUELCH | Halt audio/video [media] transmission | 2516 | | | | 2517 | 0x1d | UNQUELCH | Resume audio/video [media] transmission | 2518 | | | | 2519 | 0x1e | POKE | Poke request | 2520 | | | | 2521 | 0x1f | Reserved | Reserved for future use | 2522 | | | | 2523 | 0x20 | MWI | Message waiting indication | 2524 | | | | 2525 | 0x21 | UNSUPPORT | Unsupported message | 2526 | | | | 2527 | 0x22 | TRANSFER | Remote transfer request | 2528 | | | | 2529 | 0x23 | Reserved | Reserved for future use | 2530 | | | | 2531 | 0x24 | Reserved | Reserved for future use | 2532 | | | | 2533 | 0x25 | Reserved | Reserved for future use | 2534 +------+-----------+-----------------------------------------+ 2536 Refer to the IANA Registry for additional IAX Frame values. 2538 8.5. HTML Command Subclasses 2540 IAX HTML Command Subclasses: 2542 +--------+----------------------------+ 2543 | NUMBER | DESCRIPTION | 2544 +--------+----------------------------+ 2545 | 0x01 | Sending a URL | 2546 | | | 2547 | 0x02 | Data frame | 2548 | | | 2549 | 0x04 | Beginning frame | 2550 | | | 2551 | 0x08 | End frame | 2552 | | | 2553 | 0x10 | Load is complete | 2554 | | | 2555 | 0x11 | Peer does not support HTML | 2556 | | | 2557 | 0x12 | Link URL | 2558 | | | 2559 | 0x13 | Unlink URL | 2560 | | | 2561 | 0x14 | Reject Link URL | 2562 +--------+----------------------------+ 2564 Refer to the IANA Registry for additional IAX HTML Command Subclass 2565 values. 2567 8.6. Information Elements 2569 IAX messages sent as full frames MAY carry information elements to 2570 specify user- or call-specific data. Information elements are 2571 appended to a frame header in its data field. Zero, one, or multiple 2572 information elements MAY be included with any IAX message. 2574 Information elements are coded as follows: 2576 The first octet of any information element consists of the "IE" 2577 field. The IE field is an identification number which defines the 2578 particular information element. Table 1 lists the defined 2579 information elements and each information element is defined below 2580 the table. 2582 The second octet of any information element is the "data length" 2583 field. It specifies the length in octets of the information 2584 element's data field. 2586 The remaining octet(s) of an information element contain the 2587 actual data being transmitted. The representation of the data is 2588 dependent on the particular information element as identified by 2589 its "IE" field. Some information elements carry binary data, some 2590 carry UTF-8 [RFC3629] data, and some have no data field at all. 2591 Elements which carry UTF-8 MUST prepare strings as per [RFC3454] 2592 and [RFC3491], so that illegal characters, case folding and other 2593 characters properties are handled and compared properly. The data 2594 representation for each information element is described below. 2596 The following table specifies the Information Element Binary Format: 2598 1 2599 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | IE | Data Length | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | | 2604 : DATA : 2605 | | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 The following is a table of the information elements IAX defines, and 2609 a brief description of each information element's purpose. More 2610 information about each IE may be found below the table. 2612 +------+----------------+-------------------------------------------+ 2613 | HEX | NAME | DESCRIPTION | 2614 +------+----------------+-------------------------------------------+ 2615 | HEX | NAME | DESCRIPTION | 2616 | | | | 2617 | 0x01 | CALLED NUMBER | Number/extension being called | 2618 | | | | 2619 | 0x02 | CALLING NUMBER | Calling number | 2620 | | | | 2621 | 0x03 | CALLING ANI | Calling number ANI for billing | 2622 | | | | 2623 | 0x04 | CALLING NAME | Name of caller | 2624 | | | | 2625 | 0x05 | CALLED CONTEXT | Context for number | 2626 | | | | 2627 | 0x06 | USERNAME | Username (peer or user) for | 2628 | | | authentication | 2629 | | | | 2630 | 0x07 | PASSWORD | Password for authentication | 2631 | 0x08 | CAPABILITY | Actual CODEC capability | 2632 | | | | 2633 | 0x09 | FORMAT | Desired CODEC format | 2634 | | | | 2635 | 0x0a | LANGUAGE | Desired language | 2636 | | | | 2637 | 0x0b | VERSION | Protocol version | 2638 | | | | 2639 | 0x0c | ADSICPE | CPE ADSI capability | 2640 | | | | 2641 | 0x0d | DNID | Originally dialed DNID | 2642 | | | | 2643 | 0x0e | AUTHMETHODS | Authentication method(s) | 2644 | | | | 2645 | 0x0f | CHALLENGE | Challenge data for MD5/RSA | 2646 | | | | 2647 | 0x10 | MD5 RESULT | MD5 challenge result | 2648 | | | | 2649 | 0x11 | RSA RESULT | RSA challenge result | 2650 | | | | 2651 | 0x12 | APPARENT ADDR | Apparent address of peer | 2652 | | | | 2653 | 0x13 | REFRESH | When to refresh registration | 2654 | | | | 2655 | 0x14 | DPSTATUS | Dialplan status | 2656 | | | | 2657 | 0x15 | CALLNO | Call number of peer | 2658 | | | | 2659 | 0x16 | CAUSE | Cause | 2660 | | | | 2661 | 0x17 | IAX UNKNOWN | Unknown IAX command | 2662 | | | | 2663 | 0x18 | MSGCOUNT | How many messages waiting | 2664 | | | | 2665 | 0x19 | AUTOANSWER | Request auto-answering | 2666 | | | | 2667 | 0x1a | MUSICONHOLD | Request musiconhold with QUELCH | 2668 | | | | 2669 | 0x1b | TRANSFERID | Transfer Request Identifier | 2670 | | | | 2671 | 0x1c | RDNIS | Referring DNIS | 2672 | | | | 2673 | 0x1d | Reserved | Reserved for future use | 2674 | | | | 2675 | 0x1e | Reserved | Reserved for future use | 2676 | | | | 2677 | 0x1f | DATETIME | Date/Time | 2678 | | | | 2679 | 0x20 | Reserved | Reserved for future use | 2680 | | | | 2681 | 0x21 | Reserved | Reserved for future use | 2682 | | | | 2683 | 0x22 | Reserved | Reserved for future use | 2684 | | | | 2685 | 0x23 | Reserved | Reserved for future use | 2686 | | | | 2687 | 0x24 | Reserved | Reserved for future use | 2688 | | | | 2689 | 0x25 | Reserved | Reserved for future use | 2690 | | | | 2691 | 0x26 | CALLINGPRES | Calling presentation | 2692 | | | | 2693 | 0x27 | CALLINGTON | Calling type of number | 2694 | | | | 2695 | 0x28 | CALLINGTNS | Calling transit network select | 2696 | | | | 2697 | 0x29 | SAMPLINGRATE | Supported sampling rates | 2698 | | | | 2699 | 0x2a | CAUSECODE | Hangup cause | 2700 | | | | 2701 | 0x2b | ENCRYPTION | Encryption format | 2702 | | | | 2703 | 0x2c | ENCKEY | Reserved for future Use | 2704 | | | | 2705 | 0x2d | CODEC PREFS | CODEC Negotiation | 2706 | | | | 2707 | 0x2e | RR JITTER | Received jitter, as in rfc3550 | 2708 | | | | 2709 | 0x2f | RR LOSS | Received loss, as in rfc3550 | 2710 | | | | 2711 | 0x30 | RR PKTS | Received frames | 2712 | | | | 2713 | 0x31 | RR DELAY | Max playout delay for received frames in | 2714 | | | ms | 2715 | | | | 2716 | 0x32 | RR DROPPED | Dropped frames (presumably by jitter | 2717 | | | buffer) | 2718 | | | | 2719 | 0x33 | RR OOO | Frames received Out of Order | 2720 | | | | 2721 | 0x34 | OSPTOKEN | OSP Token Block | 2722 +------+----------------+-------------------------------------------+ 2724 Table 1: Information Element Definitions 2726 Refer to the IANA Registry for additional IAX Information Element 2727 values. 2729 8.6.1. CALLED NUMBER 2731 The purpose of the CALLED NUMBER information element is to indicate 2732 the number or extension being called. It carries UTF-8-encoded data. 2733 The CALLED NUMBER information element MUST use UTF-8 encoding and not 2734 numeric data because destinations are not limited to E.164 numbers 2735 ([E164]), national numbers, or even digits. It is possible for a 2736 number or extension to include non-numeric characters. The CALLED 2737 NUMBER IE MAY contain a SIP URI, [RFC3261] or a URI in any other 2738 format. The ability to serve a CALLED NUMBER is server dependent. 2740 The CALLED NUMBER information element is generally sent with IAX NEW, 2741 DPREQ, DPREP, DIAL, and TRANSFER messages. 2743 1 2744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | 0x01 | Data Length | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | | 2749 : UTF-8-encoded CALLED NUMBER : 2750 | | 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 8.6.2. CALLING NUMBER 2755 The purpose of the CALLING NUMBER information element is to indicate 2756 the number or extension of the calling entity to the remote peer. It 2757 carries UTF-8-encoded data. 2759 The CALLING NUMBER information element is usually sent with IAX NEW 2760 messages. 2762 1 2763 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | 0x02 | Data Length | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | | 2768 : UTF-8-encoded CALLING NUMBER : 2769 | | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 8.6.3. CALLING ANI 2774 The purpose of the CALLING ANI information element is to indicate the 2775 calling number ANI (Automatic number identification) for billing. It 2776 carries UTF-8-encoded data. 2778 The CALLING ANI information element MAY be sent with an IAX NEW 2779 message, but it is not required. 2781 1 2782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | 0x03 | Data Length | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | | 2787 : UTF-8-encoded CALLING ANI : 2788 | | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 8.6.4. CALLING NAME 2793 The purpose of the CALLING NAME information element is to indicate 2794 the calling name of the transmitting peer. It carries UTF-8-encoded 2795 data. 2797 The CALLING NAME information element is usually sent with IAX NEW 2798 messages. 2800 1 2801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 | 0x04 | Data Length | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | | 2806 : UTF-8-encoded CALLING NAME : 2807 | | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 8.6.5. CALLED CONTEXT 2812 The purpose of the CALLED CONTEXT information element is to indicate 2813 the context (or partition) of the remote peer's dialplan that the 2814 CALLED NUMBER is interpreted. It carries UTF-8-encoded data. 2816 The CALLED CONTEXT information element MAY be sent with IAX NEW or 2817 TRANSFER messages, though it is not required. 2819 1 2820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 | 0x05 | Data Length | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 | | 2825 : UTF-8-encoded CALLED CONTEXT : 2826 | | 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 8.6.6. USERNAME 2831 The purpose of the USERNAME information element is to specify the 2832 identity of the user participating in an IAX message exchange. It 2833 carries UTF-8-encoded data. 2835 The USERNAME information element MAY be sent with IAX NEW, AUTHREQ, 2836 REGREQ, REGAUTH, or REGACK messages, or any time a peer needs to 2837 identify a user. 2839 1 2840 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | 0x06 | Data Length | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | | 2845 : UTF-8-encoded USERNAME : 2846 | | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 8.6.7. CAPABILITY 2851 The purpose of the CAPABILITY information element is to indicate the 2852 media CODEC capabilities of an IAX peer. Its data is represented in 2853 a four octet bitmask according to Section 8.7. Multiple CODECs MAY 2854 be specified by logically OR'ing them into the CAPABILITY information 2855 element. 2857 The CAPABILITY information element is sent with IAX NEW messages if 2858 appropriate for the CODEC negotiation method the peer is using. 2860 1 2861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 | 0x08 | 0x04 | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | CAPABILITY according to Media | 2866 | Format Subclass Values Table | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 8.6.8. FORMAT 2871 The purpose of the FORMAT information element is to indicate a single 2872 preferred media CODEC. When sent with a NEW message, the indicated 2873 CODEC is the desired CODEC an IAX peer wishes to use for a call. 2874 When sent with an ACCEPT message, it indicates the actual CODEC that 2875 has been selected for the call. Its data is represented in a four 2876 octet bitmask according to Section 8.7. Only one CODEC MUST be 2877 specified in the FORMAT information element. 2879 1 2880 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | 0x09 | 0x04 | 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 | FORMAT according to Media | 2885 | Format Subclass Values Table | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 8.6.9. LANGUAGE 2890 The purpose of the LANGUAGE information element is to indicate the 2891 language in which the transmitting peer would like the remote peer to 2892 send signaling information. It carries UTF-8-encoded data and tags 2893 should be selected per [RFC4646] and [RFC4647]. 2895 The LANGUAGE information element MAY be sent with an IAX NEW message. 2897 1 2898 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 | 0x0a | Data Length | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | | 2903 : UTF-8-encoded LANGUAGE : 2904 | | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 8.6.10. VERSION 2909 The purpose of the VERSION information element is to indicate the 2910 protocol version the peer is using. Peers at each end of a call MUST 2911 use the same protocol version. Currently the only supported version 2912 is 2. The data field of the VERSION information element is 2 octets 2913 long. 2915 The VERSION information element MUST be sent with an IAX NEW message. 2917 When sent, the VERSION information element MUST be the first IE in 2918 the message. 2920 1 2921 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | 0x0b | 0x02 | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | 0x0002 | 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 8.6.11. ADSICPE 2930 The purpose of the ADSICPE information element is to indicate the CPE 2931 ADSI capability. The data field of the ADSICPE information element 2932 is 2 octets long. 2934 The ADSICPE information element MAY be sent with an IAX NEW message. 2936 1 2937 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | 0x0c | 0x02 | 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 | ADSICPE Capability | 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 8.6.12. DNID 2946 The purpose of the DNID information element is to indicate the Dialed 2947 Number ID, which may differ from the 'called number'. It carries 2948 UTF-8-encoded data. 2950 The DNID information element MAY be sent with an IAX NEW message. 2952 1 2953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | 0x0d | Data Length | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | | 2958 : UTF-8-encoded DNID Data : 2959 | | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 8.6.13. AUTHMETHODS 2964 The purpose of the AUTHMETHODS information element is to indicate the 2965 authentication methods a peer accepts. It is sent as a bitmask two 2966 octets long. The table below lists the valid authentication methods. 2968 The AUTHMETHODS information element MUST be sent with IAX AUTHREQ and 2969 REGAUTH messages. 2971 1 2972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | 0x0e | 0x02 | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | Valid Authentication Methods | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 The following table lists valid values for authentication: 2981 +--------+--------------------------+ 2982 | METHOD | DESCRIPTION | 2983 +--------+--------------------------+ 2984 | 0x0001 | Reserved (was Plaintext) | 2985 | | | 2986 | 0x0002 | MD5 | 2987 | | | 2988 | 0x0004 | RSA | 2989 +--------+--------------------------+ 2991 Refer to the IANA Registry for additional IAX Authentication Method 2992 values. 2994 8.6.14. CHALLENGE 2996 The purpose of the CHALLENGE information element is to offer the MD5 2997 or RSA challenge to be used for authentication. It carries the 2998 actual UTF-8-encoded challenge data. 3000 The CHALLENGE information element MUST be sent with IAX AUTHREQ and 3001 REGAUTH messages. 3003 1 3004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | 0x0f | Data Length | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | | 3009 : UTF-8-encoded Challenge Data : 3010 | | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 8.6.15. MD5 RESULT 3015 The purpose of the MD5 RESULT information element is to offer an MD5 3016 response to an authentication CHALLENGE. It carries the UTF-8- 3017 encoded challenge result. The MD5 Result value is computed by taking 3018 the MD5 [RFC1321] digest of the challenge string and the password 3019 string. 3021 The MD5 RESULT information element MAY be sent with IAX AUTHREP and 3022 REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE 3023 has been received. This information element MUST NOT be sent except 3024 in response to a CHALLENGE. 3026 1 3027 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 | 0x10 | Data Length | 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3031 | | 3032 : UTF-8-encoded MD5 Result : 3033 | | 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 8.6.16. RSA RESULT 3038 The purpose of the RSA RESULT information element is to offer an RSA 3039 response to an authentication CHALLENGE. It carries the UTF-8- 3040 encoded challenge result. The result is computed as follows: first, 3041 compute the SHA1 digest [RFC3174] of the challenge string and second, 3042 RSA sign the SHA1 digest using the private RSA key as specified in 3043 PKCS #1 v2.0 [PKCS]. The RSA keys are stored locally. 3045 Upon receiving an RSA RESULT information element, its value must be 3046 verified with the sender's public key to match the SHA1 digest 3047 [RFC3174] of the challenge string. 3049 The RSA RESULT information element MAY be sent with IAX AUTHREP and 3050 REGREQ messages if an AUTHREQ or REGAUTH and appropriate CHALLENGE 3051 have been received. This information element MUST NOT be sent except 3052 in response to a CHALLENGE. 3054 1 3055 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | 0x11 | Data Length | 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 | | 3060 : UTF-8-encoded RSA Result : 3061 | | 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 8.6.17. APPARENT ADDR 3066 The purpose of the APPARENT ADDR information element is to indicate 3067 the perceived network connection information used to reach a peer, 3068 which may differ from the actual address when the peer is behind NAT. 3069 The APPARENT ADDR IE is populated using the source address values of 3070 the UDP and IP headers in the IAX message to which this response is 3071 generated. The data field of the APPARENT ADDR information element 3072 is the same as the POSIX sockaddr struct for the address family in 3073 use (i.e., sockaddr_in for IPv4, sockaddr_in6 for IPv6). The data 3074 length depends on the type of address being represented. 3076 The APPARENT ADDR information element MUST be sent with IAX TXREQ and 3077 REGACK messages. When used with a TXREQ message, the APPARENT ADDR 3078 MUST specify the address of the peer the local peer is trying to 3079 transfer its end of the connection to. When used with a REGACK 3080 message, the APPARENT ADDR MUST specify the address it uses to reach 3081 the peer (which may be different than the address the peer perceives 3082 itself as in the case of NAT or multi-homed peer machines). 3084 The data field of the APPARENT ADDR information element is the same 3085 as the linux struct sockaddr_in: two octets for the address family, 3086 two octets for the port number, four octets for the IPv4 address, and 3087 8 octets of padding consisting of all bits set to 0. Thus the total 3088 length of the APPARENT ADDR information element is 18 octets. 3090 The following diagram demonstrates the generic APPARENT ADDR format: 3092 1 3093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3095 | 0x12 | Data Length | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | sockaddr struct | 3098 : for address family in use : 3099 | | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 The following diagram demonstrates the APPARENT ADDR format for an 3103 IPv4 address: 3105 1 3106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | 0x12 | 0x10 | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | 0x0200 | <- Address family (INET) 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | 0x11d9 | <- Portno (default 4569) 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | 32-bit IP address | 3115 | | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | | 3118 | 8 octets of all 0s | 3119 | (padding in sockaddr_in) | 3120 | | 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 The following diagram demonstrates the APPARENT ADDR format for an 3123 IPv6 address: 3125 1 3126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | 0x12 | 0x1C | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3130 | 0x0A00 | <- Address family (INET6) 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 | 0x11d9 | <- Portno (default 4569) 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 | 32 bits | <- Flow information 3135 | | 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | 128-bit IP address | <- Ip6 Address 3138 | | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | 32 bits | <- Scope ID 3141 | | 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 8.6.18. REFRESH 3146 The purpose of the REFRESH information element is to indicate the 3147 number of seconds before an event expires. Its data field is 2 3148 octets long. 3150 The REFRESH information element is used with IAX REGREQ, REGACK, and 3151 DPREP messages. When sent with a REGREQ it is a request that the 3152 peer maintaining the registration set the timeout to REFRESH seconds. 3153 When sent with a DPREP or REGACK, it is informational and tells a 3154 remote peer when the local peer will no longer consider the event 3155 valid. The REFRESH sent with a DPREP tells a peer how long it SHOULD 3156 store the received dialplan response. 3158 If the REFRESH information element is not received with a DPREP, the 3159 expiration of the cache data is assumed to be 10 minutes. If the 3160 REFRESH information element is not received with a REGACK, 3161 registration expiration is assumed to occur after 60 seconds. 3163 1 3164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | 0x13 | 0x02 | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | 2 octets specifying refresh | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 8.6.19. DPSTATUS 3173 The purpose of the DPSTATUS information element is to indicate the 3174 status of a CALLED NUMBER in a remote dialplan. Its data field is a 3175 two octet bitmask specifying flags from the table below. Exactly one 3176 of the low 3 bits MUST be set, and zero, one, or two of the high two 3177 bits MAY be set. 3179 The DPSTATUS information element MUST be sent with IAX DPREP 3180 messages, as it is the payload of the dialplan response. 3182 1 3183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 | 0x14 | 0x02 | 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 |M|R| |N|C|E| 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3190 The following table lists the dialplan status flags: 3192 +--------+------------------------------+ 3193 | FLAG | DESCRIPTION | 3194 +--------+------------------------------+ 3195 | 0x0001 | Exists | 3196 | | | 3197 | 0x0002 | Can exist | 3198 | | | 3199 | 0x0004 | Non-existent | 3200 | | | 3201 | 0x4000 | Retain dialtone (ignorepat) | 3202 | | | 3203 | 0x8000 | More digits may match number | 3204 +--------+------------------------------+ 3206 Refer to the IANA Registry for additional IAX dialplan status values. 3208 8.6.20. CALLNO 3210 The purpose of the CALLNO information element is to indicate the call 3211 number a remote peer needs to use as a destination call number to 3212 identify a call being transferred. The peer managing a transfer 3213 sends the CALLNO for one transfer endpoint to the other transfer 3214 endpoint so that it knows what call number to specify for the 3215 transfer. The data field is 2 octets long and specifies a call 3216 number in the same manner as a source call number or destination call 3217 number is specified in a frame header. 3219 The CALLNO information element MUST be sent with IAX TXREQ, TXREADY, 3220 and TXREL messages. Transferring cannot succeed if the CALLNO IE is 3221 not included with the appropriate transfer messages. 3223 1 3224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3226 | 0x15 | 0x02 | 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 | Callno of transfer recipient | 3229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 8.6.21. CAUSE 3233 The purpose of the CAUSE information element is to indicate the 3234 reason an event occurred. It carries a description of the CAUSE of 3235 the event as UTF-8-encoded data. Notification of the event itself is 3236 handled at the message level. 3238 The CAUSE information element SHOULD be sent with IAX HANGUP, REJECT, 3239 REGREJ, and TXREJ messages. 3241 1 3242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 | 0x16 | Data Length | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | | 3247 : UTF-8-encoded CAUSE of event : 3248 | | 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 8.6.22. IAX UNKNOWN 3253 The purpose of the IAX UNKNOWN information element is to indicate 3254 that a received IAX command was unknown or unrecognized. The one 3255 octet data field contains the subclass of the received frame that was 3256 unrecognized. 3258 The IAX UNKNOWN information element MUST be sent with IAX UNSUPPORT 3259 messages. 3261 1 3262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 | 0x17 | 0x01 | 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 | Rec'd Subclass| 3267 +-+-+-+-+-+-+-+-+ 3269 8.6.23. MSGCOUNT 3271 The purpose of the MSGCOUNT information element is to indicate how 3272 many voicemail messages are waiting in a registered user's mailbox. 3273 The data field is 2 octets long. If it is set to all 1s, there is at 3274 least one message present. Any other value specifies the number of 3275 old messages in the high 8 bits and the number of new messages in the 3276 low 8 bits. 3278 The IAX MSGCOUNT information element MAY be sent with IAX REGACK 3279 messages. 3281 1 3282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 | 0x18 | 0x02 | 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | Old messages | New messages | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3289 8.6.24. AUTOANSWER 3291 The purpose of the AUTOANSWER information element is to request that 3292 a call be auto-answered upon receipt of a NEW message which includes 3293 the AUTOANSWER information element. Note that this is a request and 3294 may or may not be granted by the remote peer. There is no data field 3295 with this information element, as its presence alone indicates all 3296 necessary information. 3298 The AUTOANSWER information element MAY be sent with IAX NEW messages. 3300 1 3301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 | 0x19 | 0x00 | 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 8.6.25. MUSICONHOLD 3308 The purpose of the MUSICONHOLD information element is to request that 3309 music-on-hold be played while a call is in the QUELCH state. The 3310 optional data field specifies a music-on-hold class to be used, as 3311 UTF-8-encoded data. In the absence of a data field, no music-on-hold 3312 class is specified and the IE SHOULD be treated as a generic request 3313 for music-on-hold. 3315 The MUSICONHOLD information element MAY be sent with IAX QUELCH 3316 messages. 3318 If no MUSICONHOLD information element is received, music-on-hold is 3319 not requested. 3321 1 3322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | 0x1a | Data Length | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 | | 3327 : Optional Music On Hold Class : 3328 | | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 8.6.26. TRANSFERID 3333 The purpose of the TRANSFERID information element is to identify a 3334 transfer across all three peers participating in a transfer event. 3335 It carries a number, four octets long, that SHOULD be unique for the 3336 duration of the transfer process. 3338 The TRANSFERID information element SHOULD be sent with IAX TXREQ and 3339 TXCNT messages to aid the peers involved in a transfer in identifying 3340 the proper calls. It is not required as long as the transferring 3341 peers can positively identify the calls participating in the transfer 3342 without the TRANSFERID. 3344 1 3345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | 0x1b | 0x04 | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 | 4 octet transfer | 3350 | identifier | 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3353 8.6.27. RDNIS 3355 The purpose of the RDNIS information element is to indicate the 3356 referring DNIS. It carries UTF-8-encoded data. 3358 1 3359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | 0x1c | Data Length | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | | 3364 : UTF-8-encoded RDNIS : 3365 | | 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 8.6.28. DATETIME 3370 The DATETIME information element indicates the time a message is 3371 sent. This differs from the header time-stamp because that time- 3372 stamp begins at 0 for each call, while the DATETIME is a call- 3373 independent value representing the actual real-world time. The data 3374 field of a DATETIME information element is four octets long and 3375 stores the time as follows: The five least significant bits are 3376 seconds, the next six least significant bits are minutes, the next 3377 least significant five bits are hours, the next least significant 3378 five bits are the day of the month, the next least significant four 3379 bits are the month, and the most significant seven bits are the year. 3380 The year is offset from 2000, and the month is a 1-based index (i.e., 3381 January == 1, February == 2, etc). The timezone of the clock MUST be 3382 UTC to avoid confusion between the peers. 3384 The DATETIME information element SHOULD be sent with IAX NEW and 3385 REGACK messages. However, it is strictly informational. 3387 1 3388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3390 | 0x1f | 0x04 | 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | year | month | day | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | hours | minutes | seconds | 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 8.6.29. CALLINGPRES 3399 The purpose of the CALLINGPRES information element is to indicate the 3400 calling presentation of a caller. The data field is 1 octet long and 3401 contains a value from the table below. 3403 The CALLINGPRES information element MUST be sent with IAX NEW 3404 messages. 3406 1 3407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | 0x26 | 0x01 | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 | Calling Pres. | 3412 +-+-+-+-+-+-+-+-+ 3413 The following table lists valid calling presentation values: 3415 +------+--------------------------------------+ 3416 | FLAG | PRESENTATION | 3417 +------+--------------------------------------+ 3418 | 0x00 | Allowed user/number not screened | 3419 | | | 3420 | 0x01 | Allowed user/number passed screen | 3421 | | | 3422 | 0x02 | Allowed user/number failed screen | 3423 | | | 3424 | 0x03 | Allowed network number | 3425 | | | 3426 | 0x20 | Prohibited user/number not screened | 3427 | | | 3428 | 0x21 | Prohibited user/number passed screen | 3429 | | | 3430 | 0x22 | Prohibited user/number failed screen | 3431 | | | 3432 | 0x23 | Prohibited network number | 3433 | | | 3434 | 0x43 | Number not available | 3435 +------+--------------------------------------+ 3437 Refer to the IANA Registry for additional IAX Calling Presentation 3438 values. 3440 8.6.30. CALLINGTON 3442 The purpose of the CALLINGTON information element is to indicate the 3443 calling type of number of a caller, according to ITU-T Recommendation 3444 Q.931 specifications. The data field is 1 octet long and contains 3445 data from the table below. 3447 The CALLINGTON information element MUST be sent with IAX NEW 3448 messages. 3450 1 3451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 | 0x27 | 0x01 | 3454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3455 | Calling TON | 3456 +-+-+-+-+-+-+-+-+ 3457 The following table lists valid calling type of number values from 3458 ITU-T Recommendation Q.931: 3460 +-------+-------------------------+ 3461 | VALUE | DESCRIPTION | 3462 +-------+-------------------------+ 3463 | 0x00 | Unknown | 3464 | | | 3465 | 0x10 | International Number | 3466 | | | 3467 | 0x20 | National Number | 3468 | | | 3469 | 0x30 | Network Specific Number | 3470 | | | 3471 | 0x40 | Subscriber Number | 3472 | | | 3473 | 0x60 | Abbreviated Number | 3474 | | | 3475 | 0x70 | Reserved for extension | 3476 +-------+-------------------------+ 3478 Refer to the IANA Registry for any additional IAX Calling Type of 3479 Number values. 3481 8.6.31. CALLINGTNS 3483 The CALLINGTNS information element indicates the calling transit 3484 network selected for a call. Values are chosen according to ITU-T 3485 Recommendation Q.931 specifications. The data field is two octets 3486 long. The first octet stores the network identification plan in the 3487 least significant four bits according to the first table below, and 3488 the type of network in the next three least significant bits 3489 according to the second table below. The second octet stores the 3490 actual network identification in UTF-8-encoded data. 3492 The CALLINGTNS information element MUST be sent with IAX NEW 3493 messages. 3495 1 3496 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 | 0x28 | 0x02 | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 | | TON | Plan | UTF-8 Net ID | 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3503 The following tables list the valid values for the data field of the 3504 'calling tns' IE. 3506 Q.931 Network Identification Plan Values: 3508 +------+----------------------------------+ 3509 | BITS | DESCRIPTION | 3510 +------+----------------------------------+ 3511 | 0000 | Unknown | 3512 | | | 3513 | 0001 | Caller Identification Code | 3514 | | | 3515 | 0011 | Data Network Identification Code | 3516 +------+----------------------------------+ 3518 Refer to the IAX Transit Network Identification IANA Registry for any 3519 additional values. 3521 Q.931 Type of Network Values: 3523 +------+--------------------------------------+ 3524 | BITS | DESCRIPTION | 3525 +------+--------------------------------------+ 3526 | 000 | User Specified | 3527 | | | 3528 | 010 | National Network Identification | 3529 | | | 3530 | 011 | International Network Identification | 3531 +------+--------------------------------------+ 3533 Refer to the IAX Type of Network IANA Registry for any additional 3534 values. 3536 8.6.32. SAMPLINGRATE 3538 The purpose of the SAMPLINGRATE information element is to specify to 3539 a remote IAX peer the sampling rate in hertz of the audio data being 3540 the peer will use when sending data. Its data field is 2 octets 3541 long. 3543 If the SAMPLINGRATE information element is not specified, a default 3544 sampling rate of 8 kHz may be assumed. 3546 1 3547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | 0x29 | 0x02 | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 | Sampling Rate in Hertz | 3552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3554 8.6.33. CAUSECODE 3556 The purpose of the CAUSECODE information element is to indicate the 3557 reason a call was REJECTed or HANGUPed. It derives from ITU-T 3558 Recommendation Q.931. The data field is one octet long and contains 3559 an entry from the table below. 3561 The CAUSECODE information element SHOULD be sent with IAX HANGUP, 3562 REJECT, REGREJ, and TXREJ messages. 3564 1 3565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3567 | 0x2a | 0x01 | 3568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3569 | Cause Code | 3570 +-+-+-+-+-+-+-+-+ 3572 +--------+----------------------------------------------------------+ 3573 | NUMBER | CAUSE | 3574 +--------+----------------------------------------------------------+ 3575 | 1 | Unassigned/unallocated number | 3576 | | | 3577 | 2 | No route to specified transit network | 3578 | | | 3579 | 3 | No route to destination | 3580 | | | 3581 | 6 | Channel unacceptable | 3582 | | | 3583 | 7 | Call awarded and delivered | 3584 | | | 3585 | 16 | Normal call clearing | 3586 | | | 3587 | 17 | User busy | 3588 | | | 3589 | 18 | No user response | 3590 | | | 3591 | 19 | No answer | 3592 | | | 3593 | 21 | Call rejected | 3594 | | | 3595 | 22 | Number changed | 3596 | | | 3597 | 27 | Destination out of order | 3598 | 28 | Invalid number format/incomplete number | 3599 | | | 3600 | 29 | Facility rejected | 3601 | | | 3602 | 30 | Response to status enquiry | 3603 | | | 3604 | 31 | Normal, unspecified | 3605 | | | 3606 | 34 | No circuit/channel available | 3607 | | | 3608 | 38 | Network out of order | 3609 | | | 3610 | 41 | Temporary failure | 3611 | | | 3612 | 42 | Switch congestion | 3613 | | | 3614 | 43 | Access information discarded | 3615 | | | 3616 | 44 | Requested channel not available | 3617 | | | 3618 | 45 | Pre-empted (causes.h only) | 3619 | | | 3620 | 47 | Resource unavailable, unspecified (Q.931 only) | 3621 | | | 3622 | 50 | Facility not subscribed (causes.h only) | 3623 | | | 3624 | 52 | Outgoing call barred (causes.h only) | 3625 | | | 3626 | 54 | Incoming call barred (causes.h only) | 3627 | | | 3628 | 57 | Bearer capability not authorized | 3629 | | | 3630 | 58 | Bearer capability not available | 3631 | | | 3632 | 63 | Service or option not available (Q.931 only) | 3633 | | | 3634 | 65 | Bearer capability not implemented | 3635 | | | 3636 | 66 | Channel type not implemented | 3637 | | | 3638 | 69 | Facility not implemented | 3639 | | | 3640 | 70 | Only restricted digital information bearer capability is | 3641 | | available (Q.931 only) | 3642 | | | 3643 | 79 | Service or option not available (Q.931 only) | 3644 | | | 3645 | 81 | Invalid call reference | 3646 | 82 | Identified channel does not exist (Q.931 only) | 3647 | | | 3648 | 83 | A suspended call exists, but this call identity does not | 3649 | | (Q.931 only) | 3650 | | | 3651 | 84 | Call identity in use (Q.931 only) | 3652 | | | 3653 | 85 | No call suspended (Q.931 only) | 3654 | | | 3655 | 86 | Call has been cleared (Q.931 only) | 3656 | | | 3657 | 88 | Incompatible destination | 3658 | | | 3659 | 91 | Invalid transit network selection (Q.931 only) | 3660 | | | 3661 | 95 | Invalid message, unspecified | 3662 | | | 3663 | 96 | Mandatory information element missing (Q.931 only) | 3664 | | | 3665 | 97 | Message type nonexistent/not implemented | 3666 | | | 3667 | 98 | Message not compatible with call state | 3668 | | | 3669 | 99 | Information element nonexistent | 3670 | | | 3671 | 100 | Invalid information element contents | 3672 | | | 3673 | 101 | Message not compatible with call state | 3674 | | | 3675 | 102 | Recovery on timer expiration | 3676 | | | 3677 | 103 | Mandatory information element length error (causes.h | 3678 | | only) | 3679 | | | 3680 | 111 | Protocol error, unspecified | 3681 | | | 3682 | 127 | Internetworking, unspecified | 3683 +--------+----------------------------------------------------------+ 3685 Refer to the IAX Cause Codes IANA Registry for any additional values. 3687 8.6.34. ENCRYPTION 3689 The purpose of the ENCRYPTION information element is to indicate what 3690 encryption methods are accepted for an IAX peer. The data field is a 3691 2 octet bit mask specifying which encryption methods from the table 3692 below are accepted. 3694 The ENCRYPTION information element MAY be sent with IAX NEW and 3695 AUTHREQ messages. 3697 1 3698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3700 | 0x2b | 0x01 | 3701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3702 | Encryption Methods | 3703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 The following table lists valid native encryption methods: 3707 +--------+-------------+ 3708 | METHOD | DESCRIPTION | 3709 +--------+-------------+ 3710 | 0x0001 | AES-128 | 3711 +--------+-------------+ 3713 Refer to the IAX Encryption Methods IANA Registry for any additional 3714 values. 3716 8.6.35. CODEC PREFS 3718 The purpose of the CODEC PREFS information element is to indicate the 3719 CODEC preferences of the calling peer. The data field consists of a 3720 list of CODECs in the peer's order of preference as UTF-8-encoded 3721 data. 3723 The CODEC PREFS information element MAY be sent with IAX NEW 3724 messages. 3726 If the CODEC PREFS information element is absent, CODEC negotiation 3727 takes place via the CAPABILITY and FORMAT information elements. 3729 1 3730 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3732 | 0x2d | Data Length | 3733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3734 | | 3735 : CODEC Prefs Data : 3736 | | 3737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3739 8.6.36. RR JITTER 3741 The purpose of the Receiver Report (RR) JITTER information element is 3742 to indicate the received jitter on a call, per [RFC3550]. The data 3743 field is 4 octets long and carries the current measured jitter. 3745 The RR JITTER information element MAY be sent with IAX PONG messages. 3747 1 3748 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3750 | 0x2e | 0x04 | 3751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3752 | Received Jitter | 3753 | | 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3756 8.6.37. RR LOSS 3758 The purpose of the RR LOSS information element is to indicate the 3759 number of lost frames on a call, per [RFC3550]. The data field is 4 3760 octets long and carries the percentage of frames lost in the first 3761 octet, and the count of lost frames in the next 3 octets. 3763 The RR LOSS information element MAY be sent with IAX PONG messages. 3765 1 3766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3768 | 0x2f | 0x04 | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3770 | Loss Percent | | 3771 +-+-+-+-+-+-+-+-+ Loss Count | 3772 | | 3773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3775 8.6.38. RR PKTS 3777 The purpose of the RR PKTS information element is to indicate the 3778 total number of frames received on a call, per [RFC3550]. The data 3779 field is 4 octets long and carries the count of frames received. 3781 The RR PKTS information element MAY be sent with IAX PONG messages. 3783 1 3784 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 | 0x30 | 0x04 | 3787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3788 | Frames Received Count | 3789 | | 3790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3792 8.6.39. RR DELAY 3794 The purpose of the RR DELAY information element is to indicate the 3795 maximum playout delay for a call, per [RFC3550]. The data field is 2 3796 octets long and specifies the number of milliseconds a frame may be 3797 delayed before it MUST be discarded. 3799 The RR DELAY information element MAY be sent with IAX PONG messages. 3801 1 3802 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 | 0x31 | 0x02 | 3805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3806 | Maximum Playout Delay | 3807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3809 8.6.40. RR DROPPED 3811 The purpose of the RR DROPPED information element is to indicate the 3812 total number of dropped frames for a call, per [RFC3550]. The data 3813 field is 4 octets long and carries the number of frames dropped. 3815 The RR DROPPED information element MAY be sent with IAX PONG 3816 messages. 3818 1 3819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3821 | 0x32 | 0x04 | 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 | Total Frames Dropped | 3824 | | 3825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3827 8.6.41. RR OOO 3829 The purpose of the RR OOO information element is to indicate the 3830 number of frames received out of order for a call, per [RFC3550]. 3831 The data field is 4 octets long and carries the number of frames 3832 received out of order. 3834 The RR OOO information element MAY be sent with IAX PONG messages. 3836 1 3837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3839 | 0x33 | 0x04 | 3840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3841 | Frames Received | 3842 | Out of Order | 3843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3845 8.6.42. OSPTOKEN 3847 The purpose of the OSPTOKEN information element is to carry European 3848 Telecommunications Standards Institute (ETSI) Technical Specification 3849 101 321 [OSP] (also referred to as the Open Settlement Protocol or 3850 OSP) tokens. The OSP tokens will be used to provide authorization, 3851 authentication and account support for IAX by using the OSP protocol. 3852 The first octet of the data field is the OSP token block index 3853 starting from 0. 3855 The OSPTOKEN information element MAY only be sent with IAX NEW 3856 messages. If the token is not supported by the receiver, it is 3857 ignored. 3859 1 3860 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 | 0x34 | Data Length | 3863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3864 | Block Index | | 3865 +-+-+-+-+-+-+-+-+ + 3866 | OSP Token Block | 3867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 8.7. Media Formats 3870 Media Format Values 3872 +------------+-----------------+------------------------------------+ 3873 | SUBCLASS | DESCRIPTION | LENGTH CALCULATION | 3874 +------------+-----------------+------------------------------------+ 3875 | 0x00000001 | G.723.1 | 4, 20, and 24 byte frames of 240 | 3876 | | | samples | 3877 | | | | 3878 | 0x00000002 | GSM Full Rate | 33 byte chunks of 160 samples or | 3879 | | | 65 byte chunks of 320 samples | 3880 | | | | 3881 | 0x00000004 | G.711 mu-law | 1 byte per sample | 3882 | | | | 3883 | 0x00000008 | G.711 a-law | 1 byte per sample | 3884 | | | | 3885 | 0x00000010 | G.726 | | 3886 | | | | 3887 | 0x00000020 | IMA ADPCM | 1 byte per 2 samples | 3888 | | | | 3889 | 0x00000040 | 16-bit linear | 2 bytes per sample | 3890 | | little-endian | | 3891 | | | | 3892 | 0x00000080 | LPC10 | Variable size frame of 172 samples | 3893 | | | | 3894 | 0x00000100 | G.729 | 20 bytes chunks of 172 samples | 3895 | | | | 3896 | 0x00000200 | Speex | Variable | 3897 | | | | 3898 | 0x00000400 | ILBC | 50 bytes per 240 samples | 3899 | | | | 3900 | 0x00000800 | G.726 AAL2 | | 3901 | | | | 3902 | 0x00001000 | G.722 | 16kHz ADPCM | 3903 | | | | 3904 | 0x00002000 | AMR | Variable | 3905 | | | | 3906 | 0x00010000 | JPEG | | 3907 | | | | 3908 | 0x00020000 | PNG | | 3909 | | | | 3910 | 0x00040000 | H.261 | | 3911 | | | | 3912 | 0x00080000 | H.263 | | 3913 | | | | 3914 | 0x00100000 | H.263p | | 3915 | | | | 3916 | 0x00200000 | H.264 | | 3917 +------------+-----------------+------------------------------------+ 3918 Refer to the IANA Registry for any additional IAX Media Format 3919 values. 3921 9. Example Message Flows 3923 This section includes call flow diagrams for some of the various 3924 types of IAX calls that can be made. In each diagram, the '=' 3925 character represents a full frame and the '-' character represents a 3926 mini frame. Notes applicable to a generic call may be presented 3927 alongside each diagram. 3929 9.1. Ping/Pong 3931 PING->PONG 3933 Peer A Peer B 3934 ________________________________________ 3935 | | 3936 T | | 3937 i | ===PING============================> | 3938 m | | 3939 e | <============================PONG=== |Has same time-stamp 3940 | | as received PING. 3941 | | ===ACK=============================> |Has same time-stamp 3942 | | | as received PONG 3943 \ / |________________________________________| and original PING 3945 9.2. Lagrq/Lagrp 3947 LAGRQ->LAGRP 3949 Peer A Peer B 3950 ________________________________________ 3951 | | 3952 T | | 3953 i | ===LAGRQ===========================> | 3954 m | | 3955 e | <===========================LAGRP=== |Same time-stamp as 3956 | | received LAGRQ. 3957 | | ===ACK=============================> |Same time-stamp as 3958 | | | received LAGRP and 3959 \ / |________________________________________| original LAGRQ. 3961 9.3. Registration 3963 Registration of an IAX Peer 3965 Registrant A Registrar B 3966 ________________________________________ 3967 | | 3968 T | ===REGREQ==========================> | 3969 i | | 3970 m | <=========================REGAUTH=== | 3971 e | | 3972 | ===REGREQ==========================> | 3973 | | | 3974 | | <==========================REGACK=== | 3975 \ | / | | 3976 \|/ | ===ACK=============================> | 3977 | | 3978 |________________________________________| 3980 9.4. Registration Release 3982 Registration Release 3984 Registrant A Registrar B 3985 ________________________________________ 3986 | | 3987 T | ===REGREL==========================> | 3988 i | | 3989 m | <=========================REGAUTH=== | 3990 e | | 3991 | ===REGREL==========================> | 3992 | | | 3993 | | <==========================REGACK=== | 3994 \ | / | | 3995 \|/ | ===ACK=============================> | 3996 | | 3997 |________________________________________| 3999 9.5. Call Path Optimization 4001 IAX Transfer 4003 Peer L Peer C Peer R 4004 ________________________________________ 4005 | | | 4006 T | | | 4007 | <== TXREQ =====[*]== TXREQ =========> |C requests transfer 4008 i | | | 4009 | ========================== TXCNT ==> |L sends to R 4010 m | | | 4011 | <========================= TXACC ==== |R replies 4012 e | | |R sends Media 4013 | | | to L 4014 | | | | 4015 | | = TXREADY ====> | |L tells C 'ready' 4016 | | | | C stops media to L 4017 | | | | 4018 | | <== TXCNT =========================== |L sends to R 4019 | | | | 4020 | | === TXACC ===========================> |R replies 4021 \ / | | | 4022 | | <== TXREADY ====== |R tells C 'ready' 4023 | | | C stops media to R 4024 | | | 4025 | <== TXREL =====[*]== TXREL =========> |C Releases 4026 | | 4027 |________________________________________| 4029 9.6. IAX Media Call 4031 Complete end-to-end IAX media exchange 4033 Peer A Peer B 4034 ________________________________________ 4035 | | 4036 | ====NEW============================> | 4037 T | <=========================AUTHREQ=== |If authentication 4038 | | specified. 4039 i | ====AUTHREP========================> | 4040 m | <==========================ACCEPT=== | 4041 e | ====ACK============================> | 4042 | | 4043 | | <=============Voice (full frame)=== | 4044 | | ====ACK===========================> | 4045 | | | 4046 | | <---------Voice miniframe (ring)--- | 4047 | | <---------Voice miniframe (ring)--- | 4048 | | | 4049 \ | / | <=========================RINGING=== | 4050 \|/ | ====ACK============================> | 4051 | | 4052 | <---------Voice miniframe (ring)--- | 4053 | <---------Voice miniframe (ring)--- | 4054 | | 4055 | <==========================ANSWER=== | 4056 | ====ACK============================> | 4057 | | 4058 | ====Voice (full frame)=============> | 4059 | <=============================ACK=== | 4060 | | 4061 | | 4062 | <-----------Voice miniframes-------> | exchange occurs 4063 | <--- . ---> | 4064 | <--- . ---> | 4065 | <--- . ---> | 4066 | <-----------Voice miniframes-------> | 4067 | | 4068 | | 4069 | ====Voice (full frame)=============> | (note 1) 4070 | <===ACK============================= | (note 2) 4071 | | (every 65536 ms). 4072 | <=============Voice (full frame)==== | (note 3) 4073 | ====ACK============================> | 4074 | | 4075 | | 4076 | <-----------Voice miniframes-------> | 4077 | <--- . ---> | 4078 | <--- . ---> | 4079 | <--- . ---> | 4080 | <-----------Voice miniframes-------> | 4081 | | 4082 | | 4083 | ====HANGUP=========================> | Either can hangup 4084 | <=============================ACK=== | 4085 |________________________________________| 4087 Note 1: Mini Frames carry the low 16 bits of the peer's 4088 32-bit time-stamp. 4089 Note 2: Full frames re-sync the 32 bit time-stamp when the 16 bit 4090 time-stamp overflows. 4092 Note 3:Each side has its own 32 bit time-stamp so each side needs 4093 to sync at 16 bit overflow. 4095 9.7. IAX Media Call via an IAX Device 4097 An IAX peer is not required to maintain a complete dialplan. In the 4098 event that a user wishes to dial from an IAX peer which does not 4099 switch its own calls, the following call flow diagram may represent 4100 the transaction: 4102 Peer A (IAX Device) Peer B (Dialplan Server) 4103 ________________________________________ 4104 | | 4105 | ====NEW============================> | 4106 T | <=========================AUTHREQ=== | If auth specified 4107 i | ====AUTHREP========================> | 4108 m | <==========================ACCEPT=== | 4109 e | ====ACK============================> | 4110 | | 4111 | ====DPREQ==========================> | (Note 1) 4112 | | <===========================DPREP=== | 4113 | | | 4114 | | ====DIAL===========================> | 4115 | | <========================PROGRESS=== | 4116 | | ====ACK============================> | 4117 \ | / | <==========================ANSWER=== | 4118 \|/ | ====ACK============================> | 4119 | | 4120 | ====Voice (full frame)=============> | 4121 | <=============================ACK=== | 4122 | <=============Voice (full frame)==== | 4123 | ====ACK============================> | 4124 | | 4125 | | 4126 | <-----------Voice miniframes-------> | Media exchange 4127 | <--- . ---> | 4128 | <--- . ---> | 4129 | <--- . ---> | 4130 | <-----------Voice miniframes-------> | 4131 | | 4132 | | 4133 | ====Voice (full frame)=============> | (note 2) 4134 | <===ACK============================= | (note 3) 4135 | | (every 65536 ms). 4136 | <=============Voice (full frame)==== | (Note 4) 4137 | ====ACK============================> | 4138 | | 4139 | | 4140 | <-----------Voice miniframes-------> | 4141 | <--- . ---> | 4142 | <--- . ---> | 4143 | <--- . ---> | 4144 | <-----------Voice miniframes-------> | 4145 | | 4146 | | 4147 | ====HANGUP=========================> | Either can hangup 4148 | <=============================ACK=== | 4149 |________________________________________| 4151 Note 1: There will be multiple DPREQ/DPREPs per call unless 4152 dialed number is 1 digit long 4153 Note 2: Mini Frames carry the low 16 bits of the peer's 4154 32 bit time-stamp. 4155 Note 3: Full frames re-sync the 32 bit time-stamp when the 16 bit 4156 time-stamp overflows 4157 Note 4: Each side has its own 32 bit time-stamp so each side needs 4158 to sync at 16 bit overflow. 4160 10. Security Considerations 4162 IAX is a binary protocol for setting up point-to-point call legs 4163 which includes both media and signaling. As such, it is simpler to 4164 secure than other more general purpose VoIP protocols, however, 4165 security remains a difficult task and various aspects of the protocol 4166 must be examined to identify risks. 4168 IAX registration is an area that requires careful attention. 4169 Previous protocol versions supported clear text passwords, this 4170 feature has been eliminated. The MD5 and RSA alternatives offer much 4171 higher security. Although not specified by the IAX protocol, some 4172 implementations limit the number of registrants per account to one. 4173 And a subsequent registrant with the same credentials would overwrite 4174 the prior and receive the calls destined for that user. Theft of 4175 service is trivial once a malicious caller has the ability to 4176 authenticate. In addition, since distinct cause codes are returned 4177 to erroneous registration attempts, an attacker can distinguish 4178 between existent and nonexistent users in a registration system, thus 4179 resulting in a possible directory harvest attack. 4181 The IAX protocol protects against message replay by using a challenge 4182 response method. The IAX registrar or server challenges each call or 4183 registration with an arbitrary MD5 or RSA challenge. The response 4184 and subsequent authorization relies upon knowledge of a shared 4185 secret. Since the server typically chooses a challenges using a 4186 random number-based technique, the challenge set is large, making 4187 replay highly unlikely. 4189 Although operation in the following manner is not recommended, the 4190 IAX protocol does permit servers to forego the challenge process 4191 described above. This open approach is inherently insecure and does 4192 nothing to prevent unauthorized or usage. 4194 Call Encryption in IAX starts by utilizing static keys. Once 4195 negotiated, the key may be changed for the remainder of the call. 4196 Once the initial key is compromised, all subsequent calls are subject 4197 to interception. A more secure implementation would update the key 4198 frequently and as early as practical during each call. 4200 The IAX protocol is also susceptible to eavesdropping. Call Detail, 4201 i.e., who is calling whom, is sent in unencrypted binary whether the 4202 call is to be encrypted or not. Without encryption, call content, 4203 i.e., audio and video, may be easily intercepted. However, this 4204 content is protected if the call is encrypted. 4206 Man in the middle attacks are a threat to IAX if encryption is not 4207 used. This form of attack permits message insertion, deletion, and 4208 modification such that a call may be redirected or the audio or video 4209 replaced in either or both directions for the complete or any portion 4210 of a call. If encryption is used, the call is protected end to end. 4211 Note: an initial NEW message in an encrypted call is unencrypted and 4212 could be changed; however, this is limited to a denial of service 4213 attack because subsequent messages containing the same address 4214 information are redelivered in an encrypted form. 4216 Denial of service attacks can take at least two forms in IAX. One is 4217 simply overloading the peers with bogus requests. A carefully 4218 implemented IAX peer would identify this situation and raise an alarm 4219 or take other protective action. 4221 Another form of denial of service (DoS) against an existing call is 4222 an engineered attack against an existing call. Injecting media, 4223 causing excess processing by inserting out of order packets, and 4224 sending commands such as hangup or transfer. These attacks require 4225 close monitoring of the binary channel to be successful as the 4226 message sequence numbers would need to be synchronized with the 4227 protocol exchange. 4229 Of course, providing lower layer security with DTLS [RFC4347], or 4230 IPSEC, [RFC4301], would address many of these potential issues. 4232 Unicode, [RFC3629] , and [RFC3454] security considerations also 4233 apply. 4235 11. IANA Considerations 4237 In order to facilitate the orderly extension of the the IAX protocol, 4238 several IANA Registries have been created. These registries requests 4239 are found in [IAX-IANA]. In addition, this document requests 4240 registration of the "iax" URI Scheme. See Section 5. IAX also 4241 requires a well-known UDP port to be assigned. The current port in 4242 use is 4569. 4244 12. Implementation Notes 4246 The original IAX implementation was in Asterisk, the open-source pbx, 4247 but [wikipedia] lists thirteen other publicly available 4248 implementations at the time of this writing. Some of these 4249 implementations used draft versions of this specification. Many 4250 others were developed using the Asterisk source code as the only 4251 specification. While this approach is definitive, it is very 4252 difficult to determine the protocols higher level logic and optimize 4253 it for the particular programming language or application 4254 environment. Interoperability of these implementations can not be 4255 guaranteed. 4257 Aside from the trials and tribulations of reverse engineering the 4258 source code to create a new implementation, the key lessons learned 4259 involve the use of threads, support of international character sets, 4260 security, and improved controls to limit interference during denial 4261 of service attacks. 4263 The current Asterisk implementation has a limited number of IAX 4264 worker threads and, as a result, its scalability is limited, but it 4265 can run on low end machines where threads may not be freely 4266 available. Improving the threading model will undoubtedly improve 4267 performance. 4269 Internationalization and localization are issues that were not 4270 originally addressed by most implementations. It was always on the 4271 IAX developers' road map, but never a priority. While creating this 4272 document, we formalized support for UTF-8 encoding to better support 4273 Internationalization and localization. 4275 With regards to security, many IAX implementations permit clear text 4276 authentication. This method is not secure and should not be used. 4278 Recently, some issues have been raised regarding server robustness 4279 when under a denial of service attack. IAX servers which support 4280 unauthenticated requests can receive the equivalent of a SYN attack. 4281 To mitigate the impact of these attacks, various controls to limit 4282 the number of unauthenticated calls and the number of calls per user 4283 may be added to the implementation. Other approaches, such as 4284 transferring the call to another, more protected port or using IP 4285 rate limiting when excessive failures are detected, are also 4286 suggested. 4288 Lastly, given the open nature of the protocol and implementations, it 4289 is very easy to extend. This situation makes Postel's Robustness 4290 Principle, "Be conservative in what you do, be liberal in what you 4291 accept from others," essential to any successful IAX implementation. 4293 13. Acknowledgments 4295 This work was supported by Internet Foundation Austria. The authors 4296 would like to thank Birgit Arkesteijn, Marc Blanchet, Mohamed 4297 Boucadair, Steve Kann, Olle Johansson, Alexander Mayrhofer, Tim 4298 Panton, and Peter Saint-Andre for their extensive review and 4299 technical input. We would also like to thank Jim Dalton, Christopher 4300 DeMarco, Frank Ellermann, Daniel Medeiros, Dimitri E. Prado, Leif 4301 Madson, and Tilghman Lesher for their support and suggestions. 4303 14. References 4305 14.1. Normative References 4307 [AES] U.S. Department of Commerce/N.I.S.T., "FIPS-197, 4308 Announcing the Advanced Encryption Standard", 4309 November 2001. 4311 [E164] ITU-T, "The International Public Telecommunication Number 4312 Plan", Recommendation E.164, May 1997. 4314 [OSP] European Telecommunications Standards Institute, 4315 "Telecommunications and Internet Protocol Harmonization 4316 Over Networks (TIPHON) Release 4; Open Settlement 4317 Protocol (OSP) for Inter-Domain pricing, authorization 4318 and usage exchange", November 2003. 4320 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 4321 April 1992. 4323 [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES 4324 Transform", RFC 1851, September 1995. 4326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4327 Requirement Levels", BCP 14, RFC 2119, March 1997. 4329 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4330 A., Peterson, J., Sparks, R., Handley, M., and E. 4331 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4332 June 2002. 4334 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 4335 Standards (PKCS) #1: RSA Cryptography Specifications 4336 Version 2.1", RFC 3447, February 2003. 4338 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 4339 Internationalized Strings ("stringprep")", RFC 3454, 4340 December 2002. 4342 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 4343 Profile for Internationalized Domain Names (IDN)", 4344 RFC 3491, March 2003. 4346 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4347 Jacobson, "RTP: A Transport Protocol for Real-Time 4348 Applications", STD 64, RFC 3550, July 2003. 4350 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 4351 10646", STD 63, RFC 3629, November 2003. 4353 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4354 Resource Identifier (URI): Generic Syntax", STD 66, 4355 RFC 3986, January 2005. 4357 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4358 Security", RFC 4347, April 2006. 4360 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 4361 Languages", BCP 47, RFC 4646, September 2006. 4363 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 4364 BCP 47, RFC 4647, September 2006. 4366 [html401] Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 4367 Specification", World Wide Web Consortium 4368 Recommendation REC-html401-19991224, December 1999, 4369 . 4371 14.2. Informative References 4373 [IAX-IANA] 4374 Guy, E., "IANA Considerations for IAX: Inter-Asterisk 4375 eXchange Version 2", draft-guy-iaxiana-00 Work In 4376 Progress, October 2008. 4378 [PKCS] RSA Laboratories, "PKCS #1 v2.0: RSA Cryptography 4379 Standard", October 1998. 4381 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 4382 (SHA1)", RFC 3174, September 2001. 4384 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 4385 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 4387 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 4388 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 4390 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 4391 Resource Identifiers (URI) Dynamic Delegation Discovery 4392 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 4394 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4395 Internet Protocol", RFC 4301, December 2005. 4397 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 4398 Registration Procedures for New URI Schemes", BCP 115, 4399 RFC 4395, February 2006. 4401 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4402 Description Protocol", RFC 4566, July 2006. 4404 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 4405 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 4406 December 2006. 4408 [RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for 4409 Modem, Fax, and Text Telephony Signals", RFC 4734, 4410 December 2006. 4412 [wikipedia] 4413 http://en.wikipedia.org/wiki/IAX, "Inter-Asterisk 4414 eXchange". 4416 Authors' Addresses 4418 Mark A. Spencer 4419 Digium, Inc. 4420 150 West Park Loop Suite 100 4421 Huntsville, AL 35806 4422 US 4424 Phone: +1 256 428 6000 4425 Email: markster@digium.com 4426 URI: http://www.digium.com/ 4428 Brian Capouch 4429 Saint Joseph's College 4430 PO Box 909 4431 Rensselaer, IN 47978 4432 US 4434 Phone: +1 219 866 6114 4435 Email: brianc@saintjoe.edu 4437 Ed Guy (editor) 4438 TruPhone 4439 235 Main Street, STE 253 4440 Madison, NJ 07940 4441 US 4443 Phone: +1 973 437 4519 4444 Email: edguy@emcsw.com 4445 URI: http://www.TruPhone.com/ 4447 Frank Miller 4448 Cornfed Systems, Inc. 4449 103 Overhill Road 4450 Baltimore, MD 21210 4451 US 4453 Phone: +1 410 404-8790 4454 Email: fwmiller@cornfed.com 4455 URI: http://www.digium.com/ 4456 Kenneth C. Shumard 4457 3818 N Lakegrove Way 4458 Boise, ID 83713 4459 US 4461 Phone: +1 208 724 7801 4462 Email: kshumard@gmail.com 4464 Full Copyright Statement 4466 Copyright (C) The IETF Trust (2008). 4468 This document is subject to the rights, licenses and restrictions 4469 contained in BCP 78, and except as set forth therein, the authors 4470 retain all their rights. 4472 This document and the information contained herein are provided on an 4473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4475 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4476 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4480 Intellectual Property 4482 The IETF takes no position regarding the validity or scope of any 4483 Intellectual Property Rights or other rights that might be claimed to 4484 pertain to the implementation or use of the technology described in 4485 this document or the extent to which any license under such rights 4486 might or might not be available; nor does it represent that it has 4487 made any independent effort to identify any such rights. Information 4488 on the procedures with respect to rights in RFC documents can be 4489 found in BCP 78 and BCP 79. 4491 Copies of IPR disclosures made to the IETF Secretariat and any 4492 assurances of licenses to be made available, or the result of an 4493 attempt made to obtain a general license or permission for the use of 4494 such proprietary rights by implementers or users of this 4495 specification can be obtained from the IETF on-line IPR repository at 4496 http://www.ietf.org/ipr. 4498 The IETF invites any interested party to bring to its attention any 4499 copyrights, patents or patent applications, or other proprietary 4500 rights that may cover technology that may be required to implement 4501 this standard. Please address the information to the IETF at 4502 ietf-ipr@ietf.org.