Professional Documents
Culture Documents
UBT
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 10 Dec 2011 08:46:39 UTC
Contents
Articles
Communications protocol Internet Protocol Internet protocol suite Signalling System No. 7 Public switched telephone network Voice over IP Session Initiation Protocol User Datagram Protocol User agent Hypertext Transfer Protocol H.323 H.225.0 Skinny Call Control Protocol Real Time Streaming Protocol Real-time Transport Protocol RTP Control Protocol Telephone number mapping ITU-T European Telecommunications Standards Institute Internet Engineering Task Force Request for Comments Institute of Electrical and Electronics Engineers Session Description Protocol 1 16 20 27 31 34 47 52 58 61 67 79 80 81 83 88 90 96 104 106 109 113 121
References
Article Sources and Contributors Image Sources, Licenses and Contributors 124 128
Article Licenses
License 129
Communications protocol
Communications protocol
A communications protocol is a system of digital message formats and rules for exchanging those messages in or between computing systems and in telecommunications. A protocol may have a formal description. Protocols may include signaling, authentication and error detection and correction capabilities. A protocol definition defines the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to be implemented. A protocol can therefore be implemented as hardware or software or both.
Introduction
While there is no generally accepted formal definition of "protocol" in computer science, an informal definition, based on the previous, could be "a set of procedures to be followed when communicating". In computer science the word algorithm is a synonym for the word procedure so a protocol is to communications what an algorithm is to mathematics. Communicating systems use well-defined formats for exchanging messages. Each message has an exact meaning intended to provoke a defined response of the receiver. A protocol therefore describes the syntax, semantics, and synchronization of communication. A programming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communications what programming languages are to computations.[1] The communications protocols in use on the Internet are designed to function in very complex and diverse settings. To ease design, communications protocols are structured using a layering scheme as a basis. Instead of using a single universal protocol to handle all transmission tasks, a set of cooperating protocols fitting the layering scheme is used.[2] The layering scheme in use on the Internet is called the TCP/IP model. The actual protocols are collectively called the Internet protocol suite. The group responsible for this design is called the Internet Engineering Task Force (IETF). Obviously the number of layers of a layering scheme and the way the layers are defined can have a drastic impact on the protocols involved. This is where the analogies come into play for the TCP/IP model, because the designers of TCP/IP employed the same Figure 2. The TCP/IP model or Internet layering scheme and its relation to some common protocols. techniques used to conquer the complexity of programming language compilers (design by analogy) in the implementation of its protocols and its layering scheme.[3] Communications protocols have to be agreed upon by the parties involved. To reach agreement a protocol is developed into a technical standard.
Communications protocol
Communicating systems
The information exchanged between devices on a network or other communications medium is governed by rules or conventions that can be set out in a technical specification called a communication protocol standard. The nature of the communication, the actual data exchanged and any state-dependent behaviors are defined by the specification. In digital computing systems, the rules can be expressed by algorithms and data structures. Expressing the algorithms in a portable programming language, makes the protocol software operating system independent. Operating systems are usually conceived of as consisting of a set of cooperating processes that manipulate a shared store (on the system itself) to communicate with each other. This communication is governed by well-understood protocols. These protocols can be embedded in the process code itself as small additional code fragments.[4] [5] In contrast, communicating systems have to communicate with each other using shared transmission media, because there is no common memory. Transmission is not necessarily reliable and can involve different hardware and operating systems on different systems. To implement a networking protocol, the protocol software modules are interfaced with a framework implemented on the machine's operating system. This framework implements the networking functionality of the operating system.[6] The best known frameworks are the TCP/IP model and the OSI model. At the time the Internet was developed, layering had proven to be a successful design approach for both compiler and operating system design and, given the similarities between programming languages and communication protocols, layering was applied to the protocols as well.[7] This gave rise to the concept of layered protocols which nowadays forms the basis of protocol design.[8] Systems typically do not use a single protocol to handle a transmission. Instead they use a set of cooperating protocols, sometimes called a protocol family or protocol suite.[9] Some of the best known protocol suites include: IPX/SPX, X.25, AX.25, AppleTalk and TCP/IP. The protocols can be arranged based on functionality in groups, for instance there is a group of transport protocols. The functionalities are mapped onto the layers, each layer solving a distinct class of problems relating to, for instance: application-, transport-, internet- and network interface-functions.[10] To transmit a message, a protocol has to be selected from each layer, so some sort of multiplexing/demultiplexing takes place. The selection of the next protocol is accomplished by extending the message with a protocolselector for each layer.[11]
Communications protocol referred to as address mapping.[15] Routing. When systems are not directly connected, intermediary systems along the route to the intended receiver(s) need to forward messages on behalf of the sender. On the Internet, the networks are connected using routers. This way of connecting networks is called internetworking. Detection of transmission errors is necessary on networks which cannot guarantee error-free operation. In a common approach, CRCs of the data area are added to the end of packets, making it possible for the receiver to detect differences caused by errors. The receiver rejects the packets on CRC differences and arranges somehow for retransmission.[16] Acknowledgements of correct reception of packets is required for connection oriented communication. Acknowledgements are sent from receivers back to their respective senders.[17] Loss of information - timeouts and retries. Packets may be lost on the network or suffer from long delays. To cope with this, under some protocols, a sender may expect an acknowledgement of correct reception from the receiver within a certain amount of time. On timeouts, the sender must assume the packet was not received and retransmit it. In case of a permanently broken link, the retransmission has no effect so the number of retransmissions is limited. Exceeding the retry limit is considered an error.[18]
Direction of information flow needs to be addressed if transmissions can only occur in one direction at a time as on half-duplex links. This is known as Media Access Control. Arrangements have to be made to accommodate the case when two parties want to gain control at the same time.[19] Sequence control. We have seen that long bitstrings are divided in pieces, and then sent on the network individually. The pieces may get lost or delayed or take different routes to their destination on some types of networks. As a result pieces may arrive out of sequence. Retransmissions can result duplicate pieces. By marking the pieces with sequence information at the sender, the receiver can determine what was lost or duplicated, ask for necessary retransmissions and reassemble the original message.[20] Flow control is needed when the sender transmits faster than the receiver or intermediate network equipment can process the transmissions. Flow control can be implemented by messaging from receiver to sender.[21] Getting the data across a network is only part of the problem for a protocol. The data received has to be evaluated in the context of the progress of the conversation, so a protocol has to specify rules describing the context. These kind of rules are said to express the syntax of the communications. Other rules determine whether the data is meaningful for the context in which the exchange takes place. These kind of rules are said to express the semantics of the communications. Both intuitive descriptions as well as more formal specifications in the form of finite state machine models are used to describe the expected interactions of the protocol.[22] Formal ways for describing the syntax of the communications are Abstract Syntax Notation One (a ISO standard) or Augmented Backus-Naur form (a IETF standard).
Communications protocol In communications, message values are transferred using transmission media. By analogy, the equivalent of a store would be a collection of transmission media, instead of a collection of memory locations. A valid assignment in a protocol (as an analog of programming language) could be Ethernet:='message' , meaning a message is to be broadcast on the local ethernet. On a transmission medium there can be many receivers. For instance a mac-address identifies an ether network card on the transmission medium (the 'ether'). In our imaginary protocol, the assignment ethernet[mac-address]:=message value could therefore make sense.[26] By extending the assignment statement of an existing programming language with the semantics described, a protocolling language could easily be imagined. Operating systems provide reliable communication and synchronization facilities for communicating objects confined to the same system by means of system libraries. A programmer using a general purpose programming language (like C or ADA) can use the routines in the libraries to implement a protocol, instead of using a dedicated protocolling language.
Universal protocols
The nice thing about standards is that you have so many to choose from. Andrew S. Tanenbaum in Computer Networks
[27]
Despite their numbers, networking protocols show little variety, because all networking protocols use the same underlying principles and concepts, in the same way. So, the use of a general purpose programming language would yield a large number of applications only differing in the details.[28] A suitably defined (dedicated) protocolling language would therefore have little syntax, perhaps just enough to specify some parameters or optional modes of operation, because its virtual machine would have incorporated all possible principles and concepts making the virtual machine itself a universal protocol. The protocolling language would have some syntax and a lot of semantics describing this universal protocol and would therefore in effect be a protocol, hardly differing from this universal networking protocol. In this (networking) context a protocol is a language. The notion of a universal networking protocol provides a rationale for standardization of networking protocols; assuming the existence of a universal networking protocol, development of protocol standards using a consensus model (the agreement of a group of experts) might be a viable way to coordinate protocol design efforts. Networking protocols operate in very heterogeneous environments consisting of very different network technologies and a (possibly) very rich set of applications, so a single universal protocol would be very hard to design and implement correctly. Instead, the IETF decided to reduce complexity by assuming a relatively simple network architecture allowing decomposition of the single universal networking protocol into two generic protocols, TCP and IP, and two classes of specific protocols, one dealing with the low-level network details and one dealing with the high-level details of common network applications (remote login, file transfer, email and web browsing). ISO choose a similar but more general path, allowing other network architectures, to standardize protocols.
Protocol design
Communicating systems operate in parallel. The programming tools and techniques for dealing with parallel processes are collectively called concurrent programming. Concurrent programming only deals with the synchronization of communication. The syntax and semantics of the communication governed by a low-level protocol usually have modest complexity, so they can be coded with relative ease. High-level protocols with relatively large complexity could however merit the implementation of language interpreters. An example of the latter case is the HTML language. Concurrent programming has traditionally been a topic in operating systems theorie texts.[29] Formal verification
Communications protocol seems indispensable, because concurrent programs are notorious for the hidden and sophisticated bugs they contain.[30] A mathematical approach to the study of concurrency and communication is referred to as Communicating Sequential Processes (CSP).[31] Concurrency can also be modelled using finite state machines like Mealy- and Moore machines. Mealy- and Moore machines are in use as design tools in digital electronics systems, which we encounter in the form of hardware used in telecommunications or electronic devices in general.[32] This kind of design can be a bit of a challenge to say the least, so it is important to keep things simple. For the Internet protocols, in particular and in retrospect, this meant a basis for protocol design was needed to allow decomposition of protocols into much simpler, cooperating protocols.
Concurrent programming
A concurrent program is an abstraction of cooperating processes suitable for formal treatment and study. The goal of the abstraction is to prove correctness of the program assuming the existence of some basic synchronization or data exchange mechanisms provided by the operating system (or other software) or hardware. The mechanisms are complex, so more convenient higher level primitives are implemented with these mechanisms. The primitives are used to construct the concurrent program. The basic primitive for synchronization is the semaphore. All other primitives (locks, reentrant mutexes, semaphores, monitors, message passing, tuple space) can be defined using semaphores. The semaphore is sufficiently elementary to be successfully studied by formal methods.[33] In order to synchronize or exchange data the processes must communicate by means of either a shared memory, used to store data or access-restricted procedures, or the sending/receiving of signals (message passing) using a shared transmission medium. Most third generation operating systems implement separate processes that use special instructions to ensure only one process can execute the restricted procedures. On distributed systems there is no common central memory so the communications are always by means of message passing. In this case the processes simply have to wait for each other (synchronization by rendezvous) before exchanging data.[4] Conceptually, the concurrent program consists of several sequential processes whose execution sequences are interleaved. The execution sequences are divided into sections. A section manipulating shared resources is called a critical section. The interleaving scheme makes no timing assumptions other than that no process halts in its critical section and that ready processes are eventually scheduled for execution. For correct operation of the program, the critical sections of the processes need to be properly sequenced and synchronized. This is achieved using small code fragments (protocols) at the start and the end of the critical sections. The code fragments determine whether the critical sections of two communicating processes should execute in parallel (rendezvous of processes) or should be executed sequentially (mutual exclusion of processes). A concurrent program is correct if it does not violate some safety property such as mutual exclusion or rendezvous of critical sections and does not suffer of liveness properties such as deadlock or lockout. Correctness of the concurrent program can only be shown using a mathematical argument. Specifications of concurrent programs can be formulated using formal logics (like CSP) which make it possible to prove properties of the programs. Incorrectness can be shown using execution scenarios.[5] Mutual exclusion is extensively studied in the mutual exclusion problem. The rendezvous is studied in the producer-consumer problem in which a producer process only produces data if and only if the consumer process is ready to consume the data. Although both problems only involve two processes, their solutions require rather complex algorithms (Dekker's algorithm, Lamport's bakery algorithm). The readers-writers problem is a generalization of the mutual exclusion problem. The dining philosophers problem is a classical problem sufficiently difficult to expose many of the potential pitfalls of newly proposed primitives.[34]
Communications protocol
Layering
Many communications protocols can be viewed as layered protocols where each layer gives a service to the protocol of the layers above and requires service from layers below. Typically, a (best-effort) hardware delivery mechanism layer is used to build a connectionless packet delivery system on top of which a reliable transport layer is built, on top of which is the application software. Layers below and above these can be defined, and protocols are very often stacked to give tunnelling, for example the internet protocol can be tunnelled across an ATM network protocol to provide connectivity by layering the internet protocol on top of the ATM protocol transport layer. The delivery system is defined by the IP protocol and the transport system by the TCP protocol.[37] Protocol layering Protocol layering now forms the basis of protocol design.[8] It allows the decomposition of single, complex protocols into simpler, cooperating protocols, but it is also a functional decomposition, because each protocol belongs to a functional class, called a protocol layer.[2] The protocol layers each solve a distinct class of communications problems. The Internet protocol suite consists of the following layers: application-, transport-, internet- and network interface-functions.[10] Together, the layers make up a layering scheme or model. In computations, we have algorithms and data, and in communications, we have protocols and messages, so the analog of a data flow diagram Figure 3. Message flows using a protocol suite. would be some kind of message flow diagram.[23] To visualize protocol layering and protocol suites, a diagram of the message flows in and between two systems, A and B, is shown in figure 3. The systems both make use of the same protocol suite. The vertical flows (and protocols) are in system and the horizontal message flows (and protocols) are between systems. The message flows are governed by rules, and dataformats specified by protocols. The blue lines therefore mark the boundaries of the (horizontal) protocol layers. The vertical protocols are not layered because they don't obey the protocol layering principle which states that a layered protocol is designed so that layer n at the destination receives exactly the same object sent by layer n at the source. The horizontal protocols are layered protocols and all belong to the protocol suite. Layered protocols allow the protocol designer to concentrate on one layer at a time, without worrying about how other layers perform.[36] The vertical protocols neednot be the same protocols on both systems, but they have to satisfy some minimal
Communications protocol assumptions to ensure the protocol layering principle holds for the layered protocols. This can be achieved using a technique called Encapsulation.[38] Usually, a message or a stream of data is divided into small pieces, called messages or streams, packets, IP datagrams or network frames depending on the layer in which the pieces are to be transmitted. The pieces contain a header area and a data area. The data in the header area identifies the source and the destination on the network of the packet, the protocol, and other data meaningful to the protocol like CRC's of the data to be send, data length, and a timestamp.[39] [40] The rule enforced by the vertical protocols is that the pieces for transmission are to be encapsulated in the data area of all lower protocols on the sending side and the reverse is to happen on the receiving side. The result is that at the lowest level the piece looks like this: 'Header1,Header2,Header3,data' and in the layer directly above it: 'Header2,Header3,data' and in the top layer: 'Header3,data', both on the sending and receiving side. This rule therefore ensures that the protocol layering principle holds and effectively virtualizes all but the lowest transmission lines, so for this reason some message flows are coloured red in figure 3. To ensure both sides use the same protocol, the pieces also carry data identifying the protocol in their header. The design of the protocol layering and the network (or Internet) architecture are interrelated, so one cannot be designed without the other.[41] Some of the more important features in this respect of the Internet architecture and the network services it provides are described next. The Internet offers universal interconnection, which means that any pair of computers connected to the Internet is allowed to communicate. Each computer is identified by an address on the Internet. All the interconnected physical networks appear to the user as a single large network. This interconnection scheme is called an internetwork or internet.[42] Conceptually, an Internet addresses consists of a netid and a hostid. The netid identifies a network and the hostid identifies a host. The term host is misleading in that an individual computer can have multiple network interfaces each having its own Internet address. An Internet Address identifies a connection to the network, not an individual computer.[43] The netid is used by routers to decide where to send a packet.[44] Network technology independence is achieved using the low-level address resolution protocol (ARP) which is used to map Internet addresses to physical addresses. The mapping is called address resolution. This way physical addresses are only used by the protocols of the network interface layer.[45] The TCP/IP protocols can make use of almost any underlying communication technology.[46] Physical networks are interconnected by routers. Routers forward packets between interconnected networks making it possible for hosts to reach hosts on other physical networks. The message flows between two communicating system A and B in the presence of a router R are illustrated in figure 4. Datagrams are passed from router to router until a router is reached that can deliver the datagram on a physically attached network (called direct delivery).[47] To decide whether a datagram is to be delivered directly or is to be send to a router closer to the destination, a table called the IP routing table is consulted. The table consists of pairs of networkids and the paths to be taken to reach known Figure 4. Message flows in the presence of a router networks. The path can be an indication that the datagram should be delivered directly or it can be the address of a router known to be closer to the destination.[48] A special entry can specify that a default router is chosen when there are no known paths.[49]
Communications protocol All networks are treated equal. A LAN, a WAN or a point-to-point link between two computers are all considered as one network.[50] A Connectionless packet delivery (or packet-switched) system (or service) is offered by the Internet, because it adapts well to different hardware, including best-effort delivery mechanisms like the ethernet. Connectionless delivery means that the messages or streams are divided in pieces that are multiplexed separately on the high speed intermachine connections allowing the connections to be used concurrently. Each piece carries information identifying the destination. The delivery of packets is said to be unreliable, because packets may be lost, duplicated, delayed or delivered out of order without notice to the sender or receiver. Unreliability arises only when resources are exhausted or underlying networks fail.[51] The unreliable connectionless delivery system is defined by the Internet Protocol (IP). The protocol also specifies the routing function, which chooses a path over which data will be send.[52] It is also possible to use TCP/IP protocols on connection oriented systems. Connection oriented systems build up virtual circuits (paths for exclusive use) between senders and receivers. Once build up the IP datagrams are send as if they were data through the virtual circuits and forwarded (as data) to the IP protocol modules. This technique, called tunneling, can be used on X.25 networks and ATM networks.[53] A reliable stream transport service using the unreliable connectionless packet delivery service is defined by the transmission control protocol (TCP). The services are layered as well and the application programs residing in the layer above it, called the application services, can make use of TCP.[54] Programs wishing to interact with the packet delivery system itself can do so using the user datagram protocol (UDP).[55] Software layering Having established the protocol layering and the protocols, the protocol designer can now resume with the software design. The software has a layered organization and its relationship with protocol layering is visualized in figure 5. The software modules implementing the protocols are represented by cubes. The information flow between the modules is represented by arrows. The (top two horizontal) red arrows are virtual. The blue lines mark the layer boundaries. To send a message on system A, the top module interacts with the module directly below it and hands over the message to be encapsulated. This module reacts by encapsulating the message in its own data area and filling in its header data in accordance with the protocol it implements and interacts with the module below it by handing over this newly formed Figure 5: Protocol and software layering message whenever appropriate. The bottom module directly interacts with the bottom module of system B, so the message is send across. On the receiving system B the reverse happens, so ultimately (and assuming there were no transmission errors or protocol violations etc.) the message gets delivered in its original form to the topmodule of system B.[56] On protocol errors, a receiving module discards the piece it has received and reports back the error condition to the original source of the piece on the same layer by handing the error message down or in case of the bottom module sending it across.[57] The division of the message or stream of data into pieces and the subsequent reassembly are handled in the layer that introduced the division/reassembly. The reassembly is done at the destination (i.e. not on any intermediate routers).[58] TCP/IP software is organized in four layers.[59]
Communications protocol Application layer. At the highest layer, the services available across a TCP/IP internet are accessed by application programs. The application chooses the style of transport to be used which can be a sequence of individual messages or a continuous stream of bytes. The application program passes data to the transport layer for delivery. Transport layer. The transport layer provides communication from one application to another. The transport layer may regulate flow of information and provide reliable transport, ensuring that data arrives without error and in sequence. To do so, the receiving side sends back acknowledgments and the sending side retransmits lost pieces called packets. The stream of data is divided into packets by the module and each packet is passed along with a destination address to the next layer for transmission. The layer must accept data from many applications concurrently and therefore also includes codes in the packet header to identify the sending and receiving application program. Internet layer. The Internet layer handles the communication between machines. Packets to be send are accepted from the transport layer along with an identification of the receiving machine. The packets are encapsulated in IP datagrams and the datagram headers are filled. A routing algorithm is used to determine if the datagram should be delivered directly or send to a router. The datagram is passed to the appropriate network interface for transmission. Incoming datagrams are checked for validity and the routing algorithm is used to decide whether the datagram should be processed locally or forwarded. If the datagram is addressed to the local machine, the datagram header is deleted and the appropriate transport protocol for the packet is chosen. ICMP error and control messages are handled as well in this layer. Network interface layer. The network interface layer is responsible for accepting IP datagrams and transmitting them over a specific network. A network interface may consist of a device driver or a complex subsystem that uses its own data link protocol. Program translation has been divided into four subproblems: compiler, assembler, link editor, and loader. As a result, the translation software is layered as well, allowing the software layers to be designed independently. Noting that the ways to conquer the complexity of program translation could readily be applied to protocols because of the analogy between programming languages and protocols. The designers of the TCP/IP protocol suite were keen on imposing the same layering on the software framework. This can be seen in the TCP/IP layering by considering the translation of a pascal program (message) that is compiled (function of the application layer) into an assembler program that is assembled (function of the transport layer) to object code (pieces) that is linked (function of the Internet layer) together with library object code (routing table) by the link editor, producing relocatable machine code (datagram) that is passed to the loader which fills in the memory locations (ethernet addresses) to produce executeable code (network frame) to be loaded (function of the network interface layer) into physical memory (transmission medium). To show just how closely the analogy fits, the terms between parentheses in the previous sentence denote the relevant analogs and the terms written cursively denote data representations. Program translation forms a linear sequence, because each layer's output is passed as input to the next layer. Furthermore, the translation process involves multiple data representations. We see the same thing happening in protocol software where multiple protocols define the datarepresentations of the data passed between the software modules.[3] The network interface layer uses physical addresses and all the other layers only use IP addresses. The boundary between network interface layer and Internet layer is called the high-level protocol address boundary.[60] The modules below the application layer are generally considered part of the operating system. Passing data between these modules is much less expensive than passing data between an application program and the transport layer. The boundary between application layer and transport layer is called the operating system boundary.[61]
Communications protocol Strict layering Strictly adhering to a layered model, a practice known as strict layering, is not always the best approach to networking.[62] Strict layering, can have a serious impact on the performance of the implementation, so there is at least a trade-off between simplicity and performance.[63] Another, perhaps more important point can be shown by considering the fact that some of the protocols in the Internet Protocol Suite cannot be expressed using the TCP/IP model, in other words some of the protocols behave in ways not described by the model.[64] To improve on the model, an offending protocol could, perhaps be split up into two protocols, at the cost of one or two extra layers, but there is a hidden caveat, because the model is also used to provide a conceptual view on the suite for the intended users. There is a trade-off to be made here between preciseness for the designer and clarity for the intended user.[65]
10
Protocol development
For communication to take place, protocols have to be agreed upon. Recall that in digital computing systems, the rules can be expressed by algorithms and datastructures, raising the opportunity of hardware independency. Expressing the algorithms in a portable programming language, makes the protocolsoftware operating system independent. The sourcecode could be considered a protocol specification. This form of specification, however is not suitable for the parties involved. For one thing, this would enforce a source on all parties and for another, proprietary software producers would not accept this. By describing the software interfaces of the modules on paper and agreeing on the interfaces, implementers are free to do it their way. This is referred to as source independency. By specifying the algorithms on paper and detailing hardware dependencies in an unambiguous way, a paper draft is created, that when adhered to and published, ensures interoperability between software and hardware. Such a paper draft can be developed into a protocol standard by getting the approval of a standards organization. To get the approval the paper draft needs to enter and successfully complete the standardization process. This activity is referred to as protocol development. The members of the standards organization agree to adhere to the standard on a voluntary basis. Often the members are in control of large market-shares relevant to the protocol and in many cases, standards are enforced by law or the government, because they are thought to serve an important public interest, so getting approval can be very important for the protocol. It should be noted though that in some cases protocol standards are not sufficient to gain widespread acceptance i.e. sometimes the sourcecode needs to be disclosed enforced by law or the government in the interest of the public.
Communications protocol
11
Standards organizations
Some of the standards organizations of relevance for communications protocols are the International Organization for Standardization (ISO), the International Telecommunications Union (ITU), the Institute of Electrical and Electronics Engineers (IEEE), and the Internet Engineering Task Force (IETF). The IETF maintains the protocols in use on the Internet. The IEEE controls many software and hardware protocols in the electronics industry for commercial and consumer devices. The ITU is an umbrella organization of telecommunications engineers designing the public switched telephone network (PSTN), as well as many radio communication systems. For marine electronics the NMEA standards are used. The World Wide Web Consortium (W3C) produces protocols and standards for Web technologies. International standards organizations are supposed to be more impartial than local organizations with a national or commercial self-interest to consider. Standards organizations also do research and development for standards of the future. In practice, the standards organizations mentioned, cooperate closely with each other.[66]
Communications protocol the nth layer is referred to as (n)-layer. Each layer provides service to the layer above it (or at the top to the application process) using the services of the layer immediately below it. The layers communicate with each other by means of an interface, called a service access point. Corresponding layers at each system are called peer entities. To communicate, two peer entities at a given layer use a (n)-protocol, which is implemented by using services of the (n-1)-layer. When systems are not directly connected, intermediate peer entities (called relays) are used. An address uniquely identifies a service access point. The address naming domains need not be restricted to one layer, so it is possible to use just one naming domain for all layers.[70] For each layer there are two types of standards: protocol standards defining how peer entities at a given layer communicate, and service standards defining how a given layer communicates with the layer above it. In the original version of RM/OSI, the layers and their functionality are (from highest to lowest layer): The application layer may provide the following services to the application processes: identification of the intended communication partners, establishment of the necessary authority to communicate, determination of availability and authentication of the partners, agreement on privacy mechanisms for the communication, agreement on responsibility for error recovery and procedures for ensuring data integrity, synchronization between cooperating application processes, identification of any constraints on syntax (e.g. character sets and data structures), determination of cost and acceptable quality of service, selection of the dialogue discipline, including required logon and logoff procedures.[71] The presentation layer may provide the following services to the application layer: a request for the establishment of a session, data transfer, negotiation of the syntax to be used between the application layers, any necessary syntax transformations, formatting and special purpose transformations (e.g. data compression and data encryption).[72] The session layer may provide the following services to the presentation layer: establishment and release of session connections, normal and expedited data exchange, a quarantine service which allows the sending presentation entity to instruct the receiving session entity not to release data to its presentation entity without permission, interaction management so presentation entities can control whose turn it is to perform certain control functions, resynchronization of a session connection, reporting of unrecoverable exceptions to the presentation entity.[73] The transport layer provides reliable and transparent data transfer in a cost effective way as required by the selected quality of service. It may support the multiplexing of several transport connections on to one network connection or split one transport connection into several network connections.[74] The network layer does the setup, maintenance and release of network paths between transport peer entities. When relays are needed, routing and relay functions are provided by this layer. The quality of service is negotiated between network and transport entities at the time the connection is set up. This layer is also responsible for (network) congestion control.[75] The data link layer does the setup, maintenance and release of data link connections. Errors occurring in the physical layer are detected and may be corrected. Errors are reported to the network layer. The exchange of data link units (including flow control) is defined by this layer.[76] The physical layer describes details like the electrical characteristics of the physical connection, the transmission techniques used, and the setup, maintenance and clearing of physical connections.[77] In contrast to the TCP/IP layering scheme, which assumes a connectionless network, RM/OSI assumed a connection-oriented network. Connection-oriented networks are more suitable for wide area networks and connectionless networks are more suitable for local area networks. Using connections to communicate implies some form of session and (virtual) circuits, hence the (in the TCP/IP model lacking) session layer. The constituent members of ISO were mostly concerned with wide area networks, so development of RM/OSI concentrated on connection oriented networks and connectionless networks were only mentioned in an addendum to RM/OSI.[78] At the time, the IETF had to cope with this and the fact that the Internet needed protocols which simple were not there. As a result the IETF developed its own standardization process based on "rough consensus and running code".[79]
12
Communications protocol The standardization process is described by RFC2026 [80]. Nowadays, the IETF has become a standards organization for the protocols in use on the Internet. RM/OSI has extended its model to include connectionless services and because of this, both TCP and IP could be developed into international standards.
13
Taxonomies
Classification schemes for protocols usually focus on domain of use and function. As an example of domain of use, connection-oriented protocols and connectionless protocols are used on connection-oriented networks and connectionless networks respectively. For an example of function consider a tunneling protocol, which is used to encapsulate packets in a high-level protocol, so the packets can be passed across a transport system using the high-level protocol. A layering scheme combines both function and domain of use. The dominant layering schemes are the ones proposed by the IETF and by ISO. Despite the fact that the underlying assumptions of the layering schemes are different enough to warrant distinguishing the two, it is a common practice to compare the two by relating common protocols to the layers of the two schemes.[81] For an example of this practice see: List of network protocols. The layering scheme from the IETF is called Internet layering or TCP/IP layering. The functionality of the layers has been described in the section on software layering and an overview of protocols using this scheme is given in the article on Internet protocols. The layering scheme from ISO is called the OSI model or ISO layering. The functionality of the layers has been described in the section on the future of standardization and an overview of protocols using this scheme is given in the article on OSI protocols.
Other instances of high level interaction protocols are: IIOP RMI DCOM DDE SOAP
Communications protocol
14
Notes
[1] Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, "They (protocols) are to communication what programming languages are to computation" [2] Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, introduces the decomposition in layers. [3] Comer 2000, Sect. 11.2 - The need for multiple protocols, p. 178, explains similarities protocol software and compiler, assembler, linker, loader. [4] Ben-Ari 1982, chapter 2 - The concurrent programming abstraction, p. 18-19, states the same. [5] Ben-Ari 1982, Section 2.7 - Summary, p. 27, summarizes the concurrent programming abstraction. [6] Marsden 1986, Section 6.1 - Why are standards necessary?, p. 64-65, uses BSC as an example to show the need for both standard protocols and a standard framework. [7] Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, explains this by drawing analogies between computer communication and programming languages. [8] Sect. 11.10 - The Disadvantage Of Layering, p. 192, states: layering forms the basis for protocol design. [9] Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, states the same. [10] Comer 2000, Sect. 11.3 - The Conceptual Layers Of Protocol Software, p. 178, "Each layer takes responsibility for handling one part of the problem." [11] Comer 2000, Sect. 11.11 - The Basic Idea Behind Multiplexing And Demultiplexing, p. 192, states the same. [12] Marsden 1986, Chapter 3 - Fundamental protocol concepts and problem areas, p. 26-42, explains much of the following. [13] Comer 2000, Sect. 7.7.4 - Datagram Size, Network MTU, and Fragmentation, p. 104, Explains fragmentation and the effect on the header of the fragments. [14] Comer 2000, Chapter 4 - Classful Internet Addresses, p. 64-67;71. [15] Marsden 1986, Section 14.3 - Layering concepts and general definitions, p. 187, explains address mapping. [16] Marsden 1986, Section 3.2 - Detection and transmission errors, p. 27, explains the advantages of backward error correction. [17] Marsden 1986, Section 3.3 - Acknowledgement, p. 28-33, explains the advantages of positive only acknowledgement and mentions datagram protocols as exceptions. [18] Marsden 1986, Section 3.4 - Loss of information - timeouts and retries, p. 33-34. [19] Marsden 1986, Section 3.5 - Direction of information flow, p. 34-35, explains master/slave and the negotiations to gain control. [20] Marsden 1986, Section 3.6 - Sequence control, p. 35-36, explains how packets get lost and how sequencing solves this. [21] Marsden 1986, Section 3.7 - Flow control, p. 36-38. [22] Comer 2000, Glossary of Internetworking Terms and Abbreviations, p. 704, term protocol. [23] Comer 2000, Sect. 1.3 - Internet Services, p. 3, "Protocols are to communication what algorithms are to computation" [24] Tennent 1981, Section 2.3.1 - Definitions, p.15, defines scope and binding. [25] Tennent 1981, Section 2.3.2 Environments and stores, p.16, the semantics of blocks and definitions are described using environments and stores. [26] Hoare (1985), Ch. 4 - Communication, p. 133, In the introduction: a communication is an event described by a pair c.v where c is the name of the communication channel and v is the value of the message. [27] Tanenbaum, Andrew S. (2003). Computer networks (http:/ / books. google. com/ books?id=Pd-z64SJRBAC& pg=PA235). Prentice Hall Professional. p.235. ISBN9780130661029. . Retrieved 22 June 2011. [28] Comer 2000,Foreword To The First Edition By The Late Jon Postel, xxv, "The principles of architecture, layering, multiplexing, encapsulation, addressing and address mapping, routing, and naming are quite similar in any protocol suite, though of course, different in detail.". [29] Ben-Ari 1982, in his preface, p. xiii. [30] Ben-Ari 1982, in his preface, p. xiv. [31] Hoare 1985, Chapter 4 - Communication, p. 133, deals with communication. [32] S. Srinivasan, NPTEL courses:::: Electronics & Communication Engineering :: Digital Circuits and Systems, available online: http:/ / nptel. iitm. ac. in/ video. php?courseId=1005& p=3 [33] Ben-Ari 1982, Section 1.7 - An overview of the book, p. 12, states the same. [34] Ben-Ari 1982, Section 4.3 - The producer-consumer problem, p. 56, explains the rendezvous variant in the absence of common memory. [35] Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, states more or less the same, using other analogies. [36] Comer 2000, Sect. 11.7 - The Protocol Layering Principle, p. 187, explains layered protocols. [37] Comer 2000, Section 7.3 - Internet Architecture And Philosophy, p. 96, describes service layering. [38] Comer 2000, Glossary of Internetworking terms, p.686: term encapsulation. [39] Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 184, Describes the transformations of messages or streams that can be observed in the protocol layers. [40] Comer 2000, Sect. 2.4.10 - Ethernet Frame Format, p. 30, Ethernet frames are used as an example for administrative data for the protocol itself. [41] Comer 2000, Sect. 11.4 - Functionality Of The Layers, p. 181, states the same about the software organization. [42] Comer 2000, Sect. 3.3 - Network-Level Interconnection, p. 55, explains universal interconnection and internetworking.
Communications protocol
[43] Comer 2000, Sect. 4.4 - Addresses Specify Network Connections, p. 86, explains this. [44] Comer 2000, Sect. 4.3 - The Original Classful Addressing Scheme, p. 64, explains the address scheme, netid and routing. [45] Comer 2000, Sect. 5.13 - Summary, p. 86, explains ARP. [46] Comer 2000, Sect. 2.11 - Other Technologies Over Which TCP/IP Has Been Used, p. 46, states the same. [47] Comer 2000, Sect. 8.3.2 - Indirect Delivery, p. 118, states the same. [48] Comer 2000, Sect. 8.5 - Next-Hop Routing, p. 120, gives details on the routing table. [49] Comer 2000, Sect. 8.6 - Default Routes, p. 121, explains default routing and its use. [50] Comer 2000, Sect. 3.8 - All Networks Are Equal, p. 59, states the same. [51] Comer 2000, Sect. 7.5 - Connectionless Delivery System, p. 97, explains the delivery system. [52] Comer 2000, Sect. 7.6 - Purposes Of The Internet Protocol, p. 97, states the same. [53] Comer 2000, Sect. 2.11.1 - X25NET And Tunnels, p. 46-47, explains tunneling X.25 and mentions ATM. [54] Comer 2000, Sect. 13.1 - Introduction, p. 209, introduces TCP. [55] Comer 2000, Sect. 12.10 - Summary, p. 206, explains UDP. [56] Comer 2000, Sect. 11.3 - The Conceptual Layers Of Protocol Software, p. 179, the first two paragraphs describe the sending of a message through successive layers. [57] Comer 2000, Sect. 9.3 - Error Reporting vs. Error Correction, p. 131, describes the ICMP protocol that is used to handle datagram errors. [58] Comer 2000, Sect. 7.7.5 - Reassembly Of Fragments, p. 104, describes reassembly of datagrams. [59] Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 184, explains functionality of the layers. [60] Comer 2000, Sect. 11.9.1 - High-Level Protocol Boundary, p. 191, describes the boundary. [61] Comer 2000, Sect. 11.9.1 - Operating System Boundary, p. 192, describes the operating system boundary. [62] IETF 1989, Sect 1.3.1 - Organization, p. 15, 2nd paragraph: many design choices involve creative "breaking" of strict layering. [63] Comer 2000, Sect. 11.10 - The Disadvantage Of Layering, p. 192, explains why "strict layering can be extremely inefficient" giving examples of optimizations. [64] IETF 1989, Sect 1.3.1 - Organization, p. 15, 2nd paragraph, explaining why "strict layering is an imperfect model" [65] IETF 1989, Sect 1.3.1 - Organization, p. 15, states: This layerist organization was chosen for simplicity and clarity. [66] Marsden 1986, Section 6.3 - Advantages of standardisation, p. 66-67, states the same. [67] Marsden 1986, Section 6.4 - Some problems with standardisation, p. 67, follows HDLC to illustrate the process. [68] Marsden 1986, Section 6.1 - Why are standards necessary?, p. 65, explains lessons learned from ARPANET. [69] Marsden 1986, Section 14.1 - Introduction, p. 181, introduces OSI. [70] Marsden 1986, Section 14.3 - Layering concepts and general definitions, p. 183-185, explains terminology. [71] Marsden 1986, Section 14.4 - The application layer, p. 188, explains this. [72] Marsden 1986, Section 14.5 - The presentation layer, p. 189, explains this. [73] Marsden 1986, Section 14.6 - The session layer, p. 190, explains this. [74] Marsden 1986, Section 14.7 - The transport layer, p. 191, explains this. [75] Marsden 1986, Section 14.8 - The network layer, p. 192, explains this. [76] Marsden 1986, Section 14.9 - The data link layer, p. 194, explains this. [77] Marsden 1986, Section 14.10 - The physical layer, p. 195, explains this. [78] Marsden 1986, Section 14.11 - Connectionless mode and RM/OSI, p. 195, mentions this. [79] Comer 2000, Section 1.9 - Internet Protocols And Standardization, p. 12, explains why the IETF did not use existing protocols. [80] http:/ / tools. ietf. org/ html/ rfc2026 [81] Comer 2000, Sect. 11.5.1 - The TCP/IP 5-Layer Reference Model, p. 183, states the same.
15
References
Radia Perlman: Interconnections: Bridges, Routers, Switches, and Internetworking Protocols. 2nd Edition. Addison-Wesley 1999, ISBN 0-201-63448-1. In particular Ch. 18 on "network design folklore", which is also available online at http://www.informit.com/articles/article.aspx?p=20482 Gerard J. Holzmann: Design and Validation of Computer Protocols. Prentice Hall, 1991, ISBN 0-13-539925-4. Also available online at http://spinroot.com/spin/Doc/Book91.html Douglas E. Comer (2000). Internetworking with TCP/IP - Principles, Protocols and Architecture (4th ed.). Prentice Hall. ISBN0-13-018380-6. In particular Ch.11 Protocol layering. Also has a RFC guide and a Glossary of Internetworking Terms and Abbreviations. Internet Engineering Task Force abbr. IETF (1989): RFC1122, Requirements for Internet Hosts -Communication Layers, R.Braden (ed.), Available online at http://tools.ietf.org/html/rfc1122.Describes TCP/IP to the implementors of protocolsoftware. In particular the introduction gives an overview of the design goals of the suite.
Communications protocol M. Ben-Ari (1982): Principles of concurrent programming 10th Print. Prentice Hall International, ISBN 0-13-701078-8. C.A.R. Hoare (1985): Communicating sequential processes 10th Print. Prentice Hall International, ISBN 0-13-153271-5. Available online via http://www.usingcsp.com R.D. Tennent (1981): Principles of programming languages 10th Print. Prentice Hall International, ISBN 0-13-709873-1. Brian W Marsden (1986): Communication network protocols 2nd Edition. Chartwell Bratt, ISBN 0-86238-106-1. Andrew S. Tanenbaum (1984): Structured computer organization 10th Print. Prentice Hall International, ISBN 0-13-854605-3.
16
External links
Javvin's Protocol Dictionary (http://www.javvin.com/protocolsuite.html) Network Protocol Index (http://www.networkdictionary.com/protocols/) Overview of protocols in telecontrol field with OSI Reference Model (http://www.ipcomm.de/protocols_en. html) List of Data Communication Protocols (http://www.zframez.com/protocolsuite.html) PDF-Chart showing the Protocols and the OSI reference layer (http://www.wildpackets.com/elements/misc/ WP_encapsulation_chart.pdf)
Internet Protocol
The Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (packets) across an internetwork using the Internet Protocol Suite. Responsible for routing packets across network boundaries, it is the primary protocol that establishes the Internet. IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation. Historically, IP was the connectionless datagram service in the original Transmission Control Program introduced by Vint Cerf and Bob Kahn in 1974, the other being the connection-oriented Transmission Control Protocol (TCP). The Internet Protocol Suite is therefore often referred to as TCP/IP.
The first major version of IP, now referred to as Internet Protocol Version 4 (IPv4) is the dominant protocol of the Internet, although the successor, Internet Protocol Version 6 (IPv6) is in active, growing deployment worldwide.
Internet Protocol Suite in operation between two hosts connected via two routers and the corresponding layers used at each hop
Internet Protocol
17
Function
The Internet Protocol is responsible for addressing hosts and routing datagrams (packets) from a source host to the destination host across one or more IP networks. For this purpose the Internet Protocol defines an addressing system that has two functions. Addresses identify hosts and provide a logical location service. Each packet is tagged with a header that contains the meta-data for the purpose of delivery. This process of tagging is also called encapsulation.
Reliability
The design principles of the Internet protocols assume that the network infrastructure is inherently unreliable at any single network element or transmission medium and that it is dynamic in terms of availability of links and nodes. No central monitoring or performance measurement facility exists that tracks or maintains the state of the network. For the benefit of reducing network complexity, the intelligence in the network is purposely mostly located in the end nodes of each data transmission, cf. end-to-end principle. Routers in the transmission path simply forward packets to the next known local gateway matching the routing prefix for the destination address. As a consequence of this design, the Internet Protocol only provides best effort delivery and its service is characterized as unreliable. In network architectural language it is a connection-less protocol, in contrast to so-called connection-oriented modes of transmission. The lack of reliability permits various error conditions, such data corruption, packet loss and duplication, as well as out-of-order packet delivery. Since routing is dynamic for every packet and the network maintains no state of the path of prior packets, it is possible that some packets are routed on a longer path to their destination, resulting in improper sequencing at the receiver. The only assistance that the Internet Protocol provides in Version 4 (IPv4) is to ensure that the IP packet header is error-free through computation of a checksum at the routing nodes. This has the side-effect of discarding packets with bad headers on the spot. In this case no notification is required to be sent to either end node, although a facility exists in the Internet Control Message Protocol (ICMP) to do so. IPv6, on the other hand, has abandoned the use of IP header checksums for the benefit of rapid forwarding through routing elements in the network. The resolution or correction of any of these reliability issues is the responsibility of an upper layer protocol. For example, to ensure in-order delivery the upper layer may have to cache data until it can be passed to the application. In addition to issues of reliability, this dynamic nature and the diversity of the Internet and its components provide no guarantee that any particular path is actually capable of, or suitable for, performing the data transmission requested, even if the path is available and reliable. One of the technical constraints is the size of data packets allowed on a given link. An application must assure that it uses proper transmission characteristics. Some of this responsibility lies also in the upper layer protocols between application and IP. Facilities exist to examine the maximum transmission unit (MTU) size of the local link, as well as for the entire projected path to the destination when using IPv6. The IPv4 internetworking layer has the capability to automatically fragment the original datagram into smaller units for transmission. In this case, IP does provide re-ordering of fragments delivered out-of-order.[1] Transmission Control Protocol (TCP) is an example of a protocol that will adjust its segment size to be smaller than the MTU. User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP) disregard MTU size thereby forcing IP to fragment oversized datagrams.[2]
Internet Protocol
18
Version history
In May 1974, the Institute of Electrical and Electronic Engineers (IEEE) published a paper entitled "A Protocol for Packet Network Interconnection."[4] The paper's authors, Vint Cerf and Bob Kahn, described an internetworking protocol for sharing resources using packet-switching among the nodes. A central control component of this model was the "Transmission Control Program" (TCP) that incorporated both connection-oriented links and datagram services between hosts. The monolithic Transmission Control Program was later divided into a modular architecture consisting of the Transmission Control Protocol at the connection-oriented layer and the Internet Protocol at the internetworking (datagram) layer. The model became known informally as TCP/IP, although formally referenced as the Internet Protocol Suite. The Internet Protocol is one of the determining elements that define the Internet. The dominant internetworking protocol in the Internet Layer in use today is IPv4; with number 4 assigned as the formal protocol version number carried in every IP datagram. IPv4 is described in RFC 791 (1981). The successor to IPv4 is IPv6. Its most prominent modification from version 4 is the addressing system. IPv4 uses 32-bit addresses (c. 4 billion, or 4.3109, addresses) while IPv6 uses 128-bit addresses (c. 340 undecillion, or 3.41038 addresses). Although adoption of IPv6 has been slow, as of June 2008, all United States government systems have demonstrated basic infrastructure support for IPv6 (if only at the backbone level).[5] Version numbers 0 through 3 were development versions of IPv4 used between 1977 and 1979. Version number 5 was used by the Internet Stream Protocol, an experimental streaming protocol. Version numbers 6 through 9 were proposed for various protocol models designed to replace IPv4: SIPP (Simple Internet Protocol Plus, known now as IPv6), TP/IX (RFC 1475), PIP (RFC 1621) and TUBA (TCP and UDP with Bigger Addresses, RFC 1347). Version number 6 was eventually chosen as the official assignment for the successor Internet protocol, subsequently standardized as IPv6. A humorous Request for Comments that made an IPv9 protocol center of its storyline was published on April 1, 1994 by the IETF.[6] It was intended as an April Fool's Day joke. Other protocol proposals named "IPv9" and "IPv8" have also briefly surfaced, though these came with little or no support from the wider industry and academia.[7]
Internet Protocol
19
Reference diagrams
Vulnerabilities
The Internet Protocol is vulnerable to a variety of attacks. A thorough vulnerability assessment, along with proposed mitigations, was published in 2008,[8] and is currently being pursued within the IETF.[9]
References
[1] [2] [3] [4] [5] [6] [7] [8] [9] Siyan, Karanjit. Inside TCP/IP, New Riders Publishing, 1997. ISBN 1-56205-714-6 Basic Journey of a Packet (http:/ / www. securityfocus. com/ infocus/ 1870) Netgear ProSafe XSM7224S reference manual Vinton G. Cerf, Robert E. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. 22, No. 5, May 1974 pp. 637-648 CIO council adds to IPv6 transition primer (http:/ / www. gcn. com/ print/ 25_16/ 41051-1. html), gcn.com RFC 1606: A Historical Perspective On The Usage Of IP Version 9. April 1, 1994. Theregister.com (http:/ / www. theregister. co. uk/ 2004/ 07/ 06/ ipv9_hype_dismissed/ ) Security Assessment of the Internet Protocol (IP) (http:/ / www. cpni. gov. uk/ Docs/ InternetProtocol. pdf) Security Assessment of the Internet Protocol version 4 (IPv4) (http:/ / tools. ietf. org/ html/ draft-ietf-opsec-ip-security)
External links
Internet Protocol (http://www.dmoz.org/Computers/Internet/Protocols/) at the Open Directory Project RFC 791 Data Communication Lectures of Manfred Lindner - Part IP Technology Basics (http://www.ict.tuwien.ac.at/ lva/384.081/infobase/L30-IP_Technology_Basics_v4-6.pdf) Data Communication Lectures of Manfred Lindner - Part IP Technology Details (http://www.ict.tuwien.ac.at/ lva/384.081/infobase/L31-IP_Technology_Details_v4-7.pdf) Data Communication Lectures of Manfred Lindner - Part IPv6 (http://www.ict.tuwien.ac.at/lva/384.081/ infobase/L80-IPv6_v4-6.pdf) IPv6.com - Knowledge Center for Next Generation Internet IPv6 (http://www.ipv6.com)
20
History
The Internet protocol suite resulted from research and development conducted by the Defense Advanced Research Projects Agency (DARPA) in the early 1970s. After initiating the pioneering ARPANET in 1969, DARPA started work on a number of other data transmission technologies. In 1972, Robert E. Kahn joined the DARPA Information Processing Technology Office, where he worked on both satellite packet networks and ground-based radio packet networks, and recognized the value of being able to communicate across both. In the spring of 1973, Vinton Cerf, the developer of the existing ARPANET Network Control Program (NCP) protocol, joined Kahn to work on open-architecture interconnection models with the goal of designing the next protocol generation for the ARPANET. By the summer of 1973, Kahn and Cerf had worked out a fundamental reformulation, where the differences between network protocols were hidden by using a common internetwork protocol, and, instead of the network being responsible for reliability, as in the ARPANET, the hosts became responsible. Cerf credits Hubert Zimmerman and Louis Pouzin, designer of the CYCLADES network, with important influences on this design.
The network's design included the recognition it should provide only the functions of efficiently transmitting and routing traffic between end nodes and that all other intelligence should be located at the edge of the network, in the end nodes. Using a simple
A Stanford Research Institute packet radio van, site of the first three-way internetworked transmission.
Internet protocol suite design, it became possible to connect almost any network to the ARPANET, irrespective of their local characteristics, thereby solving Kahn's initial problem. One popular expression is that TCP/IP, the eventual product of Cerf and Kahn's work, will run over "two tin cans and a string." A computer, called a router, is provided with an interface to each network. It forwards packets back and forth between them.[3] Originally a router was called gateway, but the term was changed to avoid confusion with other types of gateways. The idea was worked out in more detailed form by Cerf's networking research group at Stanford in the 197374 period, resulting in the first TCP specification.[4] The early networking work at Xerox PARC, which produced the PARC Universal Packet protocol suite, much of which existed around the same period of time, was also a significant technical influence. DARPA then contracted with BBN Technologies, Stanford University, and the University College London to develop operational versions of the protocol on different hardware platforms. Four versions were developed: TCP v1, TCP v2, a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 the standard protocol still in use on the Internet today. In 1975, a two-network TCP/IP communications test was performed between Stanford and University College London (UCL). In November, 1977, a three-network TCP/IP test was conducted between sites in the US, UK, and Norway. Several other TCP/IP prototypes were developed at multiple research centers between 1978 and 1983. The migration of the ARPANET to TCP/IP was officially completed on flag day January 1, 1983, when the new protocols were permanently activated.[5] In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer networking.[6] In 1985, the Internet Architecture Board held a three day workshop on TCP/IP for the computer industry, attended by 250 vendor representatives, promoting the protocol and leading to its increasing commercial use. In 1985 the first Interop conference was held, focused on network interoperability via further adoption of TCP/IP. It was founded by Dan Lynch, one of early Internet activists. It was attended from the beginning by large corporations such as IBM and DEC. Interoperability conferences have been held since then every year, and every year from 1985 through 1993 the number of attendees tripled. [citation needed] IBM, ATT and DEC were the first major corporations to adopt TCP/IP despite having competing internal protocols (SNA, XNS, etc) and politics. In IBM the TCP/IP development was undertaken from 1984 onward in the group of Barry Appelman who later moved to AOL to be the head of all AOL's development efforts. At IBM Barry Appelman with a handful of developers was able to maneuver the corporate politics to get a stream of TCP/IP products for various IBM systems - MVS, VM, OS/2 among others. At the same time several smaller companies began offering TCP/IP stacks for DOS and MS Windows, such as FTP Software, Wollongong [7]. The first VM/CMS TCP/IP stack came from university of Wisconsin[8] . Back then most of these TCP/IP stacks were written single-handedly by very few talented programmers. For example, John Romkey of FTP Software was the author of the MIT PC/IP package as well as at a later point of FTP Software[9] . John Romkey's PC/IP implementation was the first IBM PC TCP/IP stack. Jay Elinsky and Oleg Vishnepolsky of IBM Research wrote VM/CMS and OS/2 TCP/IP stacks, respectively[10] . The spread of TCP/IP was fueled further in June 1989 when AT&T agreed to put the TCP/IP code developed for UNIX system at University of Berkeley into public domain. Known as BSD, this code base was adopted by a variety of vendors, IBM included, for their own TCP/IP stacks. Until Microsoft released TCP/IP stack in 1995 with its Windows 95, many companies marketed and sold TCP/IP software for Windows. Windows 95 support for TCP/IP came a little late in the Internet evolution, but when it finally came, the dominance of TCP/IP over other protocols became insurmountable. IBM's SNA, OSI, Microsoft's native NetBIOS, Xerox' XNS and all other protocols disappeared from the commercial landscape. [citations needed]
21
22
Internet protocol suite The lowest layer in the Internet protocol suite is the link layer. It comprises the tasks of specific networking requirements on the local link, the network segment that a hosts network interface is connected to. This involves interacting with the hardware-specific functions of network interfaces and specific transmission technologies. As the user data, first manipulated and structured in the application layer, is passed through the descending layers of the protocol stack each layer adds encapsulation information as illustrated in the diagram (right). A receiving host reverses the encapsulation at each layer by extracting the higher level data and passing it up the stack to the receiving process.
23
The following table shows the layer names before transmission on the local network link and the number of layers of networking models presented in RFCs and textbooks in widespread use in today's university computer networking courses.
RFC 1122 [11] Four layers [18] "Internet model" Tanenbaum Cisco [12] Academy Four layers Kurose [13] Forouzan [14] [15] Comer [16] Kozierok Four+one layers Stallings [17] Arpanet Reference Model 1982 (RFC 871) Three layers
Four layers
[19]
Five layers
Five layers
"Internet model"
Application
Application
Application
Application/Process
Transport
Transport
Transport
Transport
Host-to-host
Internet Host-to-network
Internet
[18]
Network interface
Physical
These textbooks are secondary sources that may contravene the intent of RFC 1122 and other IETF primary sources.[22] Different authors have interpreted the RFCs differently regarding the question whether the link layer (and the TCP/IP model) covers OSI model layer 1 (physical layer) issues, or if a hardware layer is assumed below the link layer. Some authors have tried to use other names for the link layer, such as network interface layer, in view to avoid confusion with the similarly named OSI model layer 2 (data link layer) of the seven layer OSI model. Others have attempted to map the Internet Protocol model onto the OSI model. The mapping often results in a model with five layers where the link layer is split into an OSI model layer 2 (data link layer) on top of an OSI model layer 1 (physical layer). In literature with a bottom-up approach to Internet communication,[14] [15] [17] in which hardware issues are emphasized, those are often discussed in terms of OSI model layer 1 (physical layer) and OSI model layer 2 (data link layer).
Internet protocol suite The internet layer is usually directly mapped into OSI model layer 3 (network layer), a more general concept of network functionality. The transport layer of the TCP/IP model, sometimes also described as the host-to-host layer, is mapped to OSI layer 4 (transport layer), sometimes also including aspects of OSI layer 5 (session layer) functionality. OSI layer 7 (application layer), OSI layer 6 (presentation layer), and the remaining functionality of OSI layer 5 (session layer) are collapsed into TCP/IP's application layer. The argument is that these OSI layers do not usually exist as separate processes and protocols in Internet applications. However, the Internet protocol stack has never been altered by the Internet Engineering Task Force from the four layers defined in RFC 1122. The IETF makes no effort to follow the OSI model although RFCs sometimes refer to it. The IETF has repeatedly stated that Internet protocol and architecture development is not intended to be compliant to the OSI model. RFC 3439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".[22]
24
Implementations
Most computer operating systems in use today, including all consumer-targeted systems, include a TCP/IP implementation. Minimally acceptable implementation includes implementation for (from most essential to the less essential) IP, ARP, ICMP, UDP, TCP and sometimes IGMP. It is in principle possible to support only one of transport protocols (i.e. simple UDP), but it is rarely done, as it limits usage of the whole implementation. IPv6, beyond own version of ARP (NBP), and ICMP (ICMPv6), and IGMP (IGMPv6) have some additional required functions, and often is accompanied with integrated IPSec security layer. Other protocols could be easily added later (often they can be implemented entirely in the userspace), for example DNS for resolving domain names to IP addresses or DHCP client for automatic configuration of network interfaces. Most of the IP implementations are accessible to the programmers using socket abstraction (usable also with other protocols) and proper API for most of the operations. This interface is known as BSD sockets and was used initially in C. Unique implementations include Lightweight TCP/IP, an open source stack designed for embedded systems and KA9Q NOS, a stack and associated protocols for amateur packet radio systems and personal computers connected via serial lines.
References
[1] [2] [3] [4] [5] [6] RFC 1122, Requirements for Internet Hosts Communication Layers, R. Braden (ed.), October 1989 RFC 1123, Requirements for Internet Hosts Application and Support, R. Braden (ed.), October 1989 RFC 1812, Requirements for IP Version 4 Routers, F. Baker (June 1995) RFC 675, Specification of Internet Transmission Control Protocol, V. Cerf et al. (December 1974) Internet History (http:/ / www. livinginternet. com/ i/ ii. htm) Ronda Hauben. "From the ARPANET to the Internet" (http:/ / www. columbia. edu/ ~rh120/ other/ tcpdigest_paper. txt). TCP Digest (UUCP). . Retrieved 2007-07-05. [7] http:/ / support. microsoft. com/ kb/ 108007 [8] (http:/ / www. weblab. isti. cnr. it/ education/ ssfs/ lezioni/ slides/ archives/ cern. htm) [9] (http:/ / www. romkey. com/ about/ ) [10] Barry Appelman [11] IETF, RFC 1122, p.7, "To communicate using the Internet system, a host must implement the layered set of protocols comprising the Internet protocol suite. A host typically must implement at least one protocol from each layer." [12] Mark Dye, Mark A. Dye, Wendell, Network Fundamentals: CCNA Exploration Companion Guide, 2007, ISBN 1-58713-208-7 [13] James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 2008, ISBN 0-321-49770-8 (http:/ / www. pearsonhighered. com/ educator/ academic/ product/ 0,,0321497708,00+ en-USS_01DBC. html) [14] Behrouz A. Forouzan, Data Communications and Networking (http:/ / books. google. com/ books?id=U3Gcf65Pu9IC& printsec=frontcover& dq=forouzan+ "computer+ networks"#PPA29,M1)
25
Further reading
Douglas E. Comer. Internetworking with TCP/IP - Principles, Protocols and Architecture. ISBN 86-7991-142-9 Joseph G. Davies and Thomas F. Lee. Microsoft Windows Server 2003 TCP/IP Protocols and Services. ISBN 0-7356-1291-9 Forouzan, Behrouz A. (2003). TCP/IP Protocol Suite (2nd ed.). McGraw-Hill. ISBN0-07-246060-1. Craig Hunt TCP/IP Network Administration. O'Reilly (1998) ISBN 1-56592-322-7 Maufer, Thomas A. (1999). IP Fundamentals. Prentice Hall. ISBN0-13-975483-0. Ian McLean. Windows(R) 2000 TCP/IP Black Book. ISBN 1-57610-687-X Ajit Mungale Pro .NET 1.1 Network Programming. ISBN 1-59059-345-6 W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. ISBN 0-201-63346-9 W. Richard Stevens and Gary R. Wright. TCP/IP Illustrated, Volume 2: The Implementation. ISBN 0-201-63354-X W. Richard Stevens. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. ISBN 0-201-63495-3 Andrew S. Tanenbaum. Computer Networks. ISBN 0-13-066102-3 Clark, D. (1988). "The Design Philosophy of the DARPA Internet Protocols" (http://www.cs.princeton.edu/ ~jrex/teaching/spring2005/reading/clark88.pdf). SIGCOMM '88 Symposium proceedings on Communications architectures and protocols (ACM): 106114. doi:10.1145/52324.52336. Retrieved 2011-10-16.
External links
Internet History (http://www.livinginternet.com/i/ii.htm) -- Pages on Robert Kahn, Vinton Cerf, and TCP/IP (reviewed by Cerf and Kahn). RFC 675 (http://www.ietf.org/rfc/rfc0675.txt) - Specification of Internet Transmission Control Program, December 1974 Version TCP/IP State Transition Diagram (http://www.night-ray.com/TCPIP_State_Transition_Diagram.pdf) (PDF) RFC 1180 A TCP/IP Tutorial - from the Internet Engineering Task Force (January 1991) TCP/IP FAQ (http://www.itprc.com/tcpipfaq/) TCP/IP Resources List (http://www.private.org.il/tcpip_rl.html) The TCP/IP Guide (http://www.tcpipguide.com/free/) - A comprehensive look at the protocols and the procedures/processes involved A Study of the ARPANET TCP/IP Digest (http://www.columbia.edu/~rh120/other/tcpdigest_paper.txt) TCP/IP Sequence Diagrams (http://www.eventhelix.com/RealtimeMantra/Networking/) The Internet in Practice (http://www.searchandgo.com/articles/internet/internet-practice-4.php) TCP/IP - Directory & Informational Resource (http://softtechinfo.com/network/tcpip.html)
Internet protocol suite Daryl's TCP/IP Primer (http://www.ipprimer.com) - Intro to TCP/IP LAN administration, conversational style Introduction to TCP/IP (http://www.linux-tutorial.info/MContent-142) TCP/IP commands from command prompt (http://blog.webgk.com/2007/10/ dns-tcpip-commands-from-command-prompt.html) cIPS (http://sourceforge.net/projects/cipsuite/) Robust TCP/IP stack for embedded devices without an Operating System
26
27
Application INAP, MAP, IS-41... TCAP, CAP, ISUP, ... Network Datalink Physical MTP Level 3 + SCCP MTP Level 2 MTP Level 1
Signalling System No. 7 (SS7) is a set of telephony signaling protocols which are used to set up most of the world's public switched telephone network telephone calls. The main purpose is to set up and tear down telephone calls. Other uses include number translation, local number portability, prepaid billing mechanisms, short message service (SMS), and a variety of other mass market services. It is usually referenced as Signalling System No. 7 or Signalling System #7, or simply abbreviated to SS7. In North America it is often referred to as CCSS7, an abbreviation for Common Channel Signalling System 7. In some European countries, specifically the United Kingdom, it is sometimes called C7 (CCITT number 7) and is also known as number 7 and CCIS7 (Common Channel Interoffice Signaling 7). There is only one international SS7 protocol defined by ITU-T in its Q.700-series recommendations.[1] There are however, many national variants of the SS7 protocols. Most national variants are based on two widely deployed national variants as standardized by ANSI and ETSI, which are in turn based on the international protocol defined by ITU-T. Each national variant has its own unique characteristics. Some national variants with rather striking characteristics are the China (PRC) and Japan (TTC) national variants. The Internet Engineering Task Force (IETF) has also defined level 2, 3, and 4 protocols that are compatible with SS7: MTP2 (M2UA and M2PA) MTP3 (M3UA) Signalling Connection Control Part (SCCP) (SUA) but use a Stream Control Transmission Protocol (SCTP) transport mechanism. This suite of protocols is called SIGTRAN.
History
Common Channel Signaling protocols have been developed by major telephone companies and the ITU-T since 1975 and the first international Common Channel Signaling protocol was defined by the ITU-T as Signalling System No. 6 (SS6) in 1977.[2] Signalling System No. 7 was defined as an international standard by ITU-T in its 1980 (Yellow Book) Q.7XX-series recommendations.[1] SS7 was designed to replace SS6, which had a restricted 28-bit signal unit that was both limited in function and not amenable to digital systems.[2] SS7 has substantially replaced SS6, Signalling System No. 5 (SS5), R1 and R2, with the exception that R1 and R2 variants are still used in numerous nations. SS5 and earlier systems used in-band signaling, in which the call-setup information was sent by playing special multi-frequency tones into the telephone lines, known as bearer channels in the parlance of the telecom industry. This led to security problems with blue boxes. SS6 and SS7 implement out-of-band signaling protocols, carried in a separate signaling channel,[3] explicitly keep the end-user's audio paththe so-called speech pathseparate from
Signalling System No. 7 the signaling phase to eliminate the possibility that end users may introduce tones that would be mistaken for those used for signaling. See falsing. SS6 and SS7 are referred to as so-called Common Channel Interoffice Signalling Systems (CCIS) or Common Channel Signaling (CCS) due to their hard separation of signaling and bearer channels. This required a separate channel dedicated solely to signaling, but the greater speed of signaling decreased the holding time of the bearer channels, and the number of available channels was rapidly increasing anyway at the time SS7 was implemented. The common channel signaling paradigm was translated to IP via the SIGTRAN protocols as defined by the IETF. While running on a transport based upon IP, the SIGTRAN protocols are not an SS7 variant, but simply transport existing national and international variants of SS7.[4]
28
Functionality
The term signaling, when used in telephony, refers to the exchange of control information associated with the establishment of a telephone call on a telecommunications circuit.[5] An example of this control information is the digits dialed by the caller, the caller's billing number, and other call-related information. When the signaling is performed on the same circuit that will ultimately carry the conversation of the call, it is termed channel associated signaling (CAS). This is the case for earlier analogue trunks, MF and R2 digital trunks, and DSS1/DASS PBX trunks. In contrast, SS7 signaling is termed Common Channel Signaling (CCS) in that the path and facility used by the signaling is separate and distinct from the telecommunications channels that will ultimately carry the telephone conversation. With CCS, it becomes possible to exchange signaling without first seizing a facility, leading to significant savings and performance increases in both signaling and facility usage. Because of the mechanisms used by signaling methods prior to SS7 (battery reversal, multi-frequency digit outpulsing, A- and B-bit signaling), these older methods could not communicate much signaling information. Usually only the dialed digits were signaled, and only during call setup. For charged calls, dialed digits and charge number digits were outpulsed. SS7, being a high-speed and high-performance packet-based communications protocol, can communicate significant amounts of information when setting up a call, during the call, and at the end of the call. This permits rich call-related services to be developed. Some of the first such services were call management related services that many take for granted today: call forwarding (busy and no answer), voice mail, call waiting, conference calling, calling name and number display, call screening, malicious caller identification, busy callback.[6] The earliest deployed upper layer protocols in the SS7 signaling suite were dedicated to the setup, maintenance, and release of telephone calls.[7] The Telephone User Part (TUP) was adopted in Europe and the Integrated Services Digital Network (ISDN) User Part (ISUP) adapted for public switched telephone network (PSTN) calls was adopted in North America. ISUP was later used in Europe when the European networks upgraded to the ISDN. (North America never accomplished full upgrade to the ISDN and the predominant telephone service is still the older POTS.) Due to its richness and the need for an out-of-band channel for its operation, SS7 signaling is mostly used for signaling between telephone switches and not for signaling between local exchanges and customer-premises equipment (CPE). Because SS7 signaling does not require seizure of a channel for a conversation prior to the exchange of control information, non-facility associated signalling (NFAS) became possible. NFAS is signaling that is not directly associated with the path that a conversation will traverse and may concern other information located at a centralized database such as service subscription, feature activation, and service logic. This makes possible a set of network-based services that do not rely upon the call being routed to a particular subscription switch at which service logic would be executed, but permits service logic to be distributed throughout the telephone network and executed more expediently at originating switches far in advance of call routing. It also permits the subscriber increased mobility due to the decoupling of service logic from the subscription switch. Another characteristic of ISUP made
Signalling System No. 7 possible by SS7 with NFAS is the exchange of signaling information during the middle of a call.[5] Also possible with SS7 is Non-Call-Associated Signaling, which is signaling that is not directly related to the establishment of a telephone call.[8] An example of this is the exchange of the registration information used between a mobile telephone and a home location register (HLR) database: a database that tracks the location of the mobile. Other examples include Intelligent Network and local number portability databases.[9]
29
Signaling modes
As well as providing for signaling with these various degrees of association with call set up and the facilities used to carry calls, SS7 is designed to operate in two modes: associated mode and quasi-associated mode.[10] When operating in the associated mode, SS7 signaling progresses from switch to switch through the PSTN following the same path as the associated facilities that carry the telephone call. This mode is more economical for small networks. The associated mode of signaling is not the predominant choice of modes in North America.[11] When operating in the quasi-associated mode, SS7 signaling progresses from the originating switch to the terminating switch, following a path through a separate SS7 signaling network composed of signal transfer points. This mode is more economical for large networks with lightly loaded signaling links. The quasi-associated mode of signaling is the predominant choice of modes in North America.[12]
Physical network
SS7 is an out-of-band signaling protocol, i.e. separate from the bearer channels that carry the voice or data. This separation extends onto the physical network by having circuits that are solely dedicated to carrying the SS7 links. Clearly splitting the signaling plane and voice circuits. An SS7 network has to be made up of SS7-capable equipment from end to end in order to provide its full functionality. The network is made up of several link types (A, B, C, D, E, and F) and three signaling nodes - Service switching point (SSPs), signal transfer point (STPs), and service control point (SCPs). Each node is identified on the network by a number, a point code. Extended services are provided by a database interface at the SCP level using the SS7 network. The links between nodes are full-duplex 56, 64, 1,536, or 1,984 kbit/s graded communications channels. In Europe they are usually one (64 kbit/s) or all (1,984 kbit/s) timeslots (DS0s) within an E1 facility; in North America one (56 or 64 kbit/s) or all (1,536 kbit/s) timeslots (DS0As or DS0s) within a T1 facility. One or more signaling links can be connected to the same two endpoints that together form a signaling link set. Signaling links are added to link sets to increase the signaling capacity of the link set. In Europe, SS7 links normally are directly connected between switching exchanges using F-links. This direct connection is called associated signaling. In North America, SS7 links are normally indirectly connected between switching exchanges using an intervening network of STPs. This indirect connection is called quasi-associated signaling. Quasi-associated signaling reduces the number of SS7 links necessary to interconnect all switching exchanges and SCPs in an SS7 signaling network.[13] SS7 links at higher signaling capacity (1.536 and 1.984 Mbit/s, simply referred to as the 1.5 Mbit/s and 2.0 Mbit/s rates) are called high speed links (HSL) in contrast to the low speed (56 and 64 kbit/s) links. High speed links are specified in ITU-T Recommendation Q.703 [14] for the 1.5 Mbit/s and 2.0 Mbit/s rates, and ANSI Standard T1.111.3 for the 1.536 Mbit/s rate. There are differences between the specifications for the 1.5 Mbit/s rate. High speed links utilize the entire bandwidth of a T1 (1.536 Mbit/s) or E1 (1.984 Mbit/s) transmission facility for the transport of SS7 signaling messages.[15] SIGTRAN provides signaling using SCTP associations over the Internet Protocol.[16] The protocols for SIGTRAN are M2PA, M2UA, M3UA and SUA.
30
Application INAP, MAP, IS-41... TCAP, CAP, ISUP, ... Network Datalink Physical MTP Level 3 + SCCP MTP Level 2 MTP Level 1
The SS7 protocol stack borrows partially from the OSI Model of a packetized digital protocol stack. OSI layers 1 to 3 are provided by the Message Transfer Part (MTP) and the Signalling Connection Control Part (SCCP) of the SS7 protocol (together referred to as the Network Service Part (NSP)); for circuit related signaling, such as the Telephone User Part (TUP) or the ISDN User Part (ISUP), the User Part provides layer 7. Currently there are no protocol components that provide OSI layers 4 through 6.[1] The Transaction Capabilities Application Part (TCAP) is the primary SCCP User in the Core Network, using SCCP in connectionless mode. SCCP in connection oriented mode provides the transport layer for air interface protocols such as BSSAP and RANAP. TCAP provides transaction capabilities to its Users (TC-Users), such as the Mobile Application Part, the Intelligent Network Application Part and the CAMEL Application Part. The Message Transfer Part (MTP) covers a portion of the functions of the OSI network layer including: network interface, information transfer, message handling and routing to the higher levels. Signalling Connection Control Part (SCCP) is at functional Level 4. Together with MTP Level 3 it is called the Network Service Part (NSP). SCCP completes the functions of the OSI network layer: end-to-end addressing and routing, connectionless messages (UDTs), and management services for users of the Network Service Part (NSP).[17] Telephone User Part (TUP) is a link-by-link signaling system used to connect calls. ISDN User Part (ISUP) is the key user part, providing a circuit-based protocol to establish, maintain, and end the connections for calls. Transaction Capabilities Application Part (TCAP) is used to create database queries and invoke advanced network functionality, or links to Intelligent Network Application Part (INAP) for intelligent networks, or Mobile Application Part (MAP) for mobile services.
References
[1] ITU-T Recommendation Q.700 (http:/ / www. itu. int/ rec/ T-REC-Q. 700/ en) [2] (Ronayne 1986, p.145). [3] (Ronayne 1986, p.141). [4] RFC 2719 (http:/ / www. ietf. org/ rfc/ rfc2719. txt) - Framework Architecture for Signaling Transport [5] (Russell 2002, p.318). [6] (Russell 2002, p.xx). [7] ITU-T Recommendation Q.700 (http:/ / www. itu. int/ rec/ T-REC-Q. 700-199303-I/ en/ ), Section 3.2.1, p. 7. [8] (Russell 2002, p.319). [9] (Russell 2002, p.433). [10] ITU-T Recommendation Q.700 (http:/ / www. itu. int/ rec/ T-REC-Q. 700-199303-I/ en/ ), p. 4. [11] (Dryburgh 2004, pp.2223). [12] (Dryburgh 2004, p.23). [13] ITU-T Recommendation Q.700 (http:/ / www. itu. int/ rec/ T-REC-Q. 700-199303-I/ en/ ), Section 2.2.3, "signaling modes", pp. 4-5. [14] http:/ / www. itu. int/ rec/ T-REC-Q. 703-199607-I/ en/ [15] ITU-T Recommendation Q.703 (http:/ / www. itu. int/ rec/ T-REC-Q. 703-199607-I/ en/ ), Annex A, "Additions for a national option for high speed signaling links", pp 81-86. [16] (Russell 2002, p.456). [17] ITU-T Recommendation Q.711 (http:/ / www. itu. int/ rec/ T-REC-Q. 711-200103-I/ en/ ), Section 1, "Scope and field of application", pp 1-2.
Signalling System No. 7 Dryburgh, Lee; Jeff Hewitt (2004). Signalling System No. 7 (SS7/C7): Protocol, Architecture, and Services. Indianapolis: Cisco Press. ISBN1-587-05040-4. Link to online version of text below. Ronayne, John P. (1986). "The Digital Network". Introduction to Digital Communications Switching (1st edition ed.). Indianapolis: Howard W. Sams & Co., Inc.. ISBN0-672-22498-4. Russell, Travis (2002). Signaling System #7 (4th Edition ed.). New York: McGraw-Hill. ISBN978-0071387729.
31
External links
Signaling System No. 7 (SS7/C7): Protocol, Architecture, and Services (http://www.ss7-training.net). Full HTML version of the 2004 edition of the Dryburgh/Hewitt book (above). SS7 Protocol layer architecture overview, tutorials and discussion forum (http://www.telecomspace.com/ss7. html) SS7 - A Brief Comparison with TCP/IP (http://www.kenneyjacob.com/2007/06/05/ ss7-backbone-of-mobile-networks) www.protocols.com: practical overview (http://www.protocols.com/pbook/pdf/ss7.pdf) SS7 open source project (http://www.openss7.org) Mobicents SS7 open source project (http://www.mobicents.org/ss7/intro.html) Introduction to signaling (http://www.buzzinbees.com/services-tutorials.php). A tutorial about signaling. Excellent SS7 Tutorial (http://www.pt.com/page/tutorials/ss7-tutorial) SeveNTest online SS7 decoder (http://decoder.seventest.com/cgi-bin/decoder)
History
The first telephones had no network but were in private use, wired together in pairs. Users who wanted to talk to different people had as many telephones as necessary for the purpose. A user who wished to speak whistled into the transmitter until the other party heard. Soon, however, a bell was added for signalling, and then a switch hook, and telephones took advantage of the exchange principle already employed in telegraph networks. Each telephone was wired to a local telephone exchange, and the exchanges were wired together with trunks. Networks were connected together in a hierarchical manner until they spanned cities, countries, continents and oceans. This was the beginning of the PSTN, though the term was unknown for many decades. Automation introduced pulse dialing between the phone and the exchange, and then among exchanges, followed by more sophisticated address signaling including multi-frequency, culminating in the SS7 network that connected most exchanges by the end of the 20th century.
Public switched telephone network The growth of the PSTN meant that traffic engineering techniques needed to be deployed to deliver quality of service (QoS) guarantees for the users. The work of A.K. Erlang established the mathematical foundations of methods required to determine the capacity requirements and configuration of equipment and the number of personnel required to deliver a specific level of service. In the 1970s the telecommunications industry began implementing packet switched network data services using the X.25 protocol transported over much of the end-to-end equipment as was already in use in the PSTN. In the 1980s the industry began planning for digital services assuming they would follow much the same pattern as voice services, and conceived a vision of end-to-end circuit switched services, known as the Broadband Integrated Services Digital Network (B-ISDN). The B-ISDN vision has been overtaken by the disruptive technology of the Internet. Today, only the oldest parts of the telephone network still use analog technology for anything other than the last mile loop to the end user, and in recent years digital services have been increasingly rolled out to end users using services such as DSL, ISDN, FTTx and cable modem systems. There are a number of large private telephone networks which are not linked to the PSTN, usually for military purposes. There are also private networks run by large companies which are linked to the PSTN only through limited gateways, like a large private branch exchange (PBX).
32
PSTN operators
The task of building the networks and selling services to customers fell to the network operators. The first company to be incorporated to provide PSTN services was the Bell Telephone Company in the United States. In some countries however, the job of providing telephone networks fell to government as the investment required was very large and the provision of telephone service was increasingly becoming an essential public utility. For example, the General Post Office in the United Kingdom brought together a number of private companies to form a single nationalised company. In recent decades however, these state monopolies were broken up or sold off through privatization.
33
Digital channels
As described above, most automated telephone exchanges now use digital switching rather than mechanical or analog switching. The trunks connecting the exchanges are also digital, called circuits or channels. However analog two-wire circuits are still used to connect the last mile from the exchange to the telephone in the home (also called the local loop). To carry a typical phone call from a calling party to a called party, the analog audio signal is digitized at an 8kHz sample rate with 8-bit resolution using a special type of nonlinear pulse code modulation known as G.711. The call is then transmitted from one end to another via telephone exchanges. The call is switched using a call set up protocol (usually ISUP) between the telephone exchanges under an overall routing strategy. The call is carried over the PSTN using a 64 kbit/s channel, originally designed by Bell Labs. The name given to this channel is Digital Signal 0 (DS0). The DS0 circuit is the basic granularity of circuit switching in a telephone exchange. A DS0 is also known as a timeslot because DS0s are aggregated in time-division multiplexing (TDM) equipment to form higher capacity communication links. A Digital Signal 1 (DS1) circuit carries 24 DS0s on a North American or Japanese T-carrier (T1) line, or 32 DS0s (30 for calls plus two for framing and signaling) on an E-carrier (E1) line used in most other countries. In modern networks, the multiplexing function is moved as close to the end user as possible, usually into cabinets at the roadside in residential areas, or into large business premises. These aggregated circuits are conveyed from the initial multiplexer to the exchange over a set of equipment collectively known as the access network. The access network and inter-exchange transport use synchronous optical transmission, for example, SONET and Synchronous Digital Hierarchy (SDH) technologies, although some parts still use the older PDH technology. Within the access network, there are a number of reference points defined. Most of these are of interest mainly to ISDN but one the V reference point is of more general interest. This is the reference point between a primary multiplexer and an exchange. The protocols at this reference point were standardized in ETSI areas as the V5 interface.
Impact on IP standards
Voice quality over PSTN networks was used as the benchmark for the development of the Telecommunications Industry Association's TIA-TSB-116 standard on voice-quality recommendations for IP telephony, to determine acceptable levels of audio delay and echo.[1]
References
[1] "IHS - Document Details" (http:/ / global. ihs. com/ doc_detail. cfm?currency_code=USD& customer_id=21254C2A5E0A& oshid=21254C2A5C0A& shopping_cart_id=292558332E4B4048405B2D33220A& country_code=US& lang_code=ENGL& item_s_key=00381377& item_key_date=880731& input_doc_number=TSB-116& input_doc_title=). Global.ihs.com. . Retrieved 2011-11-20.
Voice over IP
34
Voice over IP
Voice over Internet Protocol (Voice over IP, VoIP) is a family of technologies, methodologies, communication protocols, and transmission techniques for the delivery of voice communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet. Other terms frequently encountered and often used synonymously with VoIP are IP telephony, Internet telephony, voice over broadband (VoBB), broadband telephony, and broadband phone. Internet telephony refers to communications servicesVoice, fax, SMS, and/or voice-messaging applicationsthat are transported via the Internet, rather than the public switched telephone network (PSTN). The steps involved in originating a VoIP telephone call are signaling and media channel setup, digitization of the analog voice signal, encoding, packetization, and transmission as Internet Protocol (IP) packets over a packet-switched network. On the receiving side, similar steps (usually in the reverse order) such as reception of the IP packets, decoding of the packets and digital-to-analog conversion reproduce the original voice stream.[1] Even though IP Telephony and VoIP are terms that are used interchangeably, they are actually different; IP telephony has to do with digital telephony systems that use IP protocols for voice communication while VoIP is actually a subset of IP Telephony. VoIP is a technology used by IP telephony as a means of transporting phone calls.[2] VoIP systems employ session control protocols to control the set-up and tear-down of calls as well as audio codecs which encode speech allowing transmission over an IP network as digital audio via an audio stream. The codec used is varied between different implementations of VoIP (and often a range of codecs are used); some implementations rely on narrowband and compressed speech, while others support high fidelity stereo codecs. VoIP is available on many smartphones and internet devices so even the users of portable devices that are not phones can still make calls or send SMS text messages over 3G or Wi-Fi.[3]
Protocols
Voice over IP has been implemented in various ways using both proprietary and open protocols and standards. Examples of technologies used to implement Voice over IP include: H.323 IP Multimedia Subsystem (IMS) Media Gateway Control Protocol (MGCP) Session Initiation Protocol (SIP) Real-time Transport Protocol (RTP) Session Description Protocol (SDP) Inter-Asterisk eXchange (IAX)
The H.323 protocol was one of the first VoIP protocols that found widespread implementation for long-distance traffic, as well as local area network services. However, since the development of newer, less complex protocols, such as MGCP and SIP, H.323 deployments are increasingly limited to carrying existing long-haul network traffic. In particular, the Session Initiation Protocol (SIP) has gained widespread VoIP market penetration. A notable proprietary implementation is the Skype protocol, which is in part based on the principles of peer-to-peer (P2P) networking.
Voice over IP
35
Adoption
Consumer market
A major development that started in 2004 was the introduction of mass-market VoIP services that utilize existing broadband Internet access, by which subscribers place and receive telephone calls in much the same manner as they would via the public switched telephone network (PSTN). Full-service VoIP phone companies provide inbound and outbound service with Direct Inbound Dialing. Many offer unlimited domestic calling for a flat monthly subscription fee. This sometimes includes international calls to certain countries. Phone calls between subscribers of the same provider are usually free when flat-fee service is not available A VoIP phone is necessary to connect to a VoIP service provider. This can be implemented in several ways: Dedicated VoIP phones connect directly to the IP network using technologies such as wired Ethernet or wireless Wi-Fi. They are typically designed in the style of traditional digital business telephones.
Example of residential network including VoIP
An analog telephone adapter is a device that connects to the network and implements the electronics and firmware to operate a conventional analog telephone attached through a modular phone jack. Some residential Internet gateways and cablemodems have this function built in. A softphone is application software installed on a networked computer that is equipped with a microphone and speaker, or headset. The application typically presents a dial pad and display field to the user to operate the application by mouse clicks or keyboard input.
Corporate use
Because of the bandwidth efficiency and low costs that VoIP technology can provide, businesses are migrating from traditional copper-wire telephone systems to VoIP systems to reduce their monthly phone costs. In 2008, 80% of all new PBX lines installed internationally were VoIP.[6] VoIP solutions aimed at businesses have evolved into "unified communications" services that treat all communicationsphone calls, faxes, voice mail, e-mail, Web conferences and moreas discrete units that can all be delivered via any means and to any handset, including cellphones. Two kinds of competitors are competing in this space: one set is focused on VoIP for medium to large enterprises, while another is targeting the small-to-medium business (SMB) market.[7] VoIP allows both voice and data communications to be run over a single network, which can significantly reduce infrastructure costs.[8] The prices of extensions on VoIP are lower than for PBX and key systems. VoIP switches may run on commodity hardware, such as PCs or Linux systems. Rather than closed architectures, these devices rely on standard interfaces.[8]
Voice over IP VoIP devices have simple, intuitive user interfaces, so users can often make simple system configuration changes. Dual-mode phones enable users to continue their conversations as they move between an outside cellular service and an internal Wi-Fi network, so that it is no longer necessary to carry both a desktop phone and a cellphone. Maintenance becomes simpler as there are fewer devices to oversee.[8] Skype, which originally marketed itself as a service among friends, has begun to cater to businesses, providing free-of-charge connections between any users on the Skype network and connecting to and from ordinary PSTN telephones for a charge.[9] In the United States the Social Security Administration (SSA) is converting its field offices of 63,000 workers from traditional phone installations to a VoIP infrastructure carried over its existing data network.[10] [11]
36
Advantages
Operational cost
VoIP can be a benefit for reducing communication and infrastructure costs. Examples include: Routing phone calls over existing data networks to avoid the need for separate voice and data networks.[12] The ability to transmit more than one telephone call over a single broadband connection. Secure calls using standardized protocols (such as Secure Real-time Transport Protocol). Most of the difficulties of creating a secure telephone connection over traditional phone lines, such as digitizing and digital transmission, are already in place with VoIP. It is only necessary to encrypt and authenticate the existing data stream.
Challenges
Quality of service
Communication on the IP network is inherently less reliable in contrast to the circuit-switched public telephone network, as it does not provide a network-based mechanism to ensure that data packets are not lost, and are delivered in sequential order. It is a best-effort network without fundamental Quality of Service (QoS) guarantees. Therefore, VoIP implementations may face problems mitigating latency and jitter.[13] [14] By default, network routers handle traffic on a first-come, first-served basis. Network routers on high volume traffic links may introduce latency that exceeds permissible thresholds for VoIP. Fixed delays cannot be controlled, as they are caused by the physical distance the packets travel; however, latency can be minimized by marking voice packets as being delay-sensitive with methods such as DiffServ.[13] A VoIP packet usually has to wait for the current packet to finish transmission, although it is possible to preempt (abort) a less important packet in mid-transmission, although this is not commonly done, especially on high-speed links where transmission times are short even for maximum-sized packets.[15] An alternative to preemption on slower links, such as dialup and DSL, is to reduce the maximum transmission time by reducing the maximum transmission unit. But every packet must contain protocol headers, so this increases relative header overhead on every link along the user's Internet paths, not just the bottleneck (usually Internet access) link.[15] ADSL modems provide Ethernet (or Ethernet over USB) connections to local equipment, but inside they are actually Asynchronous Transfer Mode (ATM) modems. They use ATM Adaptation Layer 5 (AAL5) to segment each Ethernet packet into a series of 53-byte ATM cells for transmission and reassemble them back into Ethernet packets at the receiver. A virtual circuit identifier (VCI) is part of the 5-byte header on every ATM cell, so the transmitter can multiplex the active virtual circuits (VCs) in any arbitrary order. Cells from the same VC are always sent sequentially. However, the great majority of DSL providers use only one VC for each customer, even those with bundled VoIP service. Every Ethernet packet must be completely transmitted before another can begin. If a second PVC were
Voice over IP established, given high priority and reserved for VoIP, then a low priority data packet could be suspended in mid-transmission and a VoIP packet sent right away on the high priority VC. Then the link would pick up the low priority VC where it left off. Because ATM links are multiplexed on a cell-by-cell basis, a high priority packet would have to wait at most 53 byte times to begin transmission. There would be no need to reduce the interface MTU and accept the resulting increase in higher layer protocol overhead, and no need to abort a low priority packet and resend it later. ATM has substantial header overhead: 5/53 = 9.4%, roughly twice the total header overhead of a 1500 byte TCP/IP Ethernet packet (with TCP timestamps). This "ATM tax" is incurred by every DSL user whether or not he takes advantage of multiple virtual circuits-and few can.[13] ATM's potential for latency reduction is greatest on slow links, because worst-case latency decreases with increasing link speed. A full-size (1500 byte) Ethernet frame takes 94ms to transmit at 128kbit/s but only 8ms at 1.5Mbit/s. If this is the bottleneck link, this latency is probably small enough to ensure good VoIP performance without MTU reductions or multiple ATM PVCs. The latest generations of DSL, VDSL and VDSL2, carry Ethernet without intermediate ATM/AAL5 layers, and they generally support IEEE 802.1p priority tagging so that VoIP can be queued ahead of less time-critical traffic.[13] Voice, and all other data, travels in packets over IP networks with fixed maximum capacity. This system may be more prone to congestion and DoS attacks[16] than traditional circuit switched systems; a circuit switched system of insufficient capacity will refuse new connections while carrying the remainder without impairment, while the quality of real-time data such as telephone conversations on packet-switched networks degrades dramatically.[13] Fixed delays cannot be controlled as they are caused by the physical distance the packets travel. They are especially problematic when satellite circuits are involved because of the long distance to a geostationary satellite and back; delays of 400600ms are typical. When the load on a link grows so quickly that its switches experience queue overflows, congestion results and data packets are lost. This signals a transport protocol like TCP to reduce its transmission rate to alleviate the congestion. But VoIP usually uses UDP not TCP because recovering from congestion through retransmission usually entails too much latency.[13] So QoS mechanisms can avoid the undesirable loss of VoIP packets by immediately transmitting them ahead of any queued bulk traffic on the same link, even when that bulk traffic queue is overflowing. The receiver must resequence IP packets that arrive out of order and recover gracefully when packets arrive too late or not at all. Jitter results from the rapid and random (i.e., unpredictable) changes in queue lengths along a given Internet path due to competition from other users for the same transmission links. VoIP receivers counter jitter by storing incoming packets briefly in a "de-jitter" or "playout" buffer, deliberately increasing latency to improve the chance that each packet will be on hand when it is time for the voice engine to play it. The added delay is thus a compromise between excessive latency and excessive dropout, i.e., momentary audio interruptions. Although jitter is a random variable, it is the sum of several other random variables that are at least somewhat independent: the individual queuing delays of the routers along the Internet path in question. Thus according to the central limit theorem, we can model jitter as a gaussian random variable. This suggests continually estimating the mean delay and its standard deviation and setting the playout delay so that only packets delayed more than several standard deviations above the mean will arrive too late to be useful. In practice, however, the variance in latency of many Internet paths is dominated by a small number (often one) of relatively slow and congested "bottleneck" links. Most Internet backbone links are now so fast (e.g. 10Gbit/s) that their delays are dominated by the transmission medium (e.g. optical fiber) and the routers driving them do not have enough buffering for queuing delays to be significant. It has been suggested to rely on the packetized nature of media in VoIP communications and transmit the stream of packets from the source phone to the destination phone simultaneously across different routes (multi-path routing).[17] In such a way, temporary failures have less impact on the communication quality. In capillary routing it has been suggested to use at the packet level Fountain codes or particularly raptor codes for transmitting extra
37
Voice over IP redundant packets making the communication more reliable. A number of protocols have been defined to support the reporting of QoS/QoE for VoIP calls. These include RTCP Extended Report (RFC 3611), SIP RTCP Summary Reports, H.460.9 Annex B (for H.323), H.248.30 and MGCP extensions. The RFC 3611 VoIP Metrics block is generated by an IP phone or gateway during a live call and contains information on packet loss rate, packet discard rate (because of jitter), packet loss/discard burst metrics (burst length/density, gap length/density), network delay, end system delay, signal / noise / echo level, Mean Opinion Scores (MOS) and R factors and configuration information related to the jitter buffer. RFC 3611 VoIP metrics reports are exchanged between IP endpoints on an occasional basis during a call, and an end of call message sent via SIP RTCP Summary Report or one of the other signaling protocol extensions. RFC 3611 VoIP metrics reports are intended to support real time feedback related to QoS problems, the exchange of information between the endpoints for improved call quality calculation and a variety of other applications. Layer-2 quality of service A number of protocols that deal with the data link layer and physical layer include quality-of-service mechanisms that can be used to ensure that applications like VoIP work well even in congested scenarios. Some examples include: IEEE 802.11e is an approved amendment to the IEEE 802.11 standard that defines a set of quality-of-service enhancements for wireless LAN applications through modifications to the Media Access Control (MAC) layer. The standard is considered of critical importance for delay-sensitive applications, such as Voice over Wireless IP. IEEE 802.1p defines 8 different classes of service (including one dedicated to voice) for traffic on layer-2 wired Ethernet. The ITU-T G.hn standard, which provides a way to create a high-speed (up to 1 gigabit per second) Local area network using existing home wiring (power lines, phone lines and coaxial cables). G.hn provides QoS by means of "Contention-Free Transmission Opportunities" (CFTXOPs) which are allocated to flows (such as a VoIP call) which require QoS and which have negotiated a "contract" with the network controllers.
38
Voice over IP
39
Emergency calls
The nature of IP makes it difficult to locate network users geographically. Emergency calls, therefore, cannot easily be routed to a nearby call center. Sometimes, VoIP systems may route emergency calls to a non-emergency phone line at the intended department; in the United States, at least one major police department has strongly objected to this practice as potentially endangering the public.[19] [20] A fixed line phone has a direct relationship between a telephone number and a physical location. If an emergency call comes from that number, then the physical location is known. In the IP world, it is not so simple. A broadband provider may know the location where the wires terminate, but this does not necessarily allow the mapping of an IP address to that location. IP addresses are often dynamically assigned, so the ISP may allocate an address for online access, or at the time a broadband router is engaged. The ISP recognizes individual IP addresses, but does not necessarily know to which physical location it corresponds. The broadband service provider knows the physical location, but is not necessarily tracking the IP addresses in use.[20] There are more complications since IP allows a great deal of mobility. For example, a broadband connection can be used to dial a virtual private network that is employer-owned. When this is done, the IP address being used will belong to the range of the employer, rather than the address of the ISP, so this could be many kilometres away or even in another country. To provide another example: if mobile data is used, e.g., a 3G mobile handset or USB wireless broadband adapter, then the IP address has no relationship with any physical location, since a mobile user could be anywhere that there is network coverage, even roaming via another cellular company. In short, there is no relationship between IP address and physical location, so the address itself reveals no useful information for the emergency services. At the VoIP level, a phone or gateway may identify itself with a SIP registrar by using a username and password. So in this case, the Internet Telephony Service Provider (ITSP) knows that a particular user is online, and can relate a specific telephone number to the user. However, it does not recognize how that IP traffic was engaged. Since the IP address itself does not necessarily provide location information presently, today a "best efforts" approach is to use an available database to find that user and the physical address the user chose to associate with that telephone numberclearly an imperfect solution.[20] VoIP Enhanced 911 (E911) is a method by which VoIP providers in the United States support emergency services. The VoIP E911 emergency-calling system associates a physical address with the calling party's telephone number as required by the Wireless Communications and Public Safety Act of 1999. All VoIP providers that provide access to the public switched telephone network are required to implement E911,[20] a service for which the subscriber may be charged. Participation in E911 is not required and customers may opt-out of E911 service.[20] One shortcoming of VoIP E911 is that the emergency system is based on a static table lookup. Unlike in cellular phones, where the location of an E911 call can be traced using Assisted GPS or other methods, the VoIP E911 information is only accurate so long as subscribers are diligent in keeping their emergency address information up-to-date. In the United States, the Wireless Communications and Public Safety Act of 1999 leaves the burden of responsibility upon the subscribers and not the service providers to keep their emergency information up to date.[20]
Lack of redundancy
With the current separation of the Internet and the PSTN, a certain amount of redundancy is provided. An Internet outage does not necessarily mean that a voice communication outage will occur simultaneously, allowing individuals to call for emergency services and many businesses to continue to operate normally. In situations where telephone services become completely reliant on the Internet infrastructure, a single-point failure can isolate communities from all communication, including Enhanced 911 and equivalent services in other locales. However, the internet as designed by DARPA in the early 1980s was specifically designed to be fault tolerant under adverse conditions. Even during the 9/11 attacks on the World Trade Centers the internet routed data around the failed nodes that were housed
Voice over IP in or near the towers. So single point failures while possible in some geographic areas are not the norm for the internet as a whole.
40
Number portability
Local number portability (LNP) and Mobile number portability (MNP) also impact VoIP business. In November 2007, the Federal Communications Commission in the United States released an order extending number portability obligations to interconnected VoIP providers and carriers that support VoIP providers.[21] Number portability is a service that allows a subscriber to select a new telephone carrier without requiring a new number to be issued. Typically, it is the responsibility of the former carrier to "map" the old number to the undisclosed number assigned by the new carrier. This is achieved by maintaining a database of numbers. A dialed number is initially received by the original carrier and quickly rerouted to the new carrier. Multiple porting references must be maintained even if the subscriber returns to the original carrier. The FCC mandates carrier compliance with these consumer-protection stipulations. A voice call originating in the VoIP environment also faces challenges to reach its destination if the number is routed to a mobile phone number on a traditional mobile carrier. VoIP has been identified in the past as a Least Cost Routing (LCR) system, which is based on checking the destination of each telephone call as it is made, and then sending the call via the network that will cost the customer the least.[22] This rating is subject to some debate given the complexity of call routing created by number portability. With GSM number portability now in place, LCR providers can no longer rely on using the network root prefix to determine how to route a call. Instead, they must now determine the actual network of every number before routing the call. Therefore, VoIP solutions also need to handle MNP when routing a voice call. In countries without a central database, like the UK, it might be necessary to query the GSM network about which home network a mobile phone number belongs to. As the popularity of VoIP increases in the enterprise markets because of least cost routing options, it needs to provide a certain level of reliability when handling calls. MNP checks are important to assure that this quality of service is met. By handling MNP lookups before routing a call and by assuring that the voice call will actually work, VoIP service providers are able to offer business subscribers the level of reliability they require.
PSTN integration
E.164 is a global FGFnumbering standard for both the PSTN and PLMN. Most VoIP implementations support E.164 to allow calls to be routed to and from VoIP subscribers and the PSTN/PLMN.[23] VoIP implementations can also allow other identification techniques to be used. For example, Skype allows subscribers to choose "Skype names"[24] (usernames) whereas SIP implementations can use URIs[25] similar to email addresses. Often VoIP implementations employ methods of translating non-E.164 identifiers to E.164 numbers and vice-versa, such as the Skype-In service provided by Skype[26] and the ENUM service in IMS and SIP.[27] Echo can also be an issue for PSTN integration.[28] Common causes of echo include impedance mismatches in analog circuitry and acoustic coupling of the transmit and receive signal at the receiving end.
Voice over IP
41
Security
VoIP telephone systems are susceptible to attacks as are any internet-connected devices. This means that hackers who know about these vulnerabilities (such as insecure passwords) can institute denial-of-service attacks, harvest customer data, record conversations and break into voice mailboxes.[29] [30] [31] Another challenge is routing VoIP traffic through firewalls and network address translators. Private Session Border Controllers are used along with firewalls to enable VoIP calls to and from protected networks. For example, Skype uses a proprietary protocol to route calls through other Skype peers on the network, allowing it to traverse symmetric NATs and firewalls. Other methods to traverse NATs involve using protocols such as STUN or Interactive Connectivity Establishment (ICE). Many consumer VoIP solutions do not support encryption, although having a secure phone is much easier to implement with VoIP than traditional phone lines. As a result, it is relatively easy to eavesdrop on VoIP calls and even change their content.[32] An attacker with a packet sniffer could intercept your VoIP calls if you are not on a secure VLAN. However, physical security of the switches within an enterprise and the facility security provided by ISPs make packet capture less of a problem than originally foreseen. Further research has shown that tapping into a fiber optic network without detection is difficult if not impossible. This means that once a voice packet is within the internet backbone it is relatively safe from interception. There are open source solutions, such as Wireshark, that facilitate sniffing of VoIP conversations. A modicum of security is afforded by patented audio codecs in proprietary implementations that are not easily available for open source applications; however, such security through obscurity has not proven effective in other fields. Some vendors also use compression, which may make eavesdropping more difficult. However, real security requires encryption and cryptographic authentication which are not widely supported at a consumer level. The existing security standard Secure Real-time Transport Protocol (SRTP) and the new ZRTP protocol are available on Analog Telephone Adapters (ATAs) as well as various softphones. It is possible to use IPsec to secure P2P VoIP by using opportunistic encryption. Skype does not use SRTP, but uses encryption which is transparent to the Skype provider. In 2005, Skype invited a researcher, Dr Tom Berson, to assess the security of the Skype software, and his conclusions are available in a published report.[33]
Securing VoIP
To prevent the above security concerns government and military organizations are using Voice over Secure IP (VoSIP), Secure Voice over IP (SVoIP), and Secure Voice over Secure IP (SVoSIP) to protect confidential and classified VoIP communications.[34] Secure Voice over IP is accomplished by encrypting VoIP with Type 1 encryption. Secure Voice over Secure IP is accomplished by using Type 1 encryption on a classified network, like SIPRNet.[35] [36] [37] [38] [39] Public Secure VoIP is also available with free GNU programs.[40]
Caller ID
Caller ID support among VoIP providers varies, but is provided by the majority of VoIP providers. Many VoIP carriers allow callers to configure arbitrary Caller ID information, thus permitting spoofing attacks.[41] Business grade VoIP equipment and software often makes it easy to modify caller ID information, providing many businesses great flexibility. The Truth in Caller ID Act has been in preparation in the US Congress since 2006, but as of January 2009 still has not been enacted. This bill proposes to make it a crime in the United States to "knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value..."[42]
Voice over IP
42
Fax handling
Support for sending faxes over VoIP implementations is still limited. The existing voice codecs are not designed for fax transmission; they are designed to digitize an analog representation of a human voice efficiently. However, the inefficiency of digitizing an analog representation (modem signal) of a digital representation (a document image) of analog data (an original document) more than negates any bandwidth advantage of VoIP. In other words, the fax "sounds" simply do not fit in the VoIP channel. An alternative IP-based solution for delivering fax-over-IP called T.38 is available. Sending faxes using VoIP is sometimes referred to as FoIP, or Fax over IP. [44] The T.38 protocol is designed to compensate for the differences between traditional packet-less communications over analog lines and packet based transmissions which are the basis for IP communications. The fax machine could be a traditional fax machine connected to the PSTN, or an ATA box (or similar). It could be a fax machine with an RJ-45 connector plugged straight into an IP network, or it could be a computer pretending to be a fax machine.[45] Originally, T.38 was designed to use UDP and TCP transmission methods across an IP network. TCP is better suited for use between two IP devices. However, older fax machines, connected to an analog system, benefit from UDP near real-time characteristics due to the "no recovery rule" when a UDP packet is lost or an error occurs during transmission.[46] UDP transmissions are preferred as they do not require testing for dropped packets and as such since each T.38 packet transmission includes a majority of the data sent in the prior packet, a T.38 termination point has a higher degree of success in re-assembling the fax transmission back into its original form for interpretation by the end device. This in an attempt to overcome the obstacles of simulating real time transmissions using packet based protocol.[47] There have been updated versions of T.30 to resolve the fax over IP issues, which is the core fax protocol. Some newer high end fax machines have T.38 built-in capabilities which allow the user to plug right into the network and transmit/receive faxes in native T.38 like the Ricoh 4410NF Fax Machine.[48] A unique feature of T.38 is that each packet contains a portion of the main data sent in the previous packet. With T.38, two successive lost packets are needed to actually lose any data. The data you lose will only be a small piece, but with the right settings and error correction mode, there is an increased likelihood that you will receive enough of the transmission to satisfy the requirements of the fax machine for output of the sent document.
Voice over IP
43
Legal issues
As the popularity of VoIP grows, governments are becoming more interested in regulating VoIP in a manner similar to PSTN services.[49] Another legal issue that the US Congress is debating concerns changes to the Foreign Intelligence Surveillance Act. The issue in question is calls between Americans and foreigners. The National Security Agency (NSA) is not authorized to tap Americans' conversations without a warrantbut the Internet, and specifically VoIP does not draw as clear a line to the location of a caller or a call's recipient as the traditional phone system does. As VoIP's low cost and flexibility convinces more and more organizations to adopt the technology, the surveillance for law enforcement agencies becomes more difficult. VoIP technology has also increased security concerns because VoIP and similar technologies have made it more difficult for the government to determine where a target is physically located when communications are being intercepted, and that creates a whole set of new legal challenges.[50] In the US, the Federal Communications Commission now requires all interconnected VoIP service providers to comply with requirements comparable to those for traditional telecommunications service providers. VoIP operators in the US are required to support local number portability; make service accessible to people with disabilities; pay regulatory fees, universal service contributions, and other mandated payments; and enable law enforcement authorities to conduct surveillance pursuant to the Communications Assistance for Law Enforcement Act (CALEA). "Interconnected" VoIP operators also must provide Enhanced 911 service, disclose any limitations on their E-911 functionality to their consumers, and obtain affirmative acknowledgements of these disclosures from all consumers.[51] VoIP operators also receive the benefit of certain US telecommunications regulations, including an entitlement to interconnection and exchange of traffic with incumbent local exchange carriers via wholesale carriers. Providers of "nomadic" VoIP servicethose who are unable to determine the location of their usersare exempt from state telecommunications regulation.[52] Throughout the developing world, countries where regulation is weak or captured by the dominant operator, restrictions on the use of VoIP are imposed, including in Panama where VoIP is taxed, Guyana where VoIP is prohibited and India where its retail commercial sales is allowed but only for long distance service.[53] In Ethiopia, where the government is monopolizing telecommunication service, it is a criminal offense to offer services using VoIP. The country has installed firewalls to prevent international calls being made using VoIP. These measures were taken after the popularity of VoIP reduced the income generated by the state owned telecommunication company. In the European Union, the treatment of VoIP service providers is a decision for each Member State's national telecoms regulator, which must use competition law to define relevant national markets and then determine whether any service provider on those national markets has "significant market power" (and so should be subject to certain obligations). A general distinction is usually made between VoIP services that function over managed networks (via broadband connections) and VoIP services that function over unmanaged networks (essentially, the Internet). VoIP services that function over managed networks are often considered to be a viable substitute for PSTN telephone services (despite the problems of power outages and lack of geographical information); as a result, major operators that provide these services (in practice, incumbent operators) may find themselves bound by obligations of price control or accounting separation. VoIP services that function over unmanaged networks are often considered to be too poor in quality to be a viable substitute for PSTN services; as a result, they may be provided without any specific obligations, even if a service provider has "significant market power". The relevant EU Directive is not clearly drafted concerning obligations which can exist independently of market power (e.g., the obligation to offer access to emergency calls), and it is impossible to say definitively whether VoIP service providers of either type are bound by them. A review of the EU Directive is under way and should be complete by 2007.
Voice over IP In India, it is legal to use VoIP, but it is illegal to have VoIP gateways inside India. This effectively means that people who have PCs can use them to make a VoIP call to any number, but if the remote side is a normal phone, the gateway that converts the VoIP call to a POTS call should not be inside India. In the UAE and Oman it is illegal to use any form of VoIP, to the extent that Web sites of Skype and Gizmo5 are blocked. Providing or using VoIP services is illegal in Oman. Those who violate the law stand to be fined 50,000 Omani Rial (about 130,317 US dollars) or spend two years in jail or both. In 2009, police in Oman have raided 121 internet cafes throughout the country and arrested 212 people for using/providing VoIP services. In the Republic of Korea, only providers registered with the government are authorized to offer VoIP services. Unlike many VoIP providers, most of whom offer flat rates, Korean VoIP services are generally metered and charged at rates similar to terrestrial calling. Foreign VoIP providers encounter high barriers to government registration. This issue came to a head in 2006 when Internet service providers providing personal Internet services by contract to United States Forces Korea members residing on USFK bases threatened to block off access to VoIP services used by USFK members as an economical way to keep in contact with their families in the United States, on the grounds that the service members' VoIP providers were not registered. A compromise was reached between USFK and Korean telecommunications officials in January 2007, wherein USFK service members arriving in Korea before June 1, 2007, and subscribing to the ISP services provided on base may continue to use their US-based VoIP subscription, but later arrivals must use a Korean-based VoIP provider, which by contract will offer pricing similar to the flat rates offered by US VoIP providers.[54]
44
Historical milestones
1974 The Institute of Electrical and Electronic Engineers (IEEE) published a paper titled "A Protocol for Packet Network Interconnection."[55] 1981 IPv4 is described in RFC 791. 1985 The National Science Foundation commissions the creation of NSFNET.[56] 1994- Alon Cohen and Lior Haramaty invent Voice over IP.[57] 1995 VocalTec releases the first commercial Internet phone software.[58] [59] Beginning in 1995, Intel, Microsoft and Radvision initiated standardization activities for VoIP communications system.[60] 1996 ITU-T begins development of standards for the transmission and signaling of voice communications over Internet Protocol networks with the H.323 standard.[61] US telecommunication companies petition the US Congress to ban Internet phone technology.[62] 1997 Level 3 began development of its first softswitch, a term they coined in 1998.[63] 1999 The Session Initiation Protocol (SIP) specification RFC 2543 is released.[64] Mark Spencer of Digium develops the first open source private branch exchange (PBX) software (Asterisk).[65] 2004 Commercial VoIP service providers proliferate.
Voice over IP
45
Pronunciation
The acronym VoIP has been pronounced variably since the inception of the term. Apart from spelling out the acronym letter by letter, v'''p (vee-oh-eye-pee), there are three likely possible pronunciations: v''p (vo-eye-pee) and v'ip (vo-ipp), have been used, but generally, the single syllable vy'p (voyp, as in voice) may be the most common within the industry.[66]
References
[1] "Voice over Internet Protocol. Definition and Overview" (http:/ / www. iec. org/ online/ tutorials/ int_tele/ index. asp). International Engineering Consortium. 2007. . Retrieved 2009-04-27. [2] "IP Telephony Vs VoIP" (http:/ / www. networkstraining. com). . Retrieved 27 April 2011. [3] Booth, C (2010). "Chapter 2: IP Phones, Software VoIP, and Integrated and Mobile VoIP". Library Technology Reports 46 (5): 1119. [4] "Carriers look to IP for backhaul" (http:/ / www. commsdesign. com/ showArticle. jhtml;jsessionid=YBQXDJILLQX0IQSNDLPSKH0CJUNN2JVN?articleID=159907138). Telecommunications Online. January 21, 2009. . Retrieved 2009-01-21. [5] "Mobile's IP challenge" (http:/ / www. totaltele. com/ View. aspx?ID=77588& t=4). Total Telecom. December 8, 2005. . Retrieved 2009-01-21. [6] Michael Dosch and Steve Church. "VoIP In The Broadcast Studio" (http:/ / www. axiaaudio. com/ tech/ voip/ default. htm). Axia Audio. . Retrieved 2011-06-21. [7] Callahan, Renee (December 9, 2008). "Businesses Move To Voice-Over-IP" (http:/ / www. forbes. com/ 2008/ 12/ 09/ skype-vonage-ringcentral_leadership_clayton_in_rc_1209claytonchristensen_inl. html). forbes.com. . Retrieved 2009-03-03. [8] Korzeniowski, Peter (January 8, 2009). "Three Technologies You Need In 2009" (http:/ / www. forbes. com/ 2009/ 01/ 08/ small-business-voip-ent-tech-cx_bm_0108bmightytech09. html/ ). Forbes.com. . Retrieved 2009-03-02. [9] "Skype For Business" (http:/ / www. skype. com/ business/ allfeatures/ 3skypephone/ ). skype.com. . Retrieved 2009-03-16. [10] William Jackson (2009-05-27). "SSA goes big on VOIP" (http:/ / gcn. com/ Articles/ 2009/ 06/ 01/ SSA-VOIP-implementation. aspx?s=gcndaily_280509& Page=1). Government Computer News. . Retrieved 2009-05-28. [11] "Social Security to Build "World's Largest VOIP"" (http:/ / www. govtech. com/ gt/ 275677). Government Technology. . Retrieved 2009-05-29. [12] FCC.gov (http:/ / www. fcc. gov/ voip/ ), What are some advantages of VOIP? [13] "Quality of Service for Voice over IP" (http:/ / www. cisco. com/ en/ US/ docs/ ios/ solutions_docs/ qos_solutions/ QoSVoIP/ QoSVoIP. html). . Retrieved May 3, 2011. [14] Prabhakar, G.; Rastogi, R.,& Thotton, M (2005). "OSS Architecture & Requirements for VoIP Networks". Bell Labs Technical Journal 10 (1): 3145. [15] "Quality of Service for Voice over IP" (http:/ / www. cisco. com/ en/ US/ docs/ ios/ solutions_docs/ qos_solutions/ QoSVoIP/ QoSVoIP. html#wp1029054). . Retrieved May 3, 2011. [16] VOIP Vulnerability over Internet Protocol (http:/ / www. continuitycentral. com/ feature074. htm) [17] IEEE Multipath routing with adaptive playback scheduling for Voice over IP in Service Overlay Networks (Abstract) (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=4520089) [18] ICT Regulation Tool Kit 4.4 VOIP Regulatory Issues Universal Service (http:/ / www. ictregulationtoolkit. org/ en/ Section. 3083. html) [19] Letter from the City of New York to the Federal Communications Commission (http:/ / gullfoss2. fcc. gov/ prod/ ecfs/ retrieve. cgi?native_or_pdf=pdf& id_document=6517587651) [20] "FCC Consumer Advisory VoIP and 911 Service" (http:/ / www. fcc. gov/ cgb/ consumerfacts/ voip911. pdf). . Retrieved May 2, 2011. [21] Keeping your telephone number when you change your service provider FCC (http:/ / www. fcc. gov/ cgb/ consumerfacts/ numbport. html) [22] VoIpservice.com (http:/ / www. voipservice. com/ sip-trunking) [23] "RFC 3824 Using E.164 numbers with the Session Initiation Protocol (SIP)" (http:/ / www. packetizer. com/ rfc/ rfc3824/ ). The Internet Society. June 1, 2004. . Retrieved 2009-01-21. [24] "Create a Skype Name" (http:/ / www. skype. com/ help/ guides/ createskypename_windows/ ). Skype. . Retrieved 2009-01-21. [25] "RFC 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)" (http:/ / www. packetizer. com/ rfc/ rfc3969/ ). The Internet Society. December 1, 2004. . Retrieved 2009-01-21. [26] "Your personal online number" (http:/ / www. skype. com/ allfeatures/ onlinenumber/ ). Skype. . Retrieved 2009-01-21. [27] "Application-level Network Interoperability and the Evolution of IMS" (http:/ / ipcommunications. tmcnet. com/ hot-topics/ MCP/ articles/ 1311-application-level-network-interoperability-the-evolution-ims. htm). TMCnet.com. May 24, 2006. . Retrieved 2009-01-21. [28] Packetcable Implementation P557 Jeff Riddel ISBN 1587051818 Google Books Preview (http:/ / books. google. com/ books?id=8CNBbrxytcAC& pg=PA557& lpg=PA557& dq=PSTN+ gateway+ VOIP+ impedance+ mismatch)
Voice over IP
[29] Taub, Eric (April 2, 2008). "VOIP System Security: Time to Worry, or Maybe Not" (http:/ / bits. blogs. nytimes. com/ 2008/ 04/ 02/ voip-system-security-time-to-worry-or-maybe-not/ ?scp=4& sq=voip& st=cse/ ). New York Times. . Retrieved 2009-03-02. [30] Stanton, Ray (Secure VoIP- An Achievable Goal). Computer Fraud & Security 4: 1114. doi:10.1016/S1361-3723(06)70333-5. [31] Stanton, R. (2006). "Secure VoIP- an achievable goal". Computer Fraud & Security 4: 1114. doi:10.1016/S1361-3723(06)70333-5. [32] "Examining Two Well-Known Attacks on VOIP" (http:/ / www. circleid. com/ posts/ examining_two_well_known_attacks_on_voip1/ ). CircleID. . Retrieved 2006-04-05. [33] Skype.com (http:/ / download. skype. com/ share/ security/ 2005-031 security evaluation. pdf), "Skype Security Evaluation", Tom Berson/Anagram Laboratories [34] Disa.mil (http:/ / iase. disa. mil/ stigs/ stig/ VoIP-STIG-V2R2. pdf), Internet Protocol Telephony & Voice over Internet Protocol Security Technical Implementation Guide [35] IJCSNS.org (http:/ / paper. ijcsns. org/ 07_book/ 200706/ 20070610. pdf), Secure Voice-over-IP [36] Sans.org (http:/ / www. sans. org/ reading_room/ whitepapers/ voip/ secure_voice_over_ip_322), SANS Institute InfoSec Reading Room [37] JHU.edu (http:/ / www. clsp. jhu. edu/ ~cwhite/ papers/ asilo_04_LossConceal_final. pdf), Packet Loss Concealment in a Secure Voice over IP Environment [38] GDC4S.com (http:/ / www. gdc4s. com/ documents/ D-VIPER-14-1007_p11. pdf), State-of-the-art voice over IP encryptor [39] Networkworld.com (http:/ / www. networkworld. com/ news/ 2009/ 041609-cellcrypt-secure-voip-heading-to. html), Cellcrypt secure VOIP heading to BlackBerry. [40] Freesorftwaremagazine.com (http:/ / www. freesoftwaremagazine. com/ columns/ secure_voip_calling_free_software_right_to_privacy), Secure VOIP calling, free software, and the right to privacy [41] VOIPSA.org (http:/ / voipsa. org/ blog/ 2006/ 09/ 29/ hello-mom-im-a-fake/ ), Blog: "Hello Mom, I'm a Fake!" (Telespoof and Fakecaller). [42] Govtrack.us (http:/ / www. govtrack. us/ congress/ billtext. xpd?bill=s111-30), "Truth in Caller ID Act". [43] Oldphoneworks.com (http:/ / www. oldphoneworks. com/ antique-phone-parts/ parts-and-pieces/ pulse-to-tone-converters/ ) [44] Voip-Info.org (http:/ / www. voip-info. org/ wiki/ view/ FoIP), "FoIP". [45] Soft-Switch.org (http:/ / soft-switch. org/ foip. html), Faxing over IP networks [46] Umass.edu (http:/ / www-net. cs. umass. edu/ kurose/ transport/ UDP. html), UMass Discussion on UDP transmission Characteristics. [47] Faqs.org (http:/ / www. faqs. org/ rfcs/ rfc3362. html), RFC 3362-T.38 [48] FaxSuperstore.com (http:/ / www. faxsuperstore. com/ ricoh-4410nf. html), Ricoh 4410NF [49] "Global VOIP Policy Status Matrix" (http:/ / www. ipall. org/ matrix/ ). Global IP Alliance (http:/ / www. ipall. org). . Retrieved 2006-11-23. [50] Greenberg, Andy (May 15, 2008). "The State Of Cybersecurity Wiretapping's Fuzzy Future" (http:/ / www. forbes. com/ 2008/ 05/ 15/ wiretapping-voip-lichtblau-tech-security08-cx_ag_0515wiretap. html/ ). www.forbes.com. . Retrieved 2009-03-02. [51] GPO.gov (http:/ / www. access. gpo. gov/ nara/ cfr/ waisidx_07/ 47cfr9_07. html), 47 C.F.R. pt. 9 (2007) [52] FCC.gov (http:/ / www. fcc. gov/ voip/ ) [53] Proenza, Francisco J.. "The Road to Broadband Development in Developing Countries is through Competition Driven by Wireless and VOIP" (http:/ / www. e-forall. org/ pdf/ Wireless& VOIP_10July2006. pdf) (PDF). . Retrieved 2008-04-07. [54] Stripes.com (http:/ / www. stripes. com/ article. asp?section=104& article=41826& archive=true), Stars and Stripes: USFK deal keeps VoIP access for troops [55] Vinton G. Cerf, Robert E. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. 22, No. 5, May 1974, pp. 637648. [56] "The Launch of NSFNET" (http:/ / www. nsf. gov/ about/ history/ nsf0050/ internet/ launch. htm). The National Science Foundation. . Retrieved 2009-01-21. [57] US 5,825,771 (http:/ / worldwide. espacenet. com/ textdoc?DB=EPODOC& IDX=US5,825,771), filed on November 10, 1994 [58] Keating, Tom. "Internet Phone Release 4" (http:/ / blog. tmcnet. com/ blog/ tom-keating/ docs/ cti-buyers-guide-1996. pdf) (PDF). Computer Telephony Interaction Magazine. . Retrieved 2007-11-07. [59] "The 10 that Established VOIP (Part 1: VocalTec)" (http:/ / www. ilocus. com/ 2007/ 07/ the_10_that_established_voip_p_2. html). iLocus. . Retrieved 2009-01-21. [60] The free Library RADVision and Intel Target Compatibility Between RADVision's H.323/320 Videoconferencing Gateway And Intel's Business Video Conferencing And TeamStation Products. (http:/ / www. thefreelibrary. com/ RADVision+ and+ Intel+ Target+ Compatibility+ Between+ RADVision's+ . . . -a019467970) June 2, 1997 VoiP Developer Solutions (http:/ / www. radvision. com/ Developer-Solutions/ ) [61] "H.323 Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service" (http:/ / www. itu. int/ rec/ T-REC-H. 323-199611-S/ en). ITU-T. . Retrieved 2009-01-21. [62] "RFC 2235" (http:/ / www. faqs. org/ rfcs/ rfc2235. html). R. Zakon. . Retrieved 2009-01-21. [63] "The 10 that Established VOIP (Part 2: Level 3)" (http:/ / www. ilocus. com/ 2007/ 07/ the_10_that_established_voip_p_1. html). iLocus. July 13, 2007. . Retrieved 2007-11-07. [64] "RFC 2543, SIP: Session Initiation Protocol" (http:/ / www. ietf. org/ rfc/ rfc2543. txt). Handley,Schulzrinne,Schooler,Rosenberg. . Retrieved 2009-01-21. [65] "What is Asterisk" (http:/ / www. asterisk. org/ about). Asterisk.org. . Retrieved 2009-01-21. [66] Voip | Define Voip at Dictionary.com (http:/ / dictionary. reference. com/ browse/ voip). Dictionary.com. Retrieved 2011-07-15.
46
Voice over IP
47
External links
Voice over IP (http://www.dmoz.org/Business/Telecommunications/Services/VoIP/) at the Open Directory Project
History
SIP was originally designed by Henning Schulzrinne and Mark Handley in 1996. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in cellular systems. The latest version of the specification is RFC 3261 from the IETF Network Working Group published in June 2002.[3] The free software community started to provide more and more of the SIP technology required to build both end points as well as proxy and registrar servers leading to a commodification of the technology, which has accelerated global adoption. As an example, the open source community at SIPfoundry actively develops a variety of SIP stacks, client applications and SDKs, in addition to entire private branch exchange (IP PBX) solutions that compete in the market against mostly proprietary IP PBX implementations from established vendors. The National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division provides a public domain implementation of the JAVA Standard for SIP[4] which serves as a reference implementation for the standard. The stack can work in proxy server or user agent scenarios and has been used in numerous commercial and research projects. It supports RFC 3261 in full and a number of extension RFCs including RFC 3265 (Subscribe / Notify) and RFC 3262 (Provisional Reliable Responses) etc.
Protocol design
SIP employs design elements similar to the HTTP request/response transaction model.[5] Each transaction consists of a client request that invokes a particular method or function on the server and at least one response. SIP reuses most of the header fields, encoding rules and status codes of HTTP, providing a readable text-based format. SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session. SIP clients typically use TCP or UDP on port numbers 5060 and/or 5061 to connect to SIP servers and other SIP endpoints. Port 5060 is commonly used for non-encrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS). SIP is primarily used in setting up and tearing down voice or video calls. It also allows modification of existing calls. The modification can involve changing addresses or ports, inviting more participants, and adding or deleting media streams. SIP has also found applications in messaging applications, such as instant messaging, and event subscription and notification. There are a large number of
Session Initiation Protocol SIP-related Internet Engineering Task Force (IETF) documents that define behavior for such applications. The voice and video stream communications in SIP applications are carried over another application protocol, the Real-time Transport Protocol (RTP). Parameters (port numbers, protocols, codecs) for these media streams are defined and negotiated using the Session Description Protocol (SDP) which is transported in the SIP packet body. A motivating goal for SIP was to provide a signaling and call setup protocol for IP-based communications that can support a superset of the call processing functions and features present in the public switched telephone network (PSTN). SIP by itself does not define these features; rather, its focus is call-setup and signaling. The features that permit familiar telephone-like operations: dialing a number, causing a phone to ring, hearing ringback tones or a busy signal - are performed by proxy servers and user agents. Implementation and terminology are different in the SIP world but to the end-user, the behavior is similar. SIP-enabled telephony networks can also implement many of the more advanced call processing features present in Signaling System 7 (SS7), though the two protocols themselves are very different. SS7 is a centralized protocol, characterized by a complex central network architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer protocol, thus it requires only a simple (and thus scalable) core network with intelligence distributed to the network edge, embedded in endpoints (terminating devices built in either hardware or software). SIP features are implemented in the communicating endpoints (i.e. at the edge of the network) contrary to traditional SS7 features, which are implemented in the network. Although several other VoIP signaling protocols exist (such as BICC, H.323, MGCP, MEGACO), SIP is distinguished by its proponents for having roots in the IP community rather than the telecommunications industry. SIP has been standardized and governed primarily by the IETF, while other protocols, such as H.323, have traditionally been associated with the International Telecommunication Union (ITU). The first proposed standard version (SIP 1.0) was defined by RFC 2543. This version of the protocol was further refined to version 2.0 and clarified in RFC 3261, although some implementations are still relying on the older definitions.
48
Network elements
A SIP user agent (UA) is a logical network end-point used to create or receive SIP messages and thereby manage a SIP session. A SIP UA can perform the role of a User Agent Client (UAC), which sends SIP requests, and the User Agent Server (UAS), which receives the requests and returns a SIP response. These roles of UAC and UAS only last for the duration of a SIP transaction.[6] A SIP phone is a SIP user agent that provides the traditional call functions of a telephone, such as dial, answer, reject, hold/unhold, and call transfer.[7] [8] SIP phones may be implemented as a hardware device or as a softphone. As vendors increasingly implement SIP as a standard telephony platform, often driven by 4G efforts, the distinction between hardware-based and software-based SIP phones is being blurred and SIP elements are implemented in the basic firmware functions of many IP-capable devices. Examples are devices from Nokia and Research in Motion.[9] Each resource of a SIP network, such as a User Agent or a voicemail box, is identified by a Uniform Resource Identifier (URI), based on the general standard syntax[10] also used in Web services and e-mail. A typical SIP URI is of the form: sip:username:password@host:port. The URI scheme used for SIP is sip:. If secure transmission is required, the scheme sips: is used and SIP messages must be transported over Transport Layer Security (TLS).[6] In SIP, as in HTTP, the user agent may identify itself using a message header field 'User-Agent', containing a text description of the software/hardware/product involved. The User-Agent field is sent in request messages, which means that the receiving SIP server can see this information. SIP network elements sometimes store this information,[11] and it can be useful in diagnosing SIP compatibility problems.
Session Initiation Protocol SIP also defines server network elements. Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is often impractical for a public service. RFC 3261 defines these server elements. Proxy server An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Registrar A server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles which registers one or more IP addresses to a certain SIP URI, indicated by the sip: scheme, although other protocol schemes are possible (such as tel:). More than one user agent can register at the same URI, with the result that all registered user agents will receive a call to the SIP URI. SIP registrars are logical elements, and are commonly co-located with SIP proxies. But it is also possible and often good for network scalability to place this location service with a redirect server. Redirect server A user agent server that generates 3xx (Redirection) responses to requests it receives, directing the client to contact an alternate set of URIs. The redirect server allows proxy servers to direct SIP session invitations to external domains. Other SIP-related network elements include. Session border controllers (SBC) Serve as middle boxes between UA and SIP server for various types of functions, including network topology hiding, and assistance in NAT traversal. gateways Devices that exist at the edge between a SIP network and other networks (as a phone network).
49
SIP messages
SIP is a text-based protocol with syntax similar to that of HTTP. There are two different types of SIP messages: requests and responses. The first line of a request has a method, defining the nature of the request, and a Request-URI, indicating where the request should be sent.[12] The first line of a response has a response code. For SIP requests, RFC 3261 defines the following methods:[13] REGISTER: Used by a UA to indicate its current IP address and the URLs for which it would like to receive calls. INVITE: Used to establish a media session between user agents. ACK: Confirms reliable message exchanges. CANCEL: Terminates a pending request. BYE: Terminates a session between two users in a conference. OPTIONS: Requests information about the capabilities of a caller, without setting up a call. PRACK (Provisional Response Acknowledgement): PRACK improves network reliability by adding an acknowledgement system to the provisional Responses (1xx). PRACK is sent in response to provisional response (1xx). The SIP response types defined in RFC 3261 fall in one of the following categories:[14]
Session Initiation Protocol Provisional (1xx): Request received and being processed. Success (2xx): The action was successfully received, understood, and accepted. Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request. Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server. Server Error (5xx): The server failed to fulfill an apparently valid request. Global Failure (6xx): The request cannot be fulfilled at any server.
50
Transactions
SIP makes use of transactions to control the exchanges between participants and deliver messages reliably. The transactions maintain an internal state and make use of timers. Client Transactions send requests and Server Transactions respond to those requests with one-or-more responses. The responses may include zero-or-more Provisional (1xx) responses and one-or-more final (2xx-6xx) responses. Transactions are further categorized as either Invite or Non-Invite. Invite transactions differ in that they can establish a long-running conversation, referred to as a Dialog in SIP, and so include an acknowledgment (ACK) of any non-failing final response (e.g. 200 OK). Because of these transactional mechanisms, SIP can make use of un-reliable transports such as User Datagram Protocol (UDP).
If we take the above example, User1s UAC uses an Invite Client Transaction to send the initial INVITE (1) message. If no response is received after a timer controlled wait period the UAC may have chosen to terminate the transaction or retransmit the INVITE. However, once a response was received, User1 was confident the INVITE was delivered reliably. User1s UAC then must acknowledge the response. On delivery of the ACK (2) both sides of the transaction are complete. And in this case, a Dialog may have been established.[15]
51
Conformance testing
TTCN-3 test specification language is used for the purposes of specifying conformance tests for SIP implementations. SIP test suite is developed by a Specialist Task Force at ETSI (STF 196).[16] The SIP developer community meets regularly at the SIP Forum SIPit [17] events to test interoperability and test implementations of new RFCs.
Applications
The market for consumer SIP devices continues to expand, there are many devices such as SIP Terminal Adapters, SIP Gateways, and SIP Trunking services providing replacements for ISDN telephone lines. Many VoIP phone companies allow customers to use their own SIP devices, such as SIP-capable telephone sets, or softphones. SIP-enabled video surveillance cameras can make calls to alert the owner or operator that an event has occurred, for example to notify that motion has been detected out-of-hours in a protected area. SIP is used in audio over IP for broadcasting applications where it provides an interoperable means for audio interfaces from different manufacturers to make connections with one another.[18]
SIP-ISUP interworking
SIP-I, or the Session Initiation Protocol with encapsulated ISUP, is a protocol used to create, modify, and terminate communication sessions based on ISUP using SIP and IP networks. Services using SIP-I include voice, video telephony, fax and data. SIP-I and SIP-T[19] are two protocols with similar features, notably to allow ISUP messages to be transported over SIP networks. This preserves all of the detail available in the ISUP header, which is important as there are many country-specific variants of ISUP that have been implemented over the last 30 years, and it is not always possible to express all of the same detail using a native SIP message. SIP-I was defined by the ITU-T, where SIP-T was defined via the IETF RFC route.[20]
References
[1] RFC 4168, The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP), IETF, The Internet Society (2005) [2] Johnston, Alan B. (2004). SIP: Understanding the Session Initiation Protocol, Second Edition. Artech House. ISBN1580531687. [3] "SIP core working group charter" (http:/ / www. ietf. org/ dyn/ wg/ charter/ sipcore-charter. html). Ietf.org. 2010-12-07. . Retrieved 2011-01-11. [4] "JAIN SIP project" (http:/ / java. net/ projects/ jsip). . Retrieved 2011-07-26. [5] William Stallings, p.209 [6] RFC 3261, SIP: Session Initiation Protocol [7] Azzedine (2006). Handbook of algorithms for wireless networking and mobile computing (http:/ / books. google. com/ books?id=b8oisvv6fDAC& pg=PT774). CRC Press. p.774. ISBN9781584884651. . [8] Porter, Thomas; Andy Zmolek, Jan Kanclirz, Antonio Rosela (2006). Practical VoIP Security (http:/ / books. google. com/ books?id=BYxdyekyRlwC& pg=PA76). Syngress. pp.7677. ISBN9781597490603. . [9] ""BlackBerry MVS Software"" (http:/ / na. blackberry. com/ eng/ services/ business/ blackberry_mvs/ ). Na.blackberry.com. . Retrieved 2011-01-11. [10] RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, IETF, The Internet Society (2005) [11] "User-Agents We Have Known " (http:/ / www. voipuser. org/ forum_topic_14998. html)VoIP User.org
52
External links
Computers/Internet/Protocols/SIP/ (http://www.dmoz.org/Computers/Internet/Protocols/SIP//) at the Open Directory Project Henning Schulzrinne's SIP homepage (http://www.cs.columbia.edu/sip/) hosted by Columbia University SIP Latest specifications (http://www.sipknowledge.com/eBooks.htm) hosted by SIPKnowledge Some examples of SIP Use Cases (features) (http://www.sipcenter.com/sip.nsf/html/Personal+Selective+ Presence) IANA: SIP Parameters (http://www.iana.org/assignments/sip-parameters) IANA: SIP Event Types Namespace (http://www.iana.org/assignments/sip-events/sip-events.xhtml)
53
Service ports
UDP applications use datagram sockets to establish host-to-host communications. An application binds a socket to its endpoint of data transmission, which is a combination of an IP address and a service port. A port is a software structure that is identified by the port number, a 16 bit integer value, allowing for port numbers between 0 and 65535. Port 0 is reserved, but is a permissible source port value if the sending process does not expect messages in response. The Internet Assigned Numbers Authority has divided port numbers into three ranges.[2] Port numbers 0 through 1023 are used for common, well-known services. On Unix-like operating systems, using one of these ports requires superuser operating permission. Port numbers 1024 through 49151 are the registered ports used for IANA-registered services. Ports 49152 through 65535 are dynamic ports that are not officially designated for any specific service, and can be used for any purpose. They are also used as ephemeral ports, from which software running on the host may randomly choose a port in order to define itself.[2] In effect, they are used as temporary ports primarily by clients when communicating with servers.
Packet structure
UDP is a minimal message-oriented Transport Layer protocol that is documented in IETF RFC 768. UDP provides no guarantees to the upper layer protocol for message delivery and the UDP protocol layer retains no state of UDP messages once sent. For this reason, UDP is sometimes referred to as Unreliable Datagram Protocol.[3] UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload.[4] If transmission reliability is desired, it must be implemented in the user's application.
offset (bits) 0 32 64+ 0 15 16 31
The UDP header consists of 4 fields, each of which is 2 bytes (16 bits).[1] The use of two of those is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see below). Source port number This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number.[2] Destination port number This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.[2] Length A field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 8 byte UDP header 20 byte IP header).[2] Checksum
User Datagram Protocol The checksum field is used for error-checking of the header and data. If no checksum is generated by the transmitter, the field uses the value all-zeros.[5] This field is not optional for IPv6.[6]
54
Checksum computation
The method used to compute the checksum is defined in RFC 768: Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.[5] In other words, all 16-bit words are summed using one's complement arithmetic. The sum is then one's complemented to yield the value of the UDP checksum field. If the checksum calculation results in the value zero (all 16 bits 0) it should be sent as the one's complement (all 1s). The difference between IPv4 and IPv6 is in the data used to compute the checksum.
IPv4 PSEUDO-HEADER
When UDP runs over IPv4, the checksum is computed using a PSEUDO-HEADER that contains some of the same information from the real IPv4 header. The PSEUDO-HEADER is not the real IPv4 header used to send an IP packet. The following table defines the PSEUDO-HEADER used only for the checksum calculation.
bits 0 32 64 96 128 160+ 07 8 15 16 23 24 31
Source address Destination address Zeros Protocol Source Port Length Data UDP length Destination Port Checksum
The source and destination addresses are those in the IPv4 header. The protocol is that for UDP (see List of IP protocol numbers): 17 (0x11). The UDP length field is the length of the UDP header and data. UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.
IPv6 PSEUDO-HEADER
When UDP runs over IPv6, the checksum is mandatory. The method used to compute it is changed as documented in RFC 2460: Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6 to include the 128-bit IPv6 addresses.[6] When computing the checksum, again a PSEUDO-HEADER is used that mimics the real IPv6 header:
55
bits 0 32 64 96 128 160 192 224 256 288 320 352 384+
0 7 8 15 16 23 Source address
24 31
Destination address
UDP length Zeros Source Port Length Data Next Header Destination Port Checksum
The source address is the one in the IPv6 header. The destination address is the final destination; if the IPv6 packet does not contain a Routing header, that will be the destination address in the IPv6 header; otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header. The value of the Next Header field is the protocol value for UDP: 17. The UDP length field is the length of the UDP header and data.
56
Applications
Numerous key Internet applications use UDP, including: the Domain Name System (DNS), where queries must be fast and only consist of a single request followed by a single reply packet, the Simple Network Management Protocol (SNMP), the Routing Information Protocol (RIP)[1] and the Dynamic Host Configuration Protocol (DHCP). Voice and video traffic is generally transmitted using UDP. Real-time video and audio streaming protocols are designed to handle occasional lost packets, so only slight degradation in quality occurs, rather than large delays if lost packets were retransmitted. Because both TCP and UDP run over the same network, many businesses are finding that a recent increase in UDP traffic from these real-time applications is hindering the performance of applications using TCP, such as point of sale, accounting, and database systems. When TCP detects packet loss, it will throttle back its data rate usage. Since both real-time and business applications are important to businesses, developing quality of service solutions is seen as crucial by some.[7]
57
References
[1] Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN9780131365483. [2] Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited. [3] content@ipv6.com. "UDP Protocol Overview" (http:/ / ipv6. com/ articles/ general/ User-Datagram-Protocol. htm). Ipv6.com. . Retrieved 2011-08-17. [4] Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd. [5] Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http:/ / tools. ietf. org/ html/ rfc768 [6] Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http:/ / tools. ietf. org/ html/ rfc2460 [7] "The impact of UDP on Data Applications" (http:/ / www. networkperformancedaily. com/ 2007/ 08/ whiteboard_series_nice_guys_fi. html). Networkperformancedaily.com. . Retrieved 2011-08-17.
RFC references
RFC 768 User Datagram Protocol RFC 2460 Internet Protocol, Version 6 (IPv6) Specification RFC 4113 Management Information Base for the UDP RFC 5405 Unicast UDP Usage Guidelines for Application Designers
External links
IANA Port Assignments (http://www.iana.org/assignments/port-numbers) The Trouble with UDP Scanning (PDF) (http://condor.depaul.edu/~jkristof/papers/udpscanning.pdf) Breakdown of UDP frame (http://www.networksorcery.com/enp/protocol/udp.htm) UDP on MSDN Magazine Sockets and WCF (http://msdn.microsoft.com/en-us/magazine/cc163648.aspx) UDP connections (http://www.faqs.org/docs/iptables/udpconnections.html)
User agent
58
User agent
In computing, a user agent is a client application implementing a network protocol used in communications within a clientserver distributed computing system. The term most notably refers to applications that access the World Wide Web, but other systems, such as the Session Initiation Protocol (SIP), use the term user agent to refer to both end points of a communications session.[1] Web user agents range from Web browsers to search engine crawlers (spiders), as well as mobile phones, screen readers and braille browsers used by people with disabilities. When a user agent operates, it typically identifies itself, its application type, operating system, software vendor, or software revision, by submitting a characteristic identification string to its operating peer. In the HTTP, SIP, and SMTP/NNTP[2] protocols, this is transmitted in a header field User-Agent. Bots, such as Web crawlers, often also include a URL and/or e-mail address so that the Webmaster can contact the operator of the bot.
Format
RFC 1945 merely requires the format of a user agent to be a string made up of the product and optional comments. For example if your product were called WikiBrowser, your user agent string may be similar to WikiBrowser/1.0 Gecko/1.0. The parts of this string are as follows: Product name and version (WikiBrowser/1.0) Layout engine and version(Gecko/1.0). In this case, this indicates the Layout engine and version. An unofficial format, based on the above, used by Web browsers is as follows: Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [extensions]. For example, Safari on the iPad has used the following:
Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405
The components of this string are as follows: Mozilla/5.0: Previously used to indicate compatibility with the Mozilla rendering engine (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us): Details of the system in which the browser is running AppleWebKit/531.21.10: The platform the browser uses (KHTML, like Gecko): Browser platform details
Mobile/7B405: This is used by the browser to indicate specific enhancements that are available directly in the browser or through third parties. An example of this is Microsoft Live Meeting which registers an extension so that the Live Meeting service knows if the software is already installed, which means it can provide a streamlined
59
User agent
60
References
[1] [2] [3] [4] RFC 3261, SIP: Session Initiation Protocol, IETF, The Internet Society (2002) Netnews Article Format (http:/ / tools. ietf. org/ html/ rfc5536& #035;section-3. 2. 13). IETF. November 2009. sec.3.2.13. RFC 5536. . http:/ / tools. ietf. org/ html/ rfc1945#section-10. 15 Peter Eckersley. " Browser Versions Carry 10.5 Bits of Identifying Information on Average (https:/ / www. eff. org/ deeplinks/ 2010/ 01/ tracking-by-user-agent)", Electronic Frontier Foundation, 27 January 2010. Retrieved 25 August 2011. [5] Burstein complaining "...I've been rejected until I come back with Netscape" (http:/ / www. anybrowser. org/ campaign/ ) [6] http:/ / androidcommunity. com/ forums/ f8/ android-browser-reports-itself-as-apple-safari-4701/ [7] "Viewable with Any Browser" campaign (http:/ / www. anybrowser. org/ campaign/ ) [8] Pemberton, Stephen. "W3C Markup Validation Service" (http:/ / www. w3. org/ MarkUp/ #guidelines). W3C. . Retrieved 10/18/2011. [9] Clary, Bob (10 February 2003). "Browser Detection and Cross Browser Support" (https:/ / developer. mozilla. org/ en/ Browser_Detection_and_Cross_Browser_Support). Mozilla Developer Center. Mozilla. . Retrieved 2009-05-30. [10] Zawinski, Jamie (1998-03-28). "user-agent strings (obsolete)" (http:/ / www-archive. mozilla. org/ build/ user-agent-strings. html). mozilla.org. . Retrieved 2010-01-08.
External links
User-agents.org, database of known user agent strings (http://www.user-agents.org) Analyze any user agent string (http://www.useragentstring.com/)
61
The Hypertext Transfer Protocol (HTTP) is a networking protocol for distributed, collaborative, hypermedia information systems.[1] HTTP is the foundation of data communication for the World Wide Web. The standards development of HTTP has been coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs), most notably RFC 2616 (June 1999), which defines HTTP/1.1, the version of HTTP in common use.
Technical overview
HTTP functions as a request-response protocol in the client-server computing model. In HTTP, a web browser, for example, acts as a client, while an application running on a computer hosting a web site functions as a server. The client submits an HTTP request message to the server. The server, which stores content, or provides resources, such as HTML files, or performs other functions on behalf of the client, returns a response message to the client. A response contains completion status information about the request and may contain any content requested by the client in its message body. A web browser (or client) is often referred to as a user agent (UA). Other user agents can include the indexing software used by search providers, known as web crawlers, or variations of the web browser such as voice browsers, which present an interactive voice user interface. The HTTP protocol is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of the original, so-called origin server, to improve response time. HTTP proxy servers at network boundaries facilitate communication when clients without a globally routable address are located in private networks by relaying the requests and responses between clients and servers. HTTP is an Application Layer protocol designed within the framework of the Internet Protocol Suite. The protocol definitions presume a reliable Transport Layer protocol for host-to-host data transfer.[2] The Transmission Control Protocol (TCP) is the dominant protocol in use for this purpose. However, HTTP has found application even with unreliable protocols, such as the User Datagram Protocol (UDP) in methods such as the Simple Service Discovery Protocol (SSDP).
Hypertext Transfer Protocol HTTP Resources are identified and located on the network by Uniform Resource Identifiers (URIs)or, more specifically, Uniform Resource Locators (URLs)using the http or https URI schemes. URIs and the Hypertext Markup Language (HTML), form a system of inter-linked resources, called hypertext documents, on the Internet, that led to the establishment of the World Wide Web in 1990 by English computer scientist and innovator Tim Berners-Lee. The original version of HTTP (HTTP/1.0) was revised in HTTP/1.1. HTTP/1.0 uses a separate connection to the same server for every request-response transaction, while HTTP/1.1 can reuse a connection multiple times, to download, for instance, images for a just delivered page. Hence HTTP/1.1 communications experience less latency as the establishment of TCP connections presents considerable overhead.
62
History
The term HyperText was coined by Ted Nelson who in turn was inspired by Vannevar Bush's microfilm-based "memex". Tim Berners-Lee first proposed the "WorldWideWeb" project now known as the World Wide Web. Berners-Lee and his team are credited with inventing the original HTTP protocol along with the HTML and the associated technology for a web server and a text-based web browser. The first version of the protocol had only one method, namely GET, which would request a page from a server.[3] The response from the server was always an HTML page.[4] The first documented version of HTTP was HTTP V0.9 [5] (1991). Dave Raggett led the HTTP Working Group (HTTP WG) in 1995 and wanted to expand the protocol extended operations, extended negotiation, richer meta-information, tied with a security protocol and got more efficient by adding additional methods and header fields.[6] [7] RFC 1945 officially introduced and recognized HTTP V1.0 in 1996. The HTTP WG planned to publish new standards in December 1995[8] and the support for pre-standard HTTP/1.1 based on the then developing RFC 2068 (called HTTP-NG) was rapidly adopted by the major browser developers in early 1996. By March 1996, pre-standard HTTP/1.1 was supported in Arena,[9] Netscape 2.0,[9] Netscape Navigator Gold 2.01,[9] Mosaic 2.7, Lynx 2.5, and in Internet Explorer 3.0. End user adoption of the new browsers was rapid. In March 1996, one web hosting company reported that over 40% of browsers in use on the Internet were HTTP 1.1 compliant. That same web hosting company reported that by June 1996, 65% of all browsers accessing their servers were HTTP/1.1 compliant.[10] The HTTP/1.1 standard as defined in RFC 2068 was officially released in January 1997. Improvements and updates to the HTTP/1.1 standard were released under RFC 2616 in June 1999.
HTTP session
An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically port 80; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for a client's request message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.[1]
63
Request message
The request message consists of the following: Request line, such as GET /images/logo.png HTTP/1.1, which requests a resource called /images/logo.png from server Headers, such as Accept-Language: en An empty line. An optional message body. The request line and headers must all end with <CR><LF> (that is, a carriage return followed by a line feed). The empty line must consist of only <CR><LF> and no other whitespace.[11] Although <CR><LF> is required <LF> alone is also accepted by most servers. In the HTTP/1.1 protocol, all headers except Host are optional. A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification in RFC1945 [12].[13]
Request methods
HTTP defines nine methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server. HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. GET Requests a representation of the specified resource. Requests using GET (and a few other HTTP methods) "SHOULD NOT have the significance of taking an action other than retrieval".[1] The W3C has published guidance principles on this distinction, saying, "Web application design should be informed by the above principles, but also by the relevant limitations."[14] See safe methods below. POST Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. PUT Uploads a representation of the specified resource. DELETE Deletes the specified resource. TRACE Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers. OPTIONS
An HTTP request made using telnet. The request, response headers and response body are highlighted.
Hypertext Transfer Protocol Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource. CONNECT Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.[15] PATCH Is used to apply partial modifications to a resource.[16] HTTP servers are required to implement at least the GET and HEAD methods[17] and, whenever possible, also the OPTIONS method.
64
Safe methods
Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe. By contrast, methods such as POST, PUT and DELETE are intended for actions that may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers; some that do not conform tend to make requests without regard to context or consequences. Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server. Furthermore, methods such as TRACE, TRACK and DEBUG are considered potentially 'unsafe' by some security professionals, because they can be used by attackers to gather information or bypass security controls during attacks. Security software tools such as Tenable Nessus and Microsoft URLScan report on the presence of these methods as being security issues.
65
Status codes
In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as "404") and a textual reason phrase (such as "Not Found"). The way the user agent handles the response primarily depends on the code and secondarily on the response headers. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general class of the response.[18] Also, the standard reason phrases are only recommendations and can be replaced with "local equivalents" at the web developer's discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable.
Persistent connections
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request. Such persistent connections reduce request latency perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent. Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.
Secure HTTP
There are three methods of establishing a secure HTTP connection: HTTP Secure, Secure Hypertext Transfer Protocol and the HTTP/1.1 Upgrade header. Browser support for the latter two is, however, nearly non-existent, so HTTP Secure is the dominant method of establishing a secure HTTP connection.
Example session
Below is a sample conversation between an HTTP client and an HTTP server running on www.example.com, port 80.
Client request
GET /index.html HTTP/1.1 Host: www.example.com
Hypertext Transfer Protocol A client request (consisting in this case of the request line and only one header) is followed by a blank line, so that the request ends with a double newline, each in the form of a carriage return followed by a line feed. The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
66
Server response
HTTP/1.1 200 OK Date: Mon, 23May 200522:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8 A server response is followed by a blank line and text of the requested page. The ETag (entity tag) header is used to determine if a cached version of the requested resource is identical to the current version of the resource on the server. Content-Type specifies the Internet media type of the data conveyed by the http message, while Content-Length indicates its length in bytes. The HTTP/1.1 webserver publishes its ability to respond to requests for certain byte ranges of the document by setting the header Accept-Ranges: bytes. This is useful, if the client needs to have only certain portions[19] of a resource sent by the server, which is called byte serving. When Connection: close is sent in a header, it means that the web server will close the TCP connection immediately after the transfer of this response. Most of the header lines are optional. When Content-Length is missing the length is determined in other ways. Chunked transfer encoding uses a chunk size of 0 to mark the end of the content. Identity encoding without Content-Length reads content until the socket is closed. A Content-Encoding like gzip can be used to compress the transmitted data.
References
[1] Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee (June 1999). "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1" (http:/ / tools. ietf. org/ html/ rfc2616). . [2] Fielding, et al. Internet RFC 2616." (http:/ / www. w3. org/ Protocols/ rfc2616/ rfc2616-sec1. html#sec1. 4), section 1.4. Retrieved on January 21, 2009. [3] Berners-Lee, Tim. "HyperText Transfer Protocol" (http:/ / www. w3. org/ History/ 19921103-hypertext/ hypertext/ WWW/ Protocols/ HTTP. html). World Wide Web Consortium. . Retrieved 31 August 2010. [4] Tim Berners-Lee. "The Original HTTP as defined in 1991" (http:/ / www. w3. org/ Protocols/ HTTP/ AsImplemented. html). World Wide Web Consortium. . Retrieved 24 July 2010. [5] http:/ / www. w3. org/ pub/ WWW/ Protocols/ HTTP/ AsImplemented. html [6] Raggett, Dave. "Dave Raggett's Bio" (http:/ / www. w3. org/ People/ Raggett/ profile. html). World Wide Web Consortium. . Retrieved 11 June 2010. [7] Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group" (http:/ / www. w3. org/ Arena/ webworld/ httpwgcharter. html). World Wide Web Consortium. . Retrieved 29 September 2010. [8] Raggett, Dave. "HTTP WG Plans" (http:/ / www. w3. org/ Arena/ webworld/ httpwgplans. html). World Wide Web Consortium. . Retrieved 29 September 2010. [9] Simon Spero. "Progress on HTTP-NG" (http:/ / www. w3. org/ Protocols/ HTTP-NG/ http-ng-status. html). World Wide Web Consortium. . Retrieved 11 June 2010. [10] "HTTP/1.1" (http:/ / www. webcom. com/ glossary/ http1. 1. shtml). Webcom.com Glossary entry. . Retrieved 2009-05-29. [11] Cailliau, Robert (1 July 1992). "Updates To HTTP" (http:/ / www. w3. org/ History/ 19921103-hypertext/ hypertext/ WWW/ Protocols/ HTTP/ HTTP2. html). World Wide Web Consortium. . Retrieved 1 September 2010. [12] http:/ / www. ietf. org/ rfc/ rfc1945. txt
67
Further reading
HTTP 0.9 - As Implemented in 1991 (http://www.w3.org/Protocols/HTTP/AsImplemented.html)
External links
"Change History for HTTP" (http://www.w3.org/Protocols/History.html). W3.org. Retrieved 2010-08-01. A detailed technical history of HTTP. "Design Issues for HTTP" (http://www.w3.org/Protocols/DesignIssues.html). W3.org. Retrieved 2010-08-01. Design Issues by Berners-Lee when he was designing the protocol. "Classic HTTP Documents" (http://www.w3.org/Protocols/Classic.html). W3.org. 1998-05-14. Retrieved 2010-08-01. list of other classic documents recounting the early protocol history
H.323
H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio-visual communication sessions on any packet network. The H.323 standard addresses call signaling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences.[1] It is widely implemented by voice and videoconferencing equipment manufacturers, is used within various Internet real-time applications such as GnuGK and NetMeeting and is widely deployed worldwide by service providers and enterprises for both voice and video services over IP networks. It is a part of the ITU-T H.32x series of protocols, which also address multimedia communications over ISDN, the PSTN or SS7, and 3G mobile networks. H.323 call signaling is based on the ITU-T Recommendation Q.931 protocol and is suited for transmitting calls across networks using a mixture of IP, PSTN, ISDN, and QSIG over ISDN. A call model, similar to the ISDN call model, eases the introduction of IP telephony into existing networks of ISDN-based PBX systems, including transitions to IP-based PBXs. Within the context of H.323, an IP-based PBX might be a gatekeeper or other call control element which provides service to telephones or videophones. Such a device may provide or facilitate both basic services and supplementary services, such as call transfer, park, pick-up, and hold. While H.323 excels at providing basic telephony functionality and interoperability, H.323s strength lies in multimedia communication functionality designed specifically for IP networks.
H.323
68
History
The first version of H.323 was published by the ITU in November 1996[2] with an emphasis of enabling videoconferencing capabilities over a Local Area Network (LAN), but was quickly adopted by the industry as a means of transmitting voice communication over a variety of IP networks, including WANs and the Internet (see VoIP). Over the years, H.323 has been revised and re-published with enhancements necessary to better-enable both voice and video functionality over Packet-switched networks, with each version being backward-compatible with the previous version.[3] Recognizing that H.323 was being used for communication, not only on LANs, but over WANs and within large carrier networks, the title of H.323 was changed when published in 1998.[4] The title, which has since remained unchanged, is "Packet-Based Multimedia Communications Systems." The current version of H.323 was approved in 2009.[5] One strength of H.323 was the relatively early availability of a set of standards, not only defining the basic call model, but also the supplementary services needed to address business communication expectations. H.323 was the first VoIP standard to adopt the Internet Engineering Task Force (IETF) standard Real-time Transport Protocol (RTP) to transport audio and video over IP networks.
Protocols
H.323 is a system specification that describes the use of several ITU-T and IETF protocols. The protocols that comprise the core of almost any H.323 system are:[6] H.225.0 Registration, Admission and Status (RAS), which is used between an H.323 endpoint and a Gatekeeper to provide address resolution and admission control services. H.225.0 Call Signaling, which is used between any two H.323 entities in order to establish communication. H.245 control protocol for multimedia communication, which describes the messages and procedures used for capability exchange, opening and closing logical channels for audio, video and data, control and indications. Real-time Transport Protocol (RTP), which is used for sending or receiving multimedia information (voice, video, or text) between any two entities. Many H.323 systems also implement other protocols that are defined in various ITU-T Recommendations to provide supplementary services support or deliver other functionality to the user. Some of those Recommendations are: H.235 series describes security within H.323, including security for both signaling and media. H.239 describes dual stream use in videoconferencing, usually one for live video, the other for still images. H.450 series describes various supplementary services. H.460 series defines optional extensions that might be implemented by an endpoint or a Gatekeeper, including ITU-T Recommendations H.460.17, H.460.18, and H.460.19 for Network address translation (NAT) / Firewall (FW) traversal.
In addition to those ITU-T Recommendations, H.323 implements various IETF Request for Comments (RFCs) for media transport and media packetization, including the Real-time Transport Protocol (RTP).
H.323
69
Codecs
H.323 utilizes both ITU-defined codecs and codecs defined outside the ITU. Codecs that are widely implemented by H.323 equipment include: Audio codecs: G.711, G.729 (including G.729a), G.723.1, G.726, G.722, G.728, Speex Text codecs: T.140 Video codecs: H.261, H.263, H.264 All H.323 terminals providing video communications shall be capable of encoding and decoding video according to H.261 QCIF. All H.323 terminals shall have an audio codec and shall be capable of encoding and decoding speech according to ITU-T Rec. G.711. All terminals shall be capable of transmitting and receiving A-law and -law. Support for other audio and video codecs is optional.[5]
H.323 Architecture
The H.323 system defines several network elements that work together in order to deliver rich multimedia communication capabilities. Those elements are Terminals, Multipoint Control Units (MCUs), Gateways, Gatekeepers, and Border Elements. Collectively, terminals, multipoint control units and gateways are often referred to as endpoints. While not all elements are required, at least two terminals are required in order to enable communication between two people. In most H.323 deployments, a gatekeeper is employed in order to, among other things, facilitate address resolution.
H.323 Multipoint Control Units A Multipoint Control Unit (MCU) is responsible for managing multipoint conferences and is composed of two logical entities referred to as the Multipoint Controller (MC) and the Multipoint Processor (MP). In more practical terms, an MCU is a conference bridge not unlike the conference bridges used in the PSTN today. The most significant difference, however, is that H.323 MCUs might be capable of mixing or switching video, in addition to the normal audio mixing done by a traditional conference bridge. Some MCUs also provide multipoint data collaboration capabilities. What this means to the end user is that, by placing a video call into an H.323 MCU, the user might be able to see all of the other participants in the conference, not only hear their voices. Gateways Gateways are devices that enable communication between H.323 networks and other networks, such as PSTN or ISDN networks. If one party in a conversation is utilizing a terminal that is not an H.323 terminal, then the call must pass through a gateway in order to enable both parties to communicate. Gateways are widely used today in order to enable the legacy PSTN phones to interconnect with the large, international H.323 networks that are presently deployed by services providers. Gateways are also used within the enterprise in order to enable enterprise IP phones to communicate through the service provider to users on the PSTN. Gateways are also used in order to enable videoconferencing devices based on H.320 and H.324 to communicate with H.323 systems. Most of the third generation (3G) mobile networks deployed today utilize the H.324 protocol and are able to communicate with H.323-based terminals in corporate networks through such gateway devices. Gatekeepers A Gatekeeper is an optional component in the H.323 network that provides a number of services to terminals, gateways, and MCU devices. Those services include endpoint registration, address resolution, admission control, user authentication, and so forth. Of the various functions performed by the gatekeeper, address resolution is the most important as it enables two endpoints to contact each other without either endpoint having to know the IP address of the other endpoint. Gatekeepers may be designed to operate in one of two signaling modes, namely "direct routed" and "gatekeeper routed" mode. Direct routed mode is the most efficient and most widely deployed mode. In this mode, endpoints utilize the RAS protocol in order to learn the IP address of the remote endpoint and a call is established directly with the remote device. In the gatekeeper routed mode, call signaling always passes through the gatekeeper. While the latter requires the gatekeeper to have more processing power, it also gives the gatekeeper complete control over the call and the ability to provide supplementary services on behalf of the endpoints. H.323 endpoints use the RAS protocol to communicate with a gatekeeper. Likewise, gatekeepers use RAS to communicate with other gatekeepers. A collection of endpoints that are registered to a single Gatekeeper in H.323 is referred to as a zone. This collection of devices does not necessarily have to have an associated physical topology. Rather, a zone may be entirely logical and is arbitrarily defined by the network administrator. Gatekeepers have the ability to neighbor together so that call resolution can happen between zones. Neighboring facilitates the use of dial plans such as the Global Dialing Scheme. Dial plans facilitate inter-zone dialing so that two endpoints in separate zones can still communicate with each other.
70
H.323 Border Elements and Peer Elements Border Elements and Peer Elements are optional entities similar to a Gatekeeper, but that do not manage endpoints directly and provide some services that are not described in the RAS protocol. The role of a border or peer element is understood via the definition of an "administrative domain". An administrative domain is the collection of all zones that are under the control of a single person or organization, such as a service Figure 2 - An illustration of an administrative domain with border elements, peer provider. Within a service provider elements, and gatekeepers network there may be hundreds or thousands of gateway devices, telephones, video terminals, or other H.323 network elements. The service provider might arrange devices into "zones" that enable the service provider to best manage all of the devices under its control, such as logical arrangement by city. Taken together, all of the zones within the service provider network would appear to another service provider as an "administrative domain". The border element is a signaling entity that generally sits at the edge of the administrative domain and communicates with another administrative domain. This communication might include such things as access authorization information; call pricing information; or other important data necessary to enable communication between the two administrative domains. Peer elements are entities within the administrative domain that, more or less, help to propagate information learned from the border elements throughout the administrative domain. Such architecture is intended to enable large-scale deployments within carrier networks and to enable services such as clearinghouses. The diagram, figure 2, provides an illustration of an administrative domain with border elements, peer elements, and gatekeepers.
71
72
In the simplest form, an H.323 call may be established as follows (figure 3): In this example, the endpoint (EP) on the left initiated communication with the gateway on the right and the gateway connected the call with the called party. In reality, call flows are often more complex Figure 3 - Establishment of an H.323 call than the one shown, but most calls that utilize the Fast Connect procedures defined within H.323 can be established with as few as 2 or 3 messages. Endpoints must notify their gatekeeper (if gatekeepers are used) that they are in a call. Once a call has concluded, a device will send a Release Complete message. Endpoints are then required to notify their gatekeeper (if gatekeepers are used) that the call has ended. RAS Signaling Endpoints use the RAS protocol in order to communicate with a gatekeeper. Likewise, gatekeepers use RAS to communicate with peer gatekeepers. RAS is a fairly simple protocol composed of just a few messages. Namely: Gatekeeper request, reject, and confirm messages (GRx) Registration request, reject, and confirm messages (RRx) Unregister request, reject, and confirm messages (URx) Admission request, reject, and confirm messages (ARx) Bandwidth request, reject, and confirm message (BRx) Disengage request, reject, and confirm (DRx) Location request, reject, and confirm messages (LRx) Info request, ack, nack, and response (IRx) Nonstandard message Unknown message response Request in progress (RIP) Resource availability indication and confirm (RAx) Service control indication and response (SCx) Admission confirm sequence (ACS)
H.323
73
When an endpoint is powered on, it will generally send either a gatekeeper request (GRQ) message to "discover" gatekeepers that are willing to provide service or will send a registration request (RRQ) to a gatekeeper that is predefined in the systems administrative setup. Gatekeepers will then respond with a gatekeeper confirm (GCF). If a GRQ has been Figure 4 - A high-level communication exchange between two endpoints (EP) and two sent the endpoint will then select a gatekeepers (GK) gatekeeper with which to register by sending a registration request (RRQ), to which the gatekeeper responds with a registration confirm (RCF). At this point, the endpoint is known to the network and can make and place calls. When an endpoint wishes to place a call, it will send an admission request (ARQ) to the gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another gatekeeper, or by querying some other network service) and return the address of the remote endpoint in the admission confirm message (ACF). The endpoint can then place the call. Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to get permission to accept the incoming call. This is necessary, for example, to authenticate the calling device or to ensure that there is available bandwidth for the call. Figure 4 depicts a high-level communication exchange between two endpoints (EP) and two gatekeepers (GK). H.245 Call Control Once a call has initiated (but not necessarily fully connected) endpoints may initiate H.245 call control signaling in order to provide more extensive control over the conference. H.245 is a rather voluminous specification with many procedures that fully enable multipoint communication, though in practice most implementations only implement the minimum necessary in order to enable point-to-point voice and video communication. H.245 provides capabilities such as capability negotiation, master/slave determination, opening and closing of "logical channels" (i.e., audio and video flows), flow control, and conference control. It has support for both unicast and multicast communication, allowing the size of a conference to theoretically grow without bound. Capability Negotiation Of the functionality provided by H.245, capability negotiation is arguably the most important, as it enables devices to communicate without having prior knowledge of the capabilities of the remote entity. H.245 enables rich multimedia capabilities, including audio, video, text, and data communication. For transmission of audio, video, or text, H.323 devices utilize both ITU-defined codecs and codecs defined outside the ITU. Codecs that are widely implemented by H.323 equipment include: Video codecs: H.261, H.263, H.264 Audio codecs: G.711, G.729, G.729a, G.723.1, G.726 Text codecs: T.140 H.245 also enables real-time data conferencing capability through protocols like T.120. T.120-based applications generally operate in parallel with the H.323 system, but are integrated to provide the user with a seamless multimedia experience. T.120 provides such capabilities as application sharing T.128, electronic whiteboard T.126,
H.323 file transfer T.127, and text chat T.134 within the context of the conference. When an H.323 device initiates communication with a remote H.323 device and when H.245 communication is established between the two entities, the Terminal Capability Set (TCS) message is the first message transmitted to the other side. Master/Slave Determination After sending a TCS message, H.323 entities (through H.245 exchanges) will attempt to determine which device is the "master" and which is the "slave." This process, referred to as Master/Slave Determination (MSD), is important, as the master in a call settles all "disputes" between the two devices. For example, if both endpoints attempt to open incompatible media flows, it is the master who takes the action to reject the incompatible flow. Logical Channel Signaling Once capabilities are exchanged and master/slave determination steps have completed, devices may then open "logical channels" or media flows. This is done by simply sending an Open Logical Channel (OLC) message and receiving an acknowledgement message. Upon receipt of the acknowledgement message, an endpoint may then transmit audio or video to the remote endpoint. Fast Connect A typical H.245 exchange looks similar to figure 5: After this exchange of messages, the two endpoints (EP) in this figure would be transmitting audio in each direction. The number of message exchanges is numerous, each has an important purpose, but nonetheless takes time. For this reason, H.323 version 2 (published in 1998) introduced a concept called Fast Connect, which enables a device to establish Figure 5 - A typical H.245 exchange bi-directional media flows as part of the H.225.0 call establishment procedures. With Fast Connect, it is possible to establish a call with bi-directional media flowing with no more than two messages, like in figure 3. Fast Connect is widely supported in the industry. Even so, most devices still implement the complete H.245 exchange as shown above and performs that message exchange in parallel to other activities, so there is no noticeable delay to the calling or called party.
74
Use cases
H.323 and Voice over IP services
Voice over Internet Protocol (VoIP) describes the transmission of voice using the Internet or other packet switched networks. ITU-T Recommendation H.323 is one of the standards used in VoIP. VoIP requires a connection to the Internet or another packet switched network, a subscription to a VoIP service provider and a client (an analogue telephone adapter (ATA), VoIP Phone or "soft phone"). The service provider offers the connection to other VoIP services or to the PSTN. Most service providers charge a monthly fee, then additional costs when calls are made. Using VoIP between two enterprise locations would not necessarily require a VoIP service provider, for example.
H.323 H.323 has been widely deployed by companies who wish to interconnect remote locations over IP using a number of various wired and wireless technologies.
75
International Conferences
H.323 has been used in the industry to enable large-scale international video conferences that are significantly larger than the typical video conference. One of the most widely attended is an annual event called Megaconference.
Alternatives
The IETF produced a standard called the Session Initiation Protocol (SIP) that also enables voice and video communication over IP. There are also other ITU-T recommendations used for videoconferencing and videophone services - H.320 (using ISDN) and H.324 (using regular analog phone lines and 3G mobile phones). Some providers (such as Skype) also use their own closed, proprietary formats. Access Grid provides broadly similar functionality, with more emphasis on open-source and utilizing multicast. EVO also provides relatively open functionality via Java, and includes H.323 support.[7]
References
[1] Davidson, Jonathan; James Peters, Jim Peters, Brian Gracely. "H.323" (http:/ / books. google. com/ books?id=S5P7-Xtq7W8C& pg=PA229). Voice over IP fundamentals. Cisco Press. pp.229230. ISBN9781578701681. . [2] ITU-T Recommendation H.323 (11/1996) (http:/ / www. itu. int/ rec/ T-REC-H. 323-199611-S/ en/ ), first version of H.323. [3] ITU-T Recommendation H.323 (http:/ / www. itu. int/ rec/ T-REC-H. 323/ en/ ), in force, superseded and withdrawn component. [4] ITU-T Recommendation H.323 (02/1998) (http:/ / www. itu. int/ rec/ T-REC-H. 323-199802-S/ en/ ), Packet-based multimedia communications systems. [5] ITU-T Recommendation H.323 (12/2009) (http:/ / www. itu. int/ rec/ T-REC-H. 323), Packet-based multimedia communications systems. [6] See ITU-T Recommendations of the H.323 System for a detailed list. [7] "EVO The Collaboration Network" (http:/ / evo. caltech. edu/ evoGate). . Retrieved 2010-03-08.
H.323 ITU-T Recommendation H.283 (http://www.itu.int/rec/T-REC-H.283/en/), Remote device control logical channel transport. ITU-T Recommendation H.341 (http://www.itu.int/rec/T-REC-H.341/en/), Multimedia management information base. ITU-T H.235 Series Recommendations ITU-T Recommendation H.235.1 (http://www.itu.int/rec/T-REC-H.235.1/en/), H.323 security framework: Baseline security profile. ITU-T Recommendation H.235.2 (http://www.itu.int/rec/T-REC-H.235.2/en/), H.323 security framework: Signature security profile. ITU-T Recommendation H.235.3 (http://www.itu.int/rec/T-REC-H.235.3/en/), H.323 security: Hybrid security profile. ITU-T Recommendation H.235.4 (http://www.itu.int/rec/T-REC-H.235.4/en/), H.323 security: Direct and selective routed call security. ITU-T Recommendation H.235.5 (http://www.itu.int/rec/T-REC-H.235.5/en/), H.323 security: Framework for secure authentication in RAS using weak shared secrets. ITU-T Recommendation H.235.6 (http://www.itu.int/rec/T-REC-H.235.6/en/), H.323 security framework: Voice encryption profile with native H.235/H.245 key management. ITU-T Recommendation H.235.7 (http://www.itu.int/rec/T-REC-H.235.7/en/), H.323 security framework: Usage of the MIKEY key management protocol for the Secure Real Time Transport Protocol (SRTP) within H.235. ITU-T Recommendation H.235.8 (http://www.itu.int/rec/T-REC-H.235.8/en/), H.323 security: Key exchange for SRTP using secure signalling channels. ITU-T Recommendation H.235.9 (http://www.itu.int/rec/T-REC-H.235.9/en/), H.323 security: Security gateway support for H.323. ITU-T H.450 Series Recommendations ITU-T Recommendation H.450.1 (http://www.itu.int/rec/T-REC-H.450.1/en/), Generic functional protocol for the support of supplementary services in H.323. ITU-T Recommendation H.450.2 (http://www.itu.int/rec/T-REC-H.450.2/en/), Call transfer supplementary service for H.323. ITU-T Recommendation H.450.3 (http://www.itu.int/rec/T-REC-H.450.3/en/), Call diversion supplementary service for H.323. ITU-T Recommendation H.450.4 (http://www.itu.int/rec/T-REC-H.450.4/en/), Call hold supplementary service for H.323. ITU-T Recommendation H.450.5 (http://www.itu.int/rec/T-REC-H.450.5/en/), Call park and call pickup supplementary service for H.323. ITU-T Recommendation H.450.6 (http://www.itu.int/rec/T-REC-H.450.6/en/), Call waiting supplementary service for H.323. ITU-T Recommendation H.450.7 (http://www.itu.int/rec/T-REC-H.450.7/en/), Message waiting indication supplementary service for H.323. ITU-T Recommendation H.450.8 (http://www.itu.int/rec/T-REC-H.450.8/en/), Name identification supplementary service for H.323. ITU-T Recommendation H.450.9 (http://www.itu.int/rec/T-REC-H.450.9/en/), Call completion supplementary service for H.323. ITU-T Recommendation H.450.10 (http://www.itu.int/rec/T-REC-H.450.10/en/), Call offering supplementary service for H.323.
76
H.323 ITU-T Recommendation H.450.11 (http://www.itu.int/rec/T-REC-H.450.11/en/), Call intrusion supplementary service for H.323. ITU-T Recommendation H.450.12 (http://www.itu.int/rec/T-REC-H.450.12/en/), Common Information Additional Network Feature for H.323. ITU-T H.460 Series Recommendations ITU-T Recommendation H.460.1 (http://www.itu.int/rec/T-REC-H.460.1/en/), Guidelines for the use of the generic extensible framework. ITU-T Recommendation H.460.2 (http://www.itu.int/rec/T-REC-H.460.2/en/), Number Portability interworking between H.323 and SCN networks. ITU-T Recommendation H.460.3 (http://www.itu.int/rec/T-REC-H.460.3/en/), Circuit maps within H.323 systems. ITU-T Recommendation H.460.4 (http://www.itu.int/rec/T-REC-H.460.4/en/), Call priority designation and country/international network of call origination identification for H.323 priority calls. ITU-T Recommendation H.460.5 (http://www.itu.int/rec/T-REC-H.460.5/en/), H.225.0 transport of multiple Q.931 information elements of the same type. ITU-T Recommendation H.460.6 (http://www.itu.int/rec/T-REC-H.460.6/en/), Extended Fast Connect feature. ITU-T Recommendation H.460.7 (http://www.itu.int/rec/T-REC-H.460.7/en/), Digit maps within H.323 systems. ITU-T Recommendation H.460.8 (http://www.itu.int/rec/T-REC-H.460.8/en/), Querying for alternate routes within H.323 systems. ITU-T Recommendation H.460.9 (http://www.itu.int/rec/T-REC-H.460.9/en/), Support for online QoS-monitoring reporting within H.323 systems. ITU-T Recommendation H.460.10 (http://www.itu.int/rec/T-REC-H.460.10/en/), Call party category within H.323 systems. ITU-T Recommendation H.460.11 (http://www.itu.int/rec/T-REC-H.460.11/en/), Delayed call establishment within H.323 systems. ITU-T Recommendation H.460.12 (http://www.itu.int/rec/T-REC-H.460.12/en/), Glare control indicator within H.323 systems. ITU-T Recommendation H.460.13 (http://www.itu.int/rec/T-REC-H.460.13/en/), Called user release control. ITU-T Recommendation H.460.14 (http://www.itu.int/rec/T-REC-H.460.14/en/), Support for Multi-Level Precedence and Preemption (MLPP) within H.323 systems. ITU-T Recommendation H.460.15 (http://www.itu.int/rec/T-REC-H.460.15/en/), Call signalling transport channel suspension and redirection within H.323 systems. ITU-T Recommendation H.460.16 (http://www.itu.int/rec/T-REC-H.460.16/en/), Multiple message release sequence capability. ITU-T Recommendation H.460.17 (http://www.itu.int/rec/T-REC-H.460.17/en/), Using H.225.0 call signalling connection as transport for H.323 RAS messages. ITU-T Recommendation H.460.18 (http://www.itu.int/rec/T-REC-H.460.18/en/), Traversal of H.323 signalling across network address translators and firewalls. ITU-T Recommendation H.460.19 (http://www.itu.int/rec/T-REC-H.460.19/en/), Traversal of H.323 media across network address translators and firewalls. ITU-T Recommendation H.460.20 (http://www.itu.int/rec/T-REC-H.460.20/en/), Location number within H.323 systems. ITU-T Recommendation H.460.21 (http://www.itu.int/rec/T-REC-H.460.21/en/), Message broadcast for H.323 systems.
77
H.323 ITU-T Recommendation H.460.22 (http://www.itu.int/rec/T-REC-H.460.22/en/), Negotiation of security protocols to protect H.225.0 Call Signalling Messages. ITU-T H.500 Series Recommendations ITU-T Recommendation H.501 (http://www.itu.int/rec/T-REC-H.501/en/), Protocol for mobility management and intra/inter-domain communication in multimedia systems. ITU-T Recommendation H.510 (http://www.itu.int/rec/T-REC-H.510/en/), Mobility for H.323 multimedia systems and services. ITU-T Recommendation H.530 (http://www.itu.int/rec/T-REC-H.530/en/), Symmetric security procedures for H.323 mobility in H.510.
78
External links
General
H.323 Definition and overview (http://www.iec.org/online/tutorials/h323/index.html) H.323 Forum (http://www.h323forum.org/) H.323 Information site (http://www.packetizer.com/ipmc/h323/) H.323 Tutorial and resources (http://www.telecomspace.com/vop-h323.html)
Papers
H.323 Protocol Overview (technical) (http://hive.packetizer.com/users/packetizer/papers/h323/ h323_protocol_overview.pdf) H.323 Overview (less technical) (http://hive.packetizer.com/users/packetizer/papers/h323/ overview_of_h323.pdf) H.323 Call flow covering H.225, Q.931, H.245, RTP and RTCP protocols (PDF) (http://www.eventhelix.com/ RealtimeMantra/Telecom/h323_call_flow.pdf) H.323 Call flow (communication example) (http://www.en.voipforo.com/H323/H323_example.php) H.323 List of papers and presentations (http://www.h323forum.org/papers/)
Projects
H.323 Plus open source H.323 project (http://www.h323plus.org/) Xmeeting for Mac OS X (http://xmeeting.sourceforge.net/) GNU (OpenSource) Gatekeeper (http://www.gnugk.org/) Ekiga: open source VoIP and video conferencing application for GNOME (http://www.ekiga.org/)
H.225.0
79
H.225.0
H.225.0 is part of the H.323 family of telecommunication protocols. The main objective of H.225.0 is the definition of messages and procedures for: Call Signaling: establish, control and end an H.323 call. The call signaling of H.225.0 is based on the call setup procedures for ISDN, Recommendation Q.931. RAS Signaling Function: perform registration, admission, bandwidth changes, status and disengage procedures between endpoints and an H.323 Gatekeeper. The RAS signaling function uses a separate channel (RAS channel). This set of messages is called Registration, Admission and Status (RAS). Additionally, H.225.0 defines media packetization using RTP for traditional codecs like G.711, H.261 and H.263. Newer ITU recommendations for media compression/signaling refer to RFCs for packetization (e.g. H.264 utilizes the single NAL unit mode of RFC 3984 in H.323 as defined in H.241). The Message Encoding is performed by utilizing Q.931 User-to-User information elements to convey H.225 messages. The messages themselves are encoded according to the Packed Encoding Rules (PER) of ASN.1. The structure of H.225 follows the Q.931 standard as seen in the table below.
8 7 6 5 4 3 2 1 Octet 1 2 3 (-4)
Protocol Discriminator 0 0 0 0 Length of call reference bits Call reference value 0 Message type Information Elements H.225 structure
External links
ITU-T H.225.0 Recommendation [1]
References
[1] http:/ / www. itu. int/ rec/ T-REC-H. 225. 0/ en
80
Protocol components
A SCCP client uses TCP/IP to communicate with one or more Call Manager applications in a cluster. It uses the Real-time Transport Protocol (RTP) over UDP-transport for the bearer traffic (real-time audio stream) with other Skinny clients or an H.323 terminal. SCCP is a stimulus-based protocol and is designed as a communications protocol for hardware endpoints and other embedded systems, with significant CPU and memory constraints.
Origin
Cisco acquired SCCP technology when it acquired Selsius Corporation in 1998.[2] As a remnant of the Selsius origin of the current Cisco IP phones, the default device name format for registered Cisco phones with CallManager is SEP -- as in Selsius Ethernet Phone -- followed by the MAC address. Cisco also has marketed a Skinny-based softphone called Cisco IP Communicator.
Other implementations
Other companies like Symbol Technologies, SocketIP, and Digium have implemented this protocol in VoIP Terminals (phones), Media Gateway Controllers, and Softswitches. An open source implementation is available in the Asterisk (PBX) & FreeSWITCH[3] systems. IPBlue[4] markets a software phone (soft phone) which uses SCCP for signaling and emulates a Cisco 7960 hardware phone. The Cisco Unified Application Environment, the product acquired by Cisco when they purchased Metreos supports using SCCP to emulate Cisco 7960 hardware phones allowing applications to access all Cisco line-side features.
References
[1] Call states sent to SCCP endpoints by Cisco CallManager (http:/ / www. cisco. com/ en/ US/ products/ sw/ voicesw/ ps556/ products_tech_note09186a0080624977. shtml) [2] Cisco Systems acquisition of Selsius Systems (http:/ / newsroom. cisco. com/ dlls/ fspnisapi6d14. html) [3] http:/ / wiki. freeswitch. org/ wiki/ Mod_skinny [4] http:/ / www. ipblue. com/ IPBlue
External links
Skinny Call Control Protocol (SCCP) - Cisco Systems (http://www.cisco.com/en/US/tech/tk652/tk701/ tk589/tsd_technology_support_sub-protocol_home.html) Skinny Call Control Protocol (SCCP) - Fragment of a VoIP course dealing with SCCP, with sample captures (http://hisown.com/Talks/VoIP - Excerpt (SCCP).pdf) Alternative SCCP channel driver for Asterisk. Sourceforge Project called chan-sccp-b (http://chan-sccp-b. sourceforge.net)
81
Protocol directives
While similar in some ways to HTTP, RTSP defines control sequences useful in controlling multimedia playback. While HTTP is stateless, RTSP has state; an identifier is used when needed to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection and, while most RTSP control messages are sent by the client to the server, some commands travel in the other direction (i.e. from server to client). Presented here are the basic RTSP requests. Some typical HTTP requests, like the OPTIONS request, are also available. The default transport layer port number is 554. OPTIONS An OPTIONS request returns the request types the server will accept. DESCRIBE A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can be handled. The default port for the RTSP protocol is 554 for both UDP (deprecated and very rarely used) and TCP transports. This reply includes the presentation description, typically in Session Description Protocol (SDP) format. Among other things, the presentation description lists the media streams controlled with the aggregate URL. In the typical case, there is one media stream each for audio and video. SETUP A SETUP request specifies how a single media stream must be transported. This must be done before a PLAY request is sent. The request contains the media stream URL and a transport specifier. This specifier typically includes a local port for receiving RTP data (audio or video), and another for RTCP data (meta information). The server reply usually confirms the chosen parameters, and fills in the missing parts, such as the server's chosen ports. Each media stream must be configured using SETUP before an aggregate play request may be sent. PLAY A PLAY request will cause one or all media streams to be played. Play requests can be stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all media streams), or a single media stream URL (to play only that stream). A range can be specified. If no range is specified, the stream is played from the beginning and plays to the end, or, if the stream is paused, it is resumed at the point it was paused. PAUSE A PAUSE request temporarily halts one or all media streams, so it can later be resumed with a PLAY request. The request contains an aggregate or media stream URL. A range parameter on a PAUSE request specifies when to pause. When the range parameter is omitted, the pause occurs immediately and indefinitely.
Real Time Streaming Protocol RECORD The RECORD request can be used to send a stream to the server for storage. TEARDOWN A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session related data on the server.
82
Implementations
Server
QuickTime Streaming Server: Apple's closed-source streaming server that ships with Mac OS X Server. Darwin Streaming Server: Open-sourced version of QuickTime Streaming Server maintained by Apple. pvServer: Formerly called PacketVideo Streaming Server, this is Alcatel-Lucent's streaming server product. Helix Universal Server: RealNetworks commercial streaming server for RTSP, RTMP, iPhone OS, Silverlight and HTTP streaming media clients Helix DNA Server: RealNetworks' streaming server. Comes in both open-source and proprietary flavors. LIVE555: Open source C++ server and client libraries used in well known clients like VLC and mplayer. Feng: Lean and mean streaming server with focus with rfc compliance. VideoLAN: Open source media player and streaming server. Windows Media Services: Microsoft's streaming server included with Windows Server. VX30: Streaming video server and embedded JAVA client from Maui X-Stream. Xenon Streaming Server: Mobile streaming server from Vidiator Technology (US) Inc. RtpRtspStack: Streaming server which is designed for low footprint and high performance applications. Gstreamer based RTSP Server and client. FFmpeg: includes ffserver a GPL or LGPL RTSP streaming server. Erlyvideo[2] has RTSP client and can restream video to other protocols. ViaMotion : integrated RTSP server for Video On Demand by Anevia
Client
cURL (beginning with version 7.20.09 February 2010[3] ) FFmpeg (undocumented[4] [5] [6] [7] ) 1. Live playback: ffplay rtsp://some-server.youtube.com/some-media.3gp 2. Saving live broadcast to a file: ffmpeg -i rtsp://some-server.youtube.com/some-media.3gp -acodec copy -vcodec copy filename.3gp GStreamer Media Player Classic MPlayer MythTV via Freebox QuickTime RealPlayer Skype Spotify VLC media player
83
References
[1] [2] [3] [4] RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998 erlyvideo website (http:/ / erlyvideo. org/ ) http:/ / curl. haxx. se/ changes. html No mention of RTSP upon executing the command ffmpeg -h. Executing ffmpeg -format yields a multi-page list of items with one inconspicuous mention: "RTSP input format". Section "Supported file protocols" of this help screen only lists "file: http: pipe: rtp: tcp: udp:" and skips over "rtsp:". (FFmpeg release used: "FFmpeg version SVN-r11143", "built on Dec 3 2007 17:42:57", a statically linked Windows executable.) [5] No RTSP usage documented on FFmpeg.org website as of 30 May 2010: Google search page 1 (http:/ / www. google. com/ search?q=rtsp+ site:ffmpeg. org& num=100), page 2 (http:/ / www. google. com/ search?q=rtsp+ site:ffmpeg. org& num=100& start=100) (147 results total) [6] No mention of RTSP in FFmpeg documentation (http:/ / www. ffmpeg. org/ ffmpeg-doc. html) as of 30 May 2010. [7] An indirect hint in FFplay documentation (http:/ / www. ffmpeg. org/ ffplay-doc. html#SEC6) (as of 30 May 2010) that FFplay understands RTSPfound in one obscure mention: "`-rtp_tcp' Force RTP/TCP protocol usage instead of RTP/UDP. It is only meaningful if you are streaming with the RTSP protocol."
External links
"Real Time Streaming Protocol Information and Updates" (http://web.archive.org/web/20070306002838/ http://www.rtsp.org/). Archived from the original (http://www.rtsp.org) on 2007-03-06., a central information repository about RTSP. Tunnelling RTSP and RTP through HTTP (http://developer.apple.com/quicktime/icefloe/dispatch028.html), A standard solution to help RTSP work through firewalls and web proxies
84
Overview
RTP was developed by the Audio/Video Transport working group of the IETF standards organization. RTP is used in conjunction with other protocols such as H.323 and RTSP.[1] The RTP standard defines a pair of protocols, RTP and RTCP. RTP is used for transfer of multimedia data, and the RTCP is used to periodically send control information and QoS parameters.[2] RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facility for jitter compensation and detection of out of sequence arrival in data, that are common during transmissions on an IP network. RTP supports data transfer to multiple destinations through IP multicast.[3] RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.[1] Real-time multimedia streaming applications require timely delivery of information and can tolerate some packet loss to achieve this goal. For example, loss of a packet in audio application may result in loss of a fraction of a second of audio data, which can be made unnoticeable with suitable error concealment algorithms.[4] The Transmission Control Protocol (TCP), although standardized for RTP use,[5] is not normally used in RTP application because TCP favors reliability over timeliness. Instead the majority of the RTP implementations are built on the User Datagram Protocol (UDP).[4] Other transport protocols specifically designed for multimedia sessions are SCTP[6] and DCCP, although, as of 2010, they are not in widespread use.[7]
Protocol components
The RTP specification describes two sub-protocols: The data transfer protocol, RTP, which deals with the transfer of real-time data. Information provided by this protocol include timestamps (for synchronization), sequence numbers (for packet loss and reordering detection) and the payload format which indicates the encoded format of the data.[8] A control protocol, RTCP, used to specify quality of service (QoS) feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.[8] [9] An optional signaling protocol such as H.323 or Session Initiation Protocol (SIP) An optional media description protocol such as Session Description Protocol
Sessions
An RTP Session is established for each multimedia stream. A session consists of an IP address with a pair of ports for RTP and RTCP. For example, audio and video streams will have separate RTP sessions, enabling a receiver to deselect a particular stream.[10] The ports which form a session are negotiated using other protocols such as RTSP (using SDP in the setup method)[11] and SIP. According to the specification, an RTP port should be even and the RTCP port is the next higher odd port number. RTP and RTCP typically use unprivileged UDP ports (1024 to 65535),[12] but may use other transport protocols (most notably, SCTP and DCCP) as well, as the protocol design is transport independent.
Real-time Transport Protocol The profile defines the codecs used to encode the payload data and their mapping to payload format codes in the Payload Type (PT) field of the RTP header (see below). Each profile is accompanied by several payload format specifications, each of which describes the transport of a particular encoded data.[1] Some of the audio payload formats include: G.711, G.723, G.726, G.729, GSM, QCELP, MP3, DTMF etc., and some of the video payload formats include: H.261, H.263,[14] H.264, MPEG-4[14] etc.[15] Examples of RTP Profiles include: The RTP profile for Audio and video conferences with minimal control (RFC 3551) defines a set of static payload type assignments, and a mechanism for mapping between a payload format, and a payload type identifier (in header) using Session Description Protocol (SDP). The Secure Real-time Transport Protocol (SRTP) (RFC 3711) defines a profile of RTP that provides cryptographic services for the transfer of payload data.[16] The experimental Control Data Profile for RTP (RTP/CDP[17] ) for machine-to-machine communications.
85
Packet header
RTP packet header
bit offset 0 32 64 96 0-1 2 3 X 4-7 CC 8 M 9-15 PT 16-31 Sequence Number
Version P
Timestamp SSRC identifier CSRC identifiers ... Profile-specific extension header ID Extension header length Extension header ...
96+32CC 128+32CC
The RTP header has a minimum size of 12 bytes. After the header, optional header extensions may be present. This is followed by the RTP payload, the format of which is determined by the particular class of application.[18] The fields in the header are as follows: Version: (2 bits) Indicates the version of the protocol. Current version is 2.[19] P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the end of the RTP packet. A padding might be used to fill up a block of certain size, for example as required by an encryption algorithm.[19] X (Extension): (1 bit) Indicates presence of an Extension header between standard header and payload data. This is application or profile specific.[19] CC (CSRC Count): (4 bits) Contains the number of CSRC identifiers (defined below) that follow the fixed header.[20] M (Marker): (1 bit) Used at the application level and defined by a profile. If it is set, it means that the current data has some special relevance for the application.[20] PT (Payload Type): (7 bits) Indicates the format of the payload and determines its interpretation by the application. This is specified by an RTP profile. For example, see RTP Profile for audio and video conferences with minimal control (RFC 3551).[21] Sequence Number: (16 bits) The sequence number is incremented by one for each RTP data packet sent and is to be used by the receiver to detect packet loss and to restore packet sequence. The RTP does not specify any action on packet loss; it is left to the application to take appropriate action. For example, video applications may play the last known frame in place of the missing frame.[22] According to RFC 3550, the initial value of the sequence
Real-time Transport Protocol number should be random to make known-plaintext attacks on encryption more difficult.[20] RTP provides no guarantee of delivery, but the presence of sequence numbers makes it possible to detect missing packets.[3] Timestamp: (32 bits) Used to enable the receiver to play back the received samples at appropriate intervals. When several media streams are present, the timestamps are independent in each stream, and may not be relied upon for media synchronization. The granularity of the timing is application specific. For example, an audio application that samples data once every 125s (8kHz, a common sample rate in digital telephony) could use that value as its clock resolution. The clock granularity is one of the details that is specified in the RTP profile for an application.[22] SSRC: (32 bits) Synchronization source identifier uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.[20] CSRC: Contributing source IDs enumerate contributing sources to a stream which has been generated from multiple sources.[20] Extension header: (optional) The first 32-bit word contains a profile-specific identifier (16 bits) and a length specifier (16 bits) that indicates the length of the extension (EHL=extension header length) in 32-bit units, excluding the 32 bits of the extension header.[20]
86
RTP-based systems
A complete network based system will include other protocols and standards in conjunction with RTP. Protocols like SIP, RTSP, H.225 and H.245 are used for session initiation, control and termination. Other standards like H.264, MPEG, H.263 etc., are used to encode the payload data as specified via RTP Profile.[23] An RTP sender captures the multimedia data, which is then encoded, framed and transmitted as RTP packets with appropriate timestamps and increasing sequence numbers. Depending on the RTP Profile in use, the Payload Type field is set. The RTP receiver, captures the RTP packets, detects missing packets and may perform reordering of packets. The frames are decoded depending on the payload format and presented to the end user.[23]
RFC references
RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control RFC 6184, Proposed Standard, RTP Payload Format for H.264 Video RFC 3984, Obsolete, RTP Payload Format for H.264 Video RFC 4103, RTP Payload Format for Text Conversation RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams RFC 2250, Proposed Standard, RTP Payload Format for MPEG1/MPEG2 Video
87
Notes
[1] Colin Perkins, p.55 [2] Larry L. Peterson (2007). Computer Networks. Morgan Kaufmann. p. 430 (http:/ / books. google. com/ books?id=zGVVuO-6w3IC& pg=PA430). ISBN155860832X. [3] Daniel Hardy (2002). Network. De Boeck Universit. p. 298 (http:/ / books. google. com/ books?id=Oq8SEUW1wdQC& pg=PT320). [4] Colin Perkins, p.46 [5] RFC 4571 [6] Farrel, Adrian (2004). The Internet and its protocols (http:/ / books. google. com/ ?id=LtBegQowqFsC& pg=PA363& dq=rtp+ sctp). Morgan Kaufmann. p.363. ISBN9781558609136. . [7] Ozaktas, Haldun M.; Levent Onural (2007). THREE-DIMENSIONAL TELEVISION (http:/ / books. google. com/ ?id=kQvCHpuXji8C& pg=PA366& dq=rtp+ dccp). Springer. p.366. ISBN9783540725312. . [8] Colin Perkins, p.56 [9] Peterson, p.435 [10] Zurawski, Richard (2004). "RTP, RTCP and RTSP protocols" (http:/ / books. google. com/ ?id=MwMDUBKZ3wwC). The industrial information technology handbook. CRC Press. pp. 287 (http:/ / books. google. com/ books?id=MwMDUBKZ3wwC& pg=PT225& dq=RTP+ session). ISBN9780849319853. . [11] RFC 4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF (July 2006) [12] Collins, Daniel (2002). "Transporting Voice by using IP". Carrier grade voice over IP. McGraw-Hill Professional. pp. 47 (http:/ / books. google. com/ books?id=PVIuN9Y5FGMC& pg=PA47& dq=RTP+ session). ISBN0071363262. [13] RFC 3550, p.71 [14] Chou, Philip A.; Mihaela van der Schaar (2007). Multimedia over IP and wireless networks. Academic Press. pp. 514 (http:/ / books. google. com/ books?id=zeLFs3GD0QQC& pg=PA514). ISBN0120884801. [15] Perkins, p.60 [16] Collin Perkins, p.367 [17] Breese, Finley (2010). Serial Communication over RTP/CDP. BoD - Books on Demand. pp. (http:/ / books. google. de/ books?id=t18ehd_vM6wC& lpg=PP1& pg=PA9). ISBN9783839184608. [18] Peterson, p. 430 [19] Peterson, p. 431 (http:/ / books. google. com/ books?id=zGVVuO-6w3IC& pg=PA431) [20] "RTP Data Transfer Protocol" (http:/ / rfc-ref. org/ RFC-TEXTS/ 3550/ chapter4. html). RFC-Ref. . Retrieved 2009-03-18. [21] Colin Perkins, p.59 [22] Peterson, p. 432 (http:/ / books. google. com/ books?id=zGVVuO-6w3IC& pg=PA432) [23] Perkins, pp.11-13
References
Perkins, Colin (2003). RTP (http://books.google.com/?id=OM7YJAy9_m8C). Addison-Wesley. pp.414. ISBN9780672322495. Peterson, Larry L.; Bruce S. Davie (2007). Computer Networks (http://books.google.com/ ?id=zGVVuO-6w3IC) (4 ed.). Morgan Kaufmann. pp.806. ISBN9780123740137. "RTP" (http://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA144). Network Protocols Handbook. Javvin Technologies. 2005. ISBN9780974094526. "RTP" (http://www.youtube.com/watch?v=OaL2vVFbCG4&feature=channel_page). Broadband Networks. Ministry of Human resources, India. 2008.
88
External links
oRTP, RTP library from Linphone written in C (http://www.linphone.org/eng/documentation/dev/ortp.html) Henning Schulzrinne's RTP page (http://www.cs.columbia.edu/~hgs/rtp) (including FAQ (http://www.cs. columbia.edu/~hgs/rtp/faq.html)) GNU ccRTP (http://www.gnu.org/software/ccrtp/) JRTPLIB, a C++ RTP library (http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib) RTPMobile .NET, an open source .NET RTP library (http://rtpmobile.sitesled.com) LScube project, providing a full streaming suite including experimental SCTP support (http://lscube.org)
Protocol functions
RTCP provides three basic functions expected to be implemented in all RTP sessions: The primary function of RTCP is to gather statistics on quality aspects of the media distribution during a session and transmit this data to the session media source and other session participants. Such information may be used by the source for adaptive media encoding (codec) and detection of transmission faults. If the session is carried over a multicast network, this permits non-intrusive session quality monitoring. RTCP provides canonical end-point identifiers (CNAME) to all session participants. Although a source identifier (SSRC) of an RTP stream is expected to be unique, the instantaneous binding of source identifiers to end-points may change during a session. The CNAME establishes unique identification of end-points across an application instance (multiple use of media tools) and for third-party monitoring. RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. Such traffic will increase proportionally with the number of participants. Thus, to avoid network congestion, the protocol must include session bandwidth management. This is achieved by dynamically controlling the frequency of report transmissions. RTCP bandwidth usage should generally not exceed 5% of total session bandwidth. Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so that in large conferences new participants can receive the CNAME identifiers of the senders without excessive delay. A fourth, optional feature, is the provisioning of session control functions, because RTCP is a convenient means to reach all session participants, whereas RTP itself is not. RTP is only transmitted by a media source.
89
Message types
RTCP distinguishes several types of packets: sender report, receiver report, source description, and bye. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the Extended Report packet type introduced by RFC 3611.[3] Sender report (SR) The sender report is sent periodically by the active senders in a conference to report transmission and reception statistics for all RTP packets sent during the interval. The sender report includes an absolute timestamp, which is the number of seconds elapsed since midnight on January 1, 1900. The absolute timestamp allows the receiver to synchronize RTP messages. It is particularly important when both audio and video are transmitted simultaneously, because audio and video streams use independent relative timestamps. Receiver report (RR) The receiver report is for passive participants, those that do not send RTP packets. The report informs the sender and other receivers about the quality of service. Source description (SDES) The Source Description message is used to send the CNAME item to session participants. It may also be used to provide additional information such as the name, e-mail address, telephone number, and address of the owner or controller of the source. End of participation (BYE) A source sends a BYE message to shut down a stream. It allows an end-point to announce that it is leaving the conference. Although other sources can detect the absence of a source, this message is a direct announcement. It is also useful to a media mixer. Application-specific message (APP) The application-specific message provides a mechanism to design application-specific extensions to the RTCP protocol.
Hierarchical aggregation
Hierarchical aggregation (also known as RTCP feedback hierarchy) is an optimization of the RTCP feedback model and its aim is to shift the maximum number of users limit further together with QoS measurement.[6] It is used with Source-Specific Multicast where only a single source is allowed, such as in IPTV. Another type of multicast could be Any-Source Multicast, but it is not so suitable for large-scale applications with huge number of users. As of 2007, only the most modern IPTV systems use hierarchical aggregation.
90
References
[1] RFC 3550, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, The Internet Society (July 2003) [2] RFC 3605, Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP), C. Huitema, Microsoft (October 2003) [3] RFC 3611, RTP Control Protocol Extended Reports (RTCP XR), T. Friedman (Ed.), R. Caceres, A. Clark (Ed.), The Internet Society (November 2003) [4] Vt Novotn, Dan Komosn, Large-Scale RTCP Feedback Optimization, Journal of Networks, Vol.3 (3), March 2008 [5] Realtime control protocol and its improvements for Internet Protocol Television (http:/ / www. academypublisher. com/ jnw/ vol03/ no03/ jnw03030110. pdf) [6] Vt Novotn, Dan Komosn, Tree Structure for Specific-Source Multicast with Feedback Aggregation (http:/ / adela. utko. feec. vutbr. cz/ multicastssm/ pdf/ TreeStructureMulticastFeedback. pdf), ICN07 - The Sixth International Conference on Networking, Martinique, 2007, ISBN 0-7695-2805-8
Additional reading
Perkins, Colin (2003). RTP (http://books.google.com/books?id=OM7YJAy9_m8C). Addison-Wesley. pp.414. ISBN9780672322495. Peterson, Larry L.; Bruce S. Davie (2007). Computer Networks (http://books.google.com/ books?id=zGVVuO-6w3IC) (4 ed.). Morgan Kaufmann. pp.806. ISBN9780123740137. "RTCP" (http://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA145). Network Protocols Handbook. Javvin Technologies. 2005. ISBN9780974094526.
Rationale
Being able to dial telephone calls the way customers have come to expect is considered crucial for the convergence of classic telephone service (PSTN) and Internet telephony (VoIP), and for the development of new IP multimedia services. The problem of a single universal personal identifier for multiple communication services can be solved with different approaches. One simple approach is the Electronic Number Mapping System ENUM (also known as Telephone Number Mapping), developed by the IETF, using existing E.164 telephone numbers, protocols and infrastructure to indirectly access different services available under a single personal identifier. ENUM also permits connecting the IP world to the telephone system in a seamless manner.
91
System details
For an ENUM subscriber to be able to activate and use the ENUM service it needs to obtain three elements from a Registrar: A personal Uniform Resource Identifier (URI) to be used on the IP part of the network, as explained below One E.164 regular personal telephone number associated with the personal URI, to be used on the PSTN part of the network Authority to write his call forwarding/termination preferences in the NAPTR record accessible via the personal URI This works as follows: (1) the Registrar provides the Subscriber (or Registrant) with a domain name, the URI, that will be used for accessing a DNS server to fetch a NAPTR record, (2) a personal E.164 telephone number (the ENUM number). The URI domain name of (1) is biunivocally associated (one-to-one mapped) to the subscriber E.164 ENUM number of (2). Finally (3) the NAPTR record corresponding to the subscriber URI contains the subscriber call forwarding/termination preferences. Therefore, if a calling party being at the PSTN network dials a called party ENUM number by touch typing the E.164 called party number, the number will be translated at the ENUM gateway into the corresponding URI. This URI will be used for looking-up and fetching the NAPTR record obtaining the called party wishes about how the call should be forwarded or terminated (either on IP or on PSTN terminations) the so-called access information which the registrant (the called party) has specified by writing his/her choice at the NAPTR record, "Naming Authority Pointer Resource Records" as defined in RFC 3403, such as e-mail addresses, a fax number, a personal website, a VoIP number, mobile telephone numbers, voice mail systems, IP-telephony addresses, web pages, GPS coordinates, call diversions or instant messaging. Alternatively, when the calling party is at the IP side, the User Agent (UA) piece of software of the dialler will allow to dial a E.164 number, but the dialler UA will convert it into a URI, to be used for looking-up at the ENUM gateway DNS and fetch the NAPTR record obtaining the called party wishes about how the call should be forwarded or terminated (again, either on IP or on PSTN terminations). Calling by using a new personal E.164 number (the ENUM number) to look-up at a database is therefore an indirect calling support service. The ITU ENUM allocates a specific zone, namely "e164.arpa" for use with ENUM E.164 numbers on the IP side of the network. RFC 6116 defines how any E.164 number, such as +1 555 42 42 can be transformed into a Uniform Resource Identifier (URI), by reversing the numbers, separating them with dots and adding the e164.arpa suffix thus: 2.4.2.4.5.5.5.1.e164.arpa The URI can then be used for obtaining the Internet Protocol addresses for services such as the Session Initiation Protocol (SIP) VoIP telephony. In the Domain Name System, NAPTR records are used for setting the subscriber call forwarding/termination preferences. Therefore the whole system can 'translate' E.164 addresses to SIP addresses. An example NAPTR record is: $ORIGIN 2.4.2.4.5.5.5.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:phoneme@example.net!" . IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:myemail@example.com!" . This example specifies that if you want to use the "E2U+sip" service, you should use sip:phoneme@example.net as the address. The regular expression can be used by a telephone company to easily assign addresses to all of its clients. For example, if your number is +15554242, your SIP address is sip:4242@555telco.example.net; if your number is +15551234, your SIP address is sip:1234@555telco.example.net. The following Figure illustrates how ENUM works by giving an example: Subscriber A sets out to call Subscriber B.
92
1. The User Agent of an ENUM-enabled subscriber terminal device, or a PBX, or a Gateway, translates the request for the number +34 98 765 4321 in accordance with the rule described in RFC 6116 into the ENUM domain 1.2.3.4.5.6.7.8.9.4.3.e164.arpa. 2. A request is sent to the Domain Name System (DNS) asking it to look up the ENUM domain 1.2.3.4.5.6.7.8.9.4.3.e164.arpa.
3. The query returns a result in the form of so called Naming Authority Pointer Resource NAPTR records, as per RFC 3403. In the example above, the response is an address that can be reached in the Internet using the VoIP protocol, SIP per RFC 3261. 4. The terminal application now sets up a communication link, and the call is routed via the Internet. The ENUM user does not notice anything of this reversal and the DNS database look-up, as this is done automatically behind the scene using a user agent software in his PC or terminal, or at the PABX or Gateway. For instance, when the user types the telephone number in his web browser ENUM enabled agent and indicates what item of information he is looking for (email address, telephone number, web address, etc.) in the PC or terminal the number is converted to a domain name. This is sent to ENUM servers on the Internet, which send back the NAPTR records associated with the name. The access information and any priority indicated for them are stored in these. The user gets the requested address back on his PC or terminal. ENUM therefore in fact functions as a mechanism for translating a telephone number into a domain name with the requested address or number associated with it, but without the user viewing how this is done, just as he is currently unaware that he is using the DNS when he makes a connection with the Internet or what is going on at the telephone switch when he makes a call.
Uses
Call forwarding with ENUM
93
One way of doing call forwarding with ENUM is illustrated in the next figure. The caller uses the telephone to dial the number of another subscriber, which leads to an ENUM lookup (such as is provided by SIP Broker). The DNS responds to the caller by returning a list with NAPTR records for VoIP communication, telephone numbers and email addresses. Next, an attempt will be made, using the VoIP record from this list, to establish a connection with the subscriber. If the subscriber is not online, the next record selected will be that for a connection to Call forwarding with ENUM a PSTN or mobile telephone. If this attempt fails too, a voice message will be sent to the subscriber via a listed email address. Subdomains of e164.arpa are delegated on a country-code basis by ITU. Each delegation is normally made to a regulatory body designated by the national government for the country code concerned. What happens at a country level is a National Matter. In general the conventional DNS registry-registrar model is used. The national ENUM registry manages and operates the DNS infrastructure and related systems for country-code.e164.arpa. It takes registration requests from registrars who are agents of the end users, the registrants. Registrars are typically VoIP providers and telcos who bundle an ENUM registration as part of a VoIP service package. People using an ENUM-enabled VoIP service can dial the registrant's existing number and be connected to the registrant's VoIP telephone over the Internet instead of using the PSTN. When they call someone who does not use ENUM, calls complete over the Public Switched Telephone Network or PSTN in the usual manner. Alternative ENUM-like services such as E164.org [1] have also emerged. These services might verify PSTN numbers and can be used in addition to e164.arpa. However, this leads to confusion and complexity. Multiple DNS lookups may be needed and it is far from simple to know which E.164 numbers are registered in which of these alternate ENUM-like trees. It is also possible that if an E.164 number is registered in several of these trees, there can be inconsistencies in the information that is returned. Furthermore, the subscriber "owning" a particular E.164 number may not be aware that their number has been entered into one or more of these alternate ENUM-like trees or what information these alternate trees are returning for their E.164 number.
Telephone number mapping the called party wishes that matter and solve that decision. Another benefit of indirect dialling is to free the user to change his phone telco, webpage, IMS, email or whatever telecom service he uses without having to tell all his contacts about that. A presence enhanced ENUM facility having various profiles could automatically change the called party wishes as a function of where he/she is available. This could be a mechanism to automatically switch between cellphone and VoIP to the most convenient (or the less costing) termination.
94
ENUM varieties
One potential source of confusion, when talking about ENUM, is the variety of ENUM implementations in place today. Quite often, people speaking of ENUM are really referring to only one of the following: Public ENUM: The original vision of ENUM as a global, public directory-like database, with subscriber opt-in capabilities and delegation at the country code level in the e164.arpa domain. This is also referred to as user ENUM. Private ENUM: A carrier, VoIP operator or ISP may use ENUM techniques within its own networks, in the same way DNS is used internally to networks. Carrier ENUM: Groups of carriers or communication service providers agree to share subscriber information via ENUM in private peering relationships. The carriers themselves control subscriber information, not the individuals. Carrier ENUM is also referred to as infrastructure ENUM, and is being the subject of new IETF recommendations to support VoIP peering.....
Telephone number mapping calls to be terminated. In ENUM the number holder operator will typically be the gateway operator or, alternatively, will have an arrangement with a gateway operator, to whom he will transit the calls. But ENUM is a personal number, meant to be valid for the registrant life. Consequently in ENUM once the operator number holder assigns a number to a registrant, the number belongs to that registrant during his/her entire life. Hence, if the registrant wishes to change his initial number holder operator (that might also coincide being his gateway operator) there have to be provisions for the ENUM number to be ported from the initial operator to other number holder operators.
95
References
RFC 6116 - The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) RFC 3403 - Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database ENUM - The bridge between telephony and internet [2] ENUM - It's All in the Numbers [3] http://www.itu.int/osg/spu/enum/ http://www.ietf.org/html.charters/enum-charter.html
External links
Enum base [4] Country Code 1 ENUM LLC [5] TNS Carrier ENUM Services [6] Carrier Enum Registry and Tandem Transit [7] GSMA PathFinder Carrier ENUM Technology [8] NeuStar Global SIP Inter-working [9] UK ENUM database run by Nominet [10] Distributed Universal Number Discovery [11] e164.org - Free public ENUM database [1] openENUM.eu - Free public ENUM database for Europeans [12] Voice Peering Fabric ENUM Registry [13] Association deploying Global Services using UPT and ENUM under +87810 country code [14] XConnect Global Networks Ltd. secure multilateral Carrier/Infrastructure ENUM services [15] CircleID: ENUM Convergence [16] ENUM: Mapping the E.164 Number Space into the DNS [17] Voice Peering Forum [18] ENUM Convergence News [19] SIP Broker's multi-root ENUM lookup [20] lookup under e.164.arpa and UPT ENUM services [21] E164.PH Global ENUM Registry [22] Enum 2 go [23] ENUM en espaol [24]
96
References
[1] http:/ / www. e164. org [2] http:/ / www. eurescom. de/ message/ messageSep2004/ ENUM_The_bridge_between_telephony_and_Internet. asp [3] http:/ / www. tmcnet. com/ it/ 0403/ 0403inim. htm [4] http:/ / www. enum. org/ [5] http:/ / www. enumllc. com/ [6] http:/ / www. tnsi. com/ products-services/ telecom/ telecom-services/ carrier-enum-solutions [7] http:/ / www. carrierenum. us/ [8] http:/ / gsmworld. com/ our-work/ programmes-and-initiatives/ pathfinder/ [9] http:/ / neustar. biz/ interoperability/ sipix. cfm [10] http:/ / www. nic. uk/ tech/ enum/ [11] http:/ / www. dundi. info/ [12] http:/ / www. openenum. eu/ [13] http:/ / www. thevpf. com/ feature/ enum [14] http:/ / www. visionng. com/ [15] http:/ / www. xconnect. net/ [16] http:/ / www. circleid. com/ tags/ enum [17] http:/ / www. circleid. com/ posts/ enum_mapping_e164_into_dns/ [18] http:/ / www. thevpf. com/ [19] http:/ / www. enumregistry. com/ enum/ enumnews. aspx [20] http:/ / www. sipbroker. com/ sipbroker/ action/ enumLookup [21] [22] [23] [24] http:/ / www. enum2go. com http:/ / www. e164. ph http:/ / www. enum2go. com/ http:/ / es. wikitel. info/ wiki/ ENUM
ITU-T
The ITU Telecommunication Standardization Sector (ITU-T) is one of the three sectors (divisions or units) of the International Telecommunication Union (ITU); it coordinates standards for telecommunications. The standardization work of ITU dates back to 1865, with the birth of the International Telegraph Union. It became a United Nations specialized agency in 1947, and the International Telegraph and Telephone Consultative Committee (CCITT, from French: Comit Consultatif International Tlphonique et Tlgraphique) was created in 1956. It was renamed ITU-T in 1993.[1] ITU has been an intergovernmental public-private partnership organization since its inception and now has a membership of 191 countries (Member States) and over 700 public and private sector companies as well as international and regional telecommunication entities, known as Sector Members and Associates, which undertake most of the work of the Sector.[2] ITU-T has a permanent secretariat, the Telecommunication Standardization Bureau (TSB), based at the ITU HQ in Geneva, Switzerland. The elected Director of the Bureau is Malcolm Johnson of the UK. Johnson was elected by the ITU Membership to the directorship for a 4-year term in November 2006 and was reelected for a second term starting January 2011.
ITU-T
97
Primary function
The ITU-T mission is to ensure the efficient and timely production of standards covering all fields of telecommunications on a worldwide basis, as well as defining tariff and accounting principles for international telecommunication services.[3] The international standards that are produced by the ITU-T are referred to as "Recommendations" (with the word ordinarily capitalized to distinguish its meaning from the ordinary sense of the word "recommendation"), as they become mandatory only when adopted as part of a national law. Since the ITU-T is part of the ITU, which is a United Nations specialized agency, its standards carry more formal international weight than those of most other standards development organizations that publish technical specifications of a similar form.[4]
History
Although the ITU itself dates back to 1865,[1] the formal standardization processes are more recent. Two consultative committees were created by the ITUs 1925 Paris conference to deal with the complexities of the international telephone services (known as CCIF, as the French acronym) and long-distance telegraphy (CCIT).[5] In view of the basic similarity of many of the technical problems faced by the CCIF and CCIT, a decision was taken in 1956 to merge them to become the single International Telegraph and Telephone Consultative Committee (CCITT, in the French acronym).[5] In 1992, the Plenipotentiary Conference (the top policy-making conference of ITU) saw a reform of ITU, giving the Union greater flexibility to adapt to an increasingly complex, interactive and competitive environment. It was at this time that CCITT was renamed the Telecommunication Standardization Sector (ITU-T), as one of three Sectors of the Union alongside the Radiocommunication Sector (ITU-R) and the Telecommunication Development Sector (ITU-D).[6] Historically, the Recommendations of the CCITT were presented to four-yearly plenary assemblies for endorsement, and the full set of Recommendations were published after each plenary assembly. However, the delays in producing texts, and translating them into other working languages, did not suit the fast pace of change in the telecommunications industry.[7]
ITU-T In the work of standardization, ITU-T cooperates with other SDOs, e.g., the International Organization for Standardization (ISO) and the Internet Engineering Task Force (IETF).[14]
98
Development of Recommendations
Most of the work of ITU-T is carried out by its Sector Members and Associates, while the Telecommunication Standardization Bureau (TSB) is the executive arm of ITU-T and coordinator for a number of workshops and seminars to progress existing work areas and explore new ones. The events cover a wide array of topics in the field of information and communication technologies (ICT) and attract high-ranking experts as speakers, and attendees from engineers to high-level management from all industry sectors.[15] The technical work, the development of Recommendations, of ITU-T is managed by Study Groups (SGs). The people involved in these SGs are experts in telecommunications from all over the world. There are currently 13 SGs. Study groups meet face to face according to a calendar issued by the TSB.[16] SGs are augmented by Focus Groups (FGs), an instrument created by ITU-T, providing a way to quickly react to ICT standardization needs and allowing great flexibility in terms of participation and working methods. The key difference between SGs and FGs is that the latter have greater freedom to organize and finance themselves, and to involve non-members in their work. Focus Groups can be created very quickly, are usually short-lived and can choose their own working methods, leadership, financing, and types of deliverables.[17] Recent examples include work on Next Generation Networking, Internet Protocol Television (IPTV) and digital identity management.[18]
Approval of Recommendations
The Alternative Approval Process (AAP) is a fast-track approval procedure that was developed to allow standards to be brought to market in the timeframe that industry now demands. This dramatic overhaul of standards-making by streamlining approval procedures was implemented in 2001 and is estimated to have cut the time involved in this critical aspect of the standardization process by 80 to 90 per cent. This means that an average standard which took around four years to approve and publish until the mid nineties, and two years until 1997, can now be approved in an average of two months, or as little as five weeks. Besides streamlining the underlying procedures involved in the approval process, an important contributory factor to the use of AAP is electronic document handling. Once the approval process has begun the rest of the process can be completed electronically, in the vast majority of cases, with no further physical meetings. The introduction of AAP also formalizes public/private partnership in the approval process by providing equal opportunities for both Sector Members and Member States in the approval of technical standards. Once the text of a draft Recommendation prepared by SG experts is considered mature, it is submitted for review to an SG meeting. If agreed by the meeting it is given Consent. This means that the SG has given its consent that the text is sufficiently mature to initiate a final review process leading to approval of the draft Recommendation. After this Consent has been achieved, TSB announces the start of the AAP procedure by posting the draft text to the ITU-T web site and calling for comments. This gives the opportunity for all members to review the text. This phase, called Last Call, is a four-week period in which comments can be submitted by Member States and Sector Members. If no comments other than editorial corrections are received, the Recommendation is considered approved since no issues were identified that might need any further work. However, if there are any comments, the SG chairman, in consultation with TSB, sets up a comment resolution process by the concerned experts. The revised text is then posted on the web for an Additional Review period of three weeks. Similar to the Last Call phase, in Additional Review the Recommendation is considered as approved if no comments are received. If comments are received, it is apparent that there are some issues that still need more work, and the draft text and all comments are sent to the next Study Group meeting for further discussion and possible approval.[19]
ITU-T Those Recommendations considered as having policy or regulatory implications are approved through what is known as the Traditional Approval Process (TAP), which allows a longer period for reflection and commenting by Member States. TAP Recommendations are also translated into the six working languages of ITU (Arabic, Chinese, English, French, Russian and Spanish).[20]
99
ITU-T
100
X Y Z Data networks, open system communications and security Global information infrastructure, Internet protocol aspects and next-generation networks Languages and general software aspects for telecommunication systems
G Series Recommendations Transmission systems and media, digital systems and networks
Specification Range G.100 - G.199 G.200 - G.299 G.300 - G.399 G.400 - G.449 Specification Type
INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIERTRANSMISSION SYSTEMS INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON METALLIC LINES GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC LINES COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS DIGITAL TERMINAL EQUIPMENTS DIGITAL NETWORKS DIGITAL SECTIONS AND DIGITAL LINE SYSTEM QUALITY OF SERVICE AND PERFORMANCE GENERIC AND USER-RELATED ASPECTS TRANSMISSION MEDIA CHARACTERISTICS DATA OVER TRANSPORT GENERIC ASPECTS PACKET OVER TRANSPORT ASPECTS Ethernet over Transport aspects MPLS over Transport aspects Quality and availability targets Service Management ACCESS NETWORKS
G.450 - G.499 G.600 - G.699 G.700 - G.799 G.800 - G.899 G.900 - G.999 G.1000 - G.1999 G.6000 - G.6999 G.7000 - G.7999 G.8000 - G.8999 G.8000 - G.8099 G.8100 - G.8199 G.8200 - G.8299 G.8600 - G.8699 G.9000 - G.9999
Y Series Recommendations Global Information Infrastructure, Internet Protocol Aspects And Nextgeneration Networks
Specification Range GLOBAL INFORMATION INFRASTRUCTURE Y.100Y.199 Y.200Y.299 Y.300Y.399 Y.400Y.499 Y.500Y.599 Y.600Y.699 Y.700Y.799 Y.800Y.899 INTERNET PROTOCOL ASPECTS General Services, applications and middleware Network aspects Interfaces and protocols Numbering, addressing and naming Operation, administration and maintenance Security Performances Specification Type
ITU-T
101
Y.1000Y.1099 Y.1100Y.1199 Y.1200Y.1299 Y.1300Y.1399 Y.1400Y.1499 Y.1500Y.1599 Y.1600Y.1699 Y.1700Y.1799 Y.1800Y.1899 NEXT GENERATION NETWORKS Y.2000Y.2099 Y.2100Y.2199 Y.2200Y.2249 Y.2250Y.2299 Y.2300Y.2399 Y.2400Y.2499 Y.2500Y.2599 Y.2700Y.2799 Y.2800Y.2899 Frameworks and functional architecture models Quality of Service and performance Service aspects: Service capabilities and service architecture Service aspects: Interoperability of services and networks in NGN Numbering, naming and addressing Network management Network control architectures and protocols Security Generalized mobility General Services and applications Architecture, access, network capabilities and resource management Transport Interworking Quality of service and network performance Signalling Operation, administration and maintenance Charging
ITU-T
102
Hot topics
ITU-T is committed to bridging the standardization gap disparities in the ability of developing countries, relative to developed ones, to access, implement, contribute to and influence international ICT standards.[24] The ICT Security Standards Roadmap[25] has been developed to assist in the development of security standards by bringing together information about existing standards and current standards work in key standards development organizations. The Next Generation Networks (NGN) concept takes into consideration new realities in the telecommunication industry characterized by factors such as; the need to converge and optimize the operating networks and the extraordinary expansion of digital traffic (i.e., increasing demand for new multimedia services, mobility, etc.).
ITU-T
103
References
[1] "ITU's History" (http:/ / www. itu. int/ en/ history/ overview/ Pages/ history. aspx). International Telecommunication Union. . Retrieved 2011-03-20. [2] "About ITU" (http:/ / www. itu. int/ net/ about/ index. aspx). International Telecommunication Union. . Retrieved 2011-03-20. [3] ITU-T and TSB General Information (http:/ / www. itu. int/ ITU-T/ info/ index. html) [4] apdip.net (http:/ / www. apdip. net/ publications/ iespprimers/ eprimer-igov. pdf) (p13) [5] "CCITT - 50 YEARS OF EXCELLENCE - 1956-2006" (http:/ / www. itu. int/ ITU-T/ 50/ docs/ ITU-T_50. pdf). International Telecommunication Union. p. 8. . Retrieved 2011-03-20. [6] "CCITT - 50 YEARS OF EXCELLENCE - 1956-2006" (http:/ / www. itu. int/ ITU-T/ 50/ docs/ ITU-T_50. pdf). International Telecommunication Union. p. 14. . Retrieved 2011-03-20. [7] "CCITT - 50 YEARS OF EXCELLENCE - 1956-2006" (http:/ / www. itu. int/ ITU-T/ 50/ docs/ ITU-T_50. pdf). International Telecommunication Union. . Retrieved 2011-03-20. [8] "CCITT - 50 YEARS OF EXCELLENCE - 1956-2006" (http:/ / www. itu. int/ ITU-T/ 50/ docs/ ITU-T_50. pdf). International Telecommunication Union. p. 16. . Retrieved 2011-03-20. [9] ITU-T Standards now freely available online (http:/ / www. stanford. edu/ group/ eng/ blog/ 2007/ 09/ itut_standards_now_freely_avai. html) [10] Telecom Standards Newsletter, September 1 2007, Free access for all to ITU-T standards (http:/ / www. highbeam. com/ doc/ 1G1-169930353. html) [11] Free access for all to ITU-T standards (http:/ / www. itu. int/ ITU-T/ newslog/ Free+ Access+ For+ All+ To+ ITUT+ Standards. aspx) [12] ITU-T Recommendations overview (http:/ / www. itu. int/ en/ ITU-T/ publications/ Pages/ recs. aspx) [13] "CCITT - 50 YEARS OF EXCELLENCE - 1956-2006" (http:/ / www. itu. int/ ITU-T/ 50/ docs/ ITU-T_50. pdf). International Telecommunication Union. p. 17. . Retrieved 2011-03-20. [14] apdip.net (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf) (s10) [15] apdip.net (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf), (s13-16), General information on TSB (http:/ / www. itu. int/ ITU-T/ info/ tsb/ info. html) [16] apdip.net (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf), (s16), ITU-T Study Groups (Study Period 2009-2012) (http:/ / www. itu. int/ ITU-T/ studygroups/ index. html) [17] itu.int (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf), (s23-24), ITU-T Focus Groups (http:/ / www. itu. int/ ITU-T/ focusgroups/ index. html) [18] ITU Telecommunication Standardization Sector (ITU-T) - Focus Groups (http:/ / www. itu. int/ ITU-T/ focusgroups/ index. html) [19] itu.int (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf), (s28-29), ITU-T e-FLASH - Issue No. 22 (http:/ / www. itu. int/ ITU-T/ e-flash/ 022-jan06. html) [20] itu.int (http:/ / www. itu. int/ dms_pub/ itu-t/ oth/ 0A/ 0F/ T0A0F0000090001PDFE. pdf), (s27), ITU-T e-FLASH - Issue No. 22 (http:/ / www. itu. int/ ITU-T/ e-flash/ 022-jan06. html) [21] itu.int (http:/ / www. itu. int/ ITU-T/ itr/ files/ ITR-e. doc) [22] ITU-T - Review of the International Telecommunication Regulations (ITRs) (http:/ / www. itu. int/ ITU-T/ itr-eg/ ) [23] itu.int (http:/ / www. itu. int/ osg/ spu/ stratpol/ ITRs/ auth/ itr-03. doc) [24] itu.int (http:/ / www. itu. int/ ITU-T/ gap/ ) [25] itu.int (http:/ / www. itu. int/ ITU-T/ studygroups/ com17/ ict/ index. html)
External links
International Telecommunication Union (ITU) (official site) (http://www.itu.int/) ITU Standardization Sector (ITU-T) (http://www.itu.int/ITU-T/) ITU Radiocommunication Sector (ITU-R) (http://www.itu.int/ITU-R/) ITU Development Sector (ITU-D) (http://www.itu.int/ITU-D/) ITU-T Study Groups (http://www.itu.int/ITU-T/studygroups/) ITU-T Focus Groups (http://www.itu.int/ITU-T/focusgroups/index.html) ITU-T Recommendations (http://www.itu.int/ITU-T/publications/recs.html) ITU-T Newslog (RSS available) (http://www.itu.int/ITU-T/newslog/) ITU-T Guide for beginners (PDF) (http://www.itu.int/dms_pub/itu-t/oth/0A/0F/T0A0F0000090001PDFE. pdf) 50 years of CCITT/ITU-T (PDF) (http://www.itu.int/ITU-T/50/docs/ITU-T_50.pdf)
104
105
References
[1] [2] [3] [4] http:/ / portal. etsi. org/ Portal_IntegrateAppli/ QueryResult. asp?Alone=1& SortBy=& SortDirection=& Param= http:/ / www. etsi. org/ WebSite/ OurServices/ Forapolislandingpage. aspx http:/ / www. etsi. org/ WebSite/ document/ AR2010. pdf ETSI.org (http:/ / www. etsi. org/ WebSite/ Standards/ ETSIDeliverables. aspx)
External links
Official Website (http://www.etsi.org/) NORMAPME.com (http://www.normapme.com), The European Office of Crafts, Trades and Small and Medium sized Enterprises for Standardisation
106
The Internet Engineering Task Force (IETF) develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite. It is an open standards organization, with no formal membership or membership requirements. All participants and managers are volunteers, though their work is usually funded by their employers or sponsors; for instance, the current chairperson is funded by VeriSign and the U.S. government's National Security Agency.[2]
Organization
The IETF is organized into a large number of working groups and informal discussion groups (BoF)s, each dealing with a specific topic. Each group is intended to complete work on that topic and then disband. Each working group has an appointed chairperson (or sometimes several co-chairs), along with a charter that describes its focus, and what and when it is expected to produce. It is open to all who want to participate, and holds discussions on an open mailing list or at IETF meetings. The mailing list consensus is the final arbiter of decision-making. There is no voting procedure, as it operates on rough consensus process. The working groups are organized into areas by subject matter. Current areas include: Applications, General, Internet, Operations and Management, Real-time Applications and Infrastructure, Routing, Security, and Transport. Each area is overseen by an area director (AD), with most areas having two co-ADs. The ADs are responsible for appointing working group chairs. The area directors, together with the IETF Chair, form the Internet Engineering Steering Group (IESG), which is responsible for the overall operation of the IETF. The groups will normally be closed once the work described in its charter is finished. In some cases, the WG will instead have its charter updated to take on new tasks as appropriate. The IETF is formally a part of the Internet Society. The IETF is overseen by the Internet Architecture Board (IAB), which oversees its external relationships, and relations with the RFC Editor. The IAB is also jointly responsible for the IETF Administrative Oversight Committee (IAOC), which oversees the IETF Administrative Support Activity (IASA), which provides logistical, etc. support for the IETF. The IAB also manages the Internet Research Task Force (IRTF), with which the IETF has a number of cross-group relations.
107
History
The first IETF meeting was on January 16, 1986, consisting of 21 U.S.-government-funded researchers. It was a continuation of the work of the earlier GADS Task Force. Initially, it met quarterly, but from 1991, it has been meeting 3 times a year. Representatives from non-governmental entities were invited starting with the fourth IETF meeting, during October of that year. Since that time all IETF meetings have been open to the public. The majority of the IETF's work is done on mailing lists, and meeting attendance is not required for contributors. The initial meetings were very small, with fewer than 35 people in attendance at each of the first five meetings. The maximum attendance during the first 13 meetings was only 120 attendees. This occurred at the 12th meeting held during January 1989. These meetings have grown in both participation and scope a great deal since the early 1990s; it had a maximum attendance of almost 3000 at the December 2000 IETF held in San Diego, CA. Attendance declined with industry restructuring during the early 2000s, and is currently around 1200.[3] During the early 1990s the IETF changed institutional form from an activity of the U.S. government to an independent, international activity associated with the Internet Society.
Operations
The details of its operations have changed considerably as it has grown, but the basic mechanism remains publication of draft specifications, review and independent testing by participants, and republication. Interoperability is the chief test for IETF specifications becoming standards. Most of its specifications are focused on single protocols rather than tightly-interlocked systems. This has allowed its protocols to be used in many different systems, and its standards are routinely re-used by bodies which create full-fledged architectures (e.g. 3GPP IMS). Because it relies on volunteers and uses "rough consensus and running code" as its touchstone, results can be slow whenever the number of volunteers is either too small to make progress, or so large as to make consensus difficult, or when volunteers lack the necessary expertise. For protocols like SMTP, which is used to transport e-mail for a user community in the many hundreds of millions, there is also considerable resistance to any change that is not fully backwards compatible. Work within the IETF on ways to improve the speed of the standards-making process is ongoing but, because the number of volunteers with opinions on it is very great, consensus mechanisms on how to improve have been slow. Because the IETF does not have members (nor is it an organisation per se), the Internet Society provides the financial and legal framework for the activities of the IETF and its sister bodies (IAB, IRTF,...). Recently the IETF has set up an IETF Trust that manages the copyrighted materials produced by the IETF. IETF activities are funded by meeting fees, meeting sponsors and by the Internet Society via its organizational membership and the proceeds of the Public Interest Registry. IETF meetings vary greatly in where they are held. The list of past and future meeting locations can be found on the IETF meetings [4] page. The IETF has strived to hold the meetings near where most of the IETF volunteers are located. For a long time, the goal was 3 meetings a year, with 2 in North America and 1 in either Europe or Asia (alternating between them every other year). The goal ratio is currently, during a two year period, to have 3 in North America, 2 in Europe and 1 in Asia. However, corporate sponsorship of the meetings is typically a more important factor and this schedule has not been kept strictly in order to decrease operational costs.
108
Chairs
The IETF Chairperson is selected by the NOMCOM process specified in RFC 3777 for a 2-year term, renewable. Before 1993, the IETF Chair was selected by the IAB. Mike Corrigan (1986) Phill Gross (19861994) Paul Mockapetris (19941996) Fred Baker (19962001) Harald Tveit Alvestrand (20012005) Brian Carpenter (20052007) Russ Housley (2007)[5]
References
[1] http:/ / ietf. org [2] Duffy Marsan, Carolyn (July 26, 2007). "Q&A: Security top concern for new IETF chair" (http:/ / www. networkworld. com/ news/ 2007/ 073007-ietf-qa. html). Network World (IDG). . Retrieved 2008-04-20. [3] "Past Meetings of the IETF" (http:/ / www. ietf. org/ meetings/ past. meetings. html). . Retrieved 2008-08-05. [4] http:/ / www. ietf. org/ meeting/ [5] "IETF Chairs by year" (http:/ / www. ietf. org/ ietf_chairs_year. html). . Retrieved 2007-03-23.
External links
The official IETF site (http://ietf.org/) IETF Online Proceedings (http://www.ietf.org/old/2009/proceedings_directory.html) Early IETF Proceedings (http://www.ietf.org/old/2009/proceedings/directory2.html) (note: large pdf files, one for each volume) Past Meetings of the IETF (http://www.ietf.org/meeting/past.html) Past IESG Members and IETF Chairs (http://www.ietf.org/iesg/past-members.html) The Tao of the IETF (http://tools.ietf.org/rfcmarkup?doc=fyi17): details on how IETF is organized IAOC information (http://iaoc.ietf.org/) MyIETF (http://myietf.unfix.org) Personalized notification service on RFC's and drafts with full archive of old drafts etc.
109
History
The inception of the RFC format occurred in 1969 as part of the seminal ARPANET project.[1] Today, it is the official publication channel for the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), andto some extentthe global community of computer network researchers in general. The authors of the first RFCs typewrote their work and circulated hard copies among the ARPA researchers. Unlike the modern RFCs, many of the early RFCs were requests for comments. The RFC leaves questions open and is written in a less formal style. This less formal style is now typical of Internet Draft documents, the precursor step before being approved as an RFC. In December 1969, researchers began distributing new RFCs via the newly operational ARPANET. RFC 1, entitled "Host Software", was written by Steve Crocker of the University of California, Los Angeles (UCLA), and published on April 7, 1969. Although written by Steve Crocker, the RFC emerged from an early working group discussion between Steve Crocker, Steve Carr and Jeff Rulifson. In RFC 3, which first defined the RFC series, Crocker started attributing the RFC series to the "Network Working Group". This wasn't so much a formal committee as a loose association of researchers interested in the ARPANET project. In effect, it was anyone who wanted to join in on meetings and discussions about the project. Many of the subsequent RFCs of the 1970s also came from UCLA, because UCLA was one of the first Interface Message Processors (IMPs) on ARPANET. The Augmentation Research Center (ARC) at Stanford Research Institute, directed by Douglas Engelbart, was another of the four first ARPANET nodes and the source of early RFCs. The ARC became the first Network Information Center, which was managed by Elizabeth J. Feinler to distribute them along with other network information. From 1969 until 1998, Jon Postel served as the RFC editor. (On his death in 1998, his obituary was published as RFC 2468.) Following the expiration of the original ARPANET contract with the U.S. federal government, the Internet Society (acting on behalf of the IETF) contracted with the Networking Division of the University of Southern California (USC) Information Sciences Institute (ISI) to assume the editorship and publishing responsibilities (under the direction of the IAB). Sandy Ginoza joined USC/ISI in 1999 to work on RFC editing, and Alice Hagens in 2005.[2] Bob Braden took over the role of RFC project lead, while Joyce K. Reynolds continued to be part of the team until October 13, 2006. In July 2007, "streams" of RFCs were defined, so the editing duties could be divided. IETF documents came from IETF working groups or submissions sponsored by an IETF area director from the Internet Engineering Steering Group. The IAB can publish its own documents. A research stream of documents comes from the Internet Research Task Force (IRTF), and and independent stream includes documents from other outside sources.[3] A new model was proposed in 2008, refined, and published in August 2009, splitting the task into several roles.[4] The streams were also refined in December 2009, with standards defined for their style.[5] In January 2010 the RFC editor function was moved to a contractor, Association Management Solutions with Glenn Kowack serving as interim series editor.[6]
110
Sub-series
The RFC series contains three sub-series for IETF RFCs: BCP Best Current Practice; mandatory IETF RFCs not on standards track, see below. FYI For Your Information; informational RFCs promoted by the IETF as specified in RFC 1150 (FYI1). In 2011 RFC 6360 obsoleted FYI1 and concluded this sub-series. STD Standard; this used to be the third and highest maturity level of the IETF standards track specified in RFC 2026 (BCP9). In 2011 RFC 6410 (a new part of BCP9) reduced the standards track to two maturity levels.
Streams
There are four streams of RFCs: (1) IETF, (2) IRTF, (3) IAB, and (4) independent submission. Only the IETF creates BCPs and RFCs on standards track. An independent submission is checked by the IESG for conflicts with IETF work; the quality is assessed by an independent submission editorial board. In other words, IRTF and independent RFCs are supposed to contain relevant info or experiments for the Internet at large not in conflict with IETF work, compare RFC 4846, RFC 5742, and RFC 5744.
111
Obtaining RFCs
The official source for RFCs on the World Wide Web is the RFC Editor [8]. Almost any individual published RFC, for example RFC 5000, can be retrieved via the URL: http://www.rfc-editor.org/rfc/rfc5000.txt Every RFC is submitted as plain ASCII text and is published in that form, but may also be available in other formats. However, as of 2008 the definitive version of any standards-track specification is the ASCII version. For easy access to the metadata of an RFC, including abstract, keywords, author(s), publication date, errata, status, and especially later updates, the RFC Editor site offers a search form with many features. A redirection sets some efficient parameters, example: http://purl.net/net/rfc/5000 [9] The official International Standard Serial Number (ISSN) of the RFC series is 2070-1721.[5]
Status
Not all RFCs are standards.[10] Each RFC is assigned a designation with regard to status within the Internet standardization process. This status is one of the following: Informational, Experimental, Best Current Practice (BCP), Standards Track, or Historic (sic). Standards-track documents are further divided into Proposed Standard, Draft Standard, and Internet Standard documents. The term Historic is applied to deprecated standards-track documents or obsolete RFCs that were published before the standards track was established. Only the IETF, represented by the Internet Engineering Steering Group (IESG), can approve standards-track RFCs. Each RFC is static; if the document is changed, it is submitted again and assigned a new RFC number. If an RFC becomes an Internet Standard (STD), it is assigned an STD number but retains its RFC number; however, when an Internet Standard is updated, its number stays the same and it simply refers to a different RFC or set of RFCs. A given Internet Standard, STD n, may be RFCs x and y at a given time, but later the same standard may be updated to be RFC z instead. For example, in 2007 RFC 3700 was an Internet StandardSTD 1and in May 2008 it was replaced with RFC 5000, so RFC 3700 changed to Historic, RFC 5000 became an Internet Standard, and as of May 2008 STD 1 is RFC 5000. When STD 1 is updated again, it will simply refer to a newer RFC that will have completed the standards track, but it will still be STD 1. Best Current Practices work in a similar fashion; BCP n refers to a certain RFC or set of RFCs, but which RFC or RFCs may change over time. The definitive list of Internet Standards is itself an Internet Standard, STD 1: Internet Official Protocol Standards.[11]
Status "informational"
An informational RFC can be nearly anything from April 1 jokes over proprietary protocols up to widely recognized essential RFCs like Domain Name System Structure and Delegation (RFC 1591). Some informational RFCs formed the FYI sub-series. Some old FYIs are still interesting, e.g., the Internet User's Glossary RFC 1983 (FYI 18), and The Tao of IETF RFC 4677 (FYI 17).
Status "experimental"
An experimental RFC can be an IETF document or an individual submission to the 'RFC Editor'. In theory it is indeed experimental; in practice some documents are not promoted on standards track because there are no volunteers for the procedural details.
112
Status "historic"
A historic RFC is one that has been made obsolete by a newer version, documents a protocol that is not considered interesting in the current Internet, or has been removed from the standards track for other reasons. Some obsolete RFCs are not classified as historic, because the Internet standards process generally does not allow normative references from a standards track RFC to another RFC with lower status. Also, few are interested in working through the required procedural details to get RFCs classified as historic and update all RFCs normatively depending on it.
Status "unknown"
Status unknown is used for some very old RFCs, where it is unclear which status the document would get if it were published today. Some of these RFCs would not be published at all today; an early RFC was often just that: a simple request for comments, not intended to specify a protocol, administrative procedure, or anything else for which the RFC series is used today.
References
[1] Stephen D. Crocker, How the Internet Got Its Rules, The New York Times, 6 April 2009 (http:/ / www. nytimes. com/ 2009/ 04/ 07/ opinion/ 07crocker. html?_r=1& em) [2] Leslie Daigle (March 2010). "RFC Editor in Transition: Past, Present, and Future" (http:/ / www. cisco. com/ web/ about/ ac123/ ac147/ archived_issues/ ipj_13-1/ 131_rfc. html). The Internet Protocol Journal (Cisco Systems) 13 (1). . Retrieved August 17, 2011. [3] Leslie Diagle (July 2007). "The RFC Series and RFC Editor" (http:/ / tools. ietf. org/ html/ rfc4844). RFC 4844. . Retrieved August 17, 2011. [4] O. Kolkman, Ed (August 2009). "RFC Editor Model (Version 1)". RFC 5620. [5] Leslie Diagle, Olaf Kolkman (December 2009). "RFC Streams, Headers, and Boilerplates" (http:/ / tools. ietf. org/ html/ rfc5741). RFC 5741. . Retrieved August 17, 2011. [6] Glenn Kowack (January7, 2010). "RFC Editor Transition Announcement" (http:/ / www. ietf. org/ ibin/ c5i?mid=6& rid=49& gid=0& k1=934& k2=7324& tid=1263251951). . Retrieved August 7, 2011. [7] "RFC Index" (http:/ / www. rfc-editor. org/ rfc-index2. html). RFC Editor. 2008-05-25. . Retrieved 2008-05-26. [8] http:/ / www. rfc-editor. org/ rfc. html [9] http:/ / purl. net/ net/ rfc/ 5000 [10] Huitema, C.; Postel, J.; Crocker, S. (April 1995). "Not All RFCs are Standards (RFC 1796)" (http:/ / tools. ietf. org/ html/ rfc1796). The Internet Engineering Task Force. . Retrieved 2008-05-19. "[E]ach RFC has a status: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic." [11] "Internet Official Protocol Standards (STD 1)" (ftp:/ / ftp. rfc-editor. org/ in-notes/ std/ std1. txt) (plain text). RFC Editor. May 2008. . Retrieved 2011-04-26. [12] Scott O. Bradner (October 1996). "RFC 2026: The Internet Standards Process Revision 3" (http:/ / tools. ietf. org/ html/ rfc2026). BCP 9 (http:/ / tools. ietf. org/ html/ bcp9). IETF. . Retrieved 2011-10-31. [13] http:/ / tools. ietf. org/ html/ bcp38
113
External links
RFC Editor (http://www.rfc-editor.org/) RFC Database (http://www.rfc-editor.org/rfc.html) RFC Errata (http://www.rfc-editor.org/errata.php) RFC Frequently Asked Questions (http://www.rfc-editor.org/rfcfaq.html) RFC Index (http://www.rfc-editor.org/rfc-index2.html) (text) Official RFC standardization status (http://www.rfc-editor.org/rfcxx00.html) IETF's RFC page (http://www.ietf.org/rfc.html) RFC Index (http://tools.ietf.org/rfc/) (HTML) With the text of each RFC, also mentions what other RFCs this one "updates" or is "updated by". This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
History
The IEEE is incorporated under the Not-for-Profit Corporation Law of the state of New York in the United States.[3] It was formed in 1963 by the merger of the Institute of Radio Engineers (IRE, founded 1912) and the American Institute of Electrical Engineers (AIEE, founded 1884). The major interests of the AIEE were wire communications (telegraphy and telephony) and light and power systems. The IRE concerned mostly radio engineering, and was formed from two smaller organizations, the Society of Wireless and Telegraph Engineers and the Wireless Institute. With the rise of electronics in the 1930s, electronics engineers usually became members of the IRE, but the applications of electron tube technology became so extensive that the technical boundaries differentiating the IRE and the AIEE became difficult to distinguish. After World War II, the two organizations became increasingly competitive, and in 1961, the leadership of both the IRE and the AIEE resolved to consolidate the two organizations. The two organizations formally merged as the IEEE on January 1, 1963. Notable Presidents of IEEE and its founding organizations include Elihu Thomson (AIEE, 18891890), Alexander Graham Bell (AIEE, 18911892), Charles Proteus Steinmetz (AIEE, 19011902), Lee De Forest (IRE, 1930), Frederick E. Terman (IRE, 1941), William R. Hewlett (IRE, 1954), Ernst Weber (IRE, 1959; IEEE, 1963), and Ivan Getting (IEEE, 1978). IEEE's Constitution defines the purposes of the organization as "scientific and educational, directed toward the advancement of the theory and practice of Electrical, Electronics, Communications and Computer Engineering, as well as Computer Science, the allied branches of engineering and the related arts and sciences."[4] In pursuing these goals, the IEEE serves as a major publisher of scientific journals and organizer of conferences, workshops, and symposia (many of which have associated published proceedings). It is also a leading standards development organization for the development of industrial standards (having developed over 900 active industry technical standards) in a broad range of disciplines, including electric power and energy, biomedical technology and healthcare, information technology, information assurance, telecommunications, consumer electronics,
Institute of Electrical and Electronics Engineers transportation, aerospace, and nanotechnology. IEEE develops and participates in educational activities such as accreditation of electrical engineering programs in institutes of higher learning. The IEEE logo is a diamond-shaped design which illustrates the right hand grip rule embedded in Benjamin Franklin's kite, and it was created at the time of the 1963 merger. [5] IEEE has a dual complementary regional and technical structure - with organizational units based on geography (e.g., the IEEE Philadelphia Section, IEEE South Africa Section [6]) and technical focus (e.g., the IEEE Computer Society). It manages a separate organizational unit (IEEE-USA) which recommends policies and implements programs specifically intended to benefit the members, the profession and the public in the United States. The IEEE includes 38 technical Societies, organized around specialized technical fields, with more than 300 local organizations that hold regular meetings. The IEEE Standards Association is in charge of the standardization activities of the IEEE.
114
Publications
IEEE produces 30% of the world's literature in the electrical and electronics engineering and computer science fields, publishing well over 100 peer-reviewed journals.[7] The published content in these journals as well as the content from several hundred annual conferences sponsored by the IEEE are available in the IEEE online digital library for subscription-based access and individual publication purchases.[8] In addition to journals and conference proceedings, the IEEE also publishes tutorials and the standards that are produced by its standardization committees.
Educational activities
The IEEE provides learning opportunities within the engineering sciences, research, and technology. The goal of the IEEE education programs is to ensure the growth of skill and knowledge in the electricity-related technical professions and to foster individual commitment to continuing education among IEEE members, the engineering and scientific communities, and the general public. IEEE offers educational opportunities such as IEEE eLearning Library,[9] the Education Partners Program,[10] Standards in Education[11] and Continuing Education Units (CEUs).[12]
works in the District University of Bogot, IEEE eLearning Library is a collection of online educational courses Colombia. designed for self-paced learning. Education Partners, exclusive for IEEE members, offers on-line degree programs, certifications and courses at a 10% discount. The Standards in Education website explains what standards are and the importance of developing and using them. The site includes tutorial modules and case illustrations to introduce the history of standards, the basic terminology, their applications and impact on products, as well as news related to standards, book reviews and links to other sites that contain information on standards. Currently, twenty-nine states in the United States require Professional Development Hours (PDH) to maintain a Professional Engineering license, encouraging engineers to seek Continuing Education Units (CEUs) for their participation in continuing education programs. CEUs readily translate into Professional Development Hours (PDHs), with 1 CEU being equivalent to 10 PDHs. Countries outside the United States, such as South Africa, similarly require continuing professional development (CPD) credits, and it is anticipated that IEEE Expert Now courses will feature in the CPD listing for South Africa.
Institute of Electrical and Electronics Engineers IEEE also sponsors a website[13] designed to help young people understand better what engineering means, and how an engineering career can be made part of their future. Students of age 818, parents, and teachers can explore the site to prepare for an engineering career, ask experts engineering-related questions, play interactive games, explore curriculum links, and review lesson plans. This website also allows students to search for accredited engineering degree programs in Canada and the United States; visitors are able to search by state/province/territory, country, degree field, tuition ranges, room and board ranges, size of student body, and location (rural, suburban, or urban).
115
Institute of Electrical and Electronics Engineers Honorary Members: Individuals who are not IEEE members but have demonstrated exceptional contributions, such as being a recipient of an IEEE Medal of Honor, may receive Honorary Membership from the IEEE Board of Directors. Life Members and Life Fellows: Members who have reached the age of 65 and whose number of years of membership plus their age in years adds up to at least 100 are recognized as Life Members and, in the case of Fellow members, as Life Fellows.
116
Awards
Through its awards program, the IEEE recognizes contributions that advance the fields of interest to the IEEE. For nearly a century, the IEEE Awards Program has paid tribute to technical professionals whose exceptional achievements and outstanding contributions have made a lasting impact on technology, society and the engineering profession. Funds for the awards program, other than those provided by corporate sponsors for some awards, are administered by the IEEE Foundation.
Medals
IEEE Medal of Honor IEEE Edison Medal IEEE Founders Medal (for leadership, planning, and administration) IEEE James H. Mulligan, Jr. Education Medal IEEE Alexander Graham Bell Medal (for communications engineering) IEEE Simon Ramo Medal (for systems engineering) IEEE Medal for Engineering Excellence IEEE Medal for Environmental and Safety Technologies IEEE Medal in Power Engineering IEEE Richard W. Hamming Medal (for information technology) IEEE Heinrich Hertz Medal (for electromagnetics) IEEE John von Neumann Medal (for computer-related technology) IEEE Jack S. Kilby Signal Processing Medal IEEE Dennis J. Picard Medal for Radar Technologies and Applications IEEE Robert N. Noyce Medal (for microelectronics) IEEE Medal for Innovations in Healthcare Technology IEEE/RSE Wolfson James Clerk Maxwell Award IEEE Centennial Medal
Institute of Electrical and Electronics Engineers IEEE Reynold B. Johnson Data Storage Device Technology Award IEEE Reynold B. Johnson Information Storage Systems Award IEEE Richard Harold Kaufmann Award (for industrial systems engineering) IEEE Joseph F. Keithley Award in Instrumentation and Measurement IEEE Gustav Robert Kirchhoff Award (for electronic circuits and systems) IEEE Leon K. Kirchmayer Graduate Teaching Award IEEE Koji Kobayashi Computers and Communications Award IEEE William E. Newell Power Electronics Award IEEE Daniel E. Noble Award (for emerging technologies) IEEE Donald O. Pederson Award in Solid-State Circuits IEEE Frederik Philips Award (for management of research and development) IEEE Photonics Award IEEE Emanuel R. Piore Award (for information processing systems in computer science) IEEE Judith A. Resnik Award (for space engineering) IEEE Robotics and Automation Award IEEE Frank Rosenblatt Award (for biologically and linguistically motivated computational paradigms such as neural networks IEEE David Sarnoff Award (for electronics) IEEE Charles Proteus Steinmetz Award (for standardization) IEEE Marie Sklodowska-Curie Award (for nuclear and plasma engineering) IEEE Eric E. Sumner Award (for communications technology) IEEE Undergraduate Teaching Award IEEE Nikola Tesla Award (for power technology) IEEE Kiyo Tomiyasu Award (for technologies holding the promise of innovative applications)
117
Recognitions
IEEE Haraden Pratt Award IEEE Richard M. Emberson Award IEEE Corporate Innovation Recognition IEEE Ernst Weber Engineering Leadership Recognition IEEE Honorary Membership
Scholarships
IEEE Life Members Graduate Study Fellowship in Electrical Engineering was established by the IEEE in 2000. The fellowship is awarded annually to a first year, full time graduate student obtaining their masters for work in the area of electrical engineering, at an engineering school/program of recognized standing worldwide.[14] IEEE Charles LeGeyt Fortescue Graduate Scholarship was established by the IRE in 1939 to commemorate Charles Legeyt Fortescue's contributions to electrical engineering. The scholarship is awarded for one year of full-time graduate work obtaining their masters in electrical engineering an ANE engineering school of recognized standing in the United States.[15]
118
Societies
IEEE is supported by 38 societies, each one focused on a certain knowledge area. They provide specialized publications, conferences, business networking and sometimes other services.[16] [17]
IEEE Aerospace and Electronic Systems Society IEEE Antennas & Propagation Society IEEE Broadcast Technology Society IEEE Circuits and Systems Society IEEE Communications Society IEEE Computational Intelligence Society IEEE Computer Society IEEE Consumer Electronics Society IEEE Control Systems Society IEEE Dielectrics & Electrical Insulation Society IEEE Education Society IEEE Electromagnetic Compatibility Society IEEE Electron Devices Society IEEE Engineering in Medicine and Biology Society IEEE Geoscience and Remote Sensing Society IEEE Industrial Electronics Society IEEE Industry Applications Society IEEE Information Theory Society IEEE Instrumentation & Measurement Society IEEE Intelligent Transportation Systems Society IEEE Magnetics Society IEEE Microwave Theory and Techniques Society IEEE Nuclear and Plasma Sciences Society IEEE Oceanic Engineering Society IEEE Photonics Society IEEE Power Electronics Society IEEE Power & Energy Society IEEE Product Safety Engineering Society IEEE Professional Communication Society IEEE Reliability Society IEEE Robotics and Automation Society IEEE Signal Processing Society IEEE Society on Social Implications of Technology IEEE Solid-State Circuits Society IEEE Systems, Man & Cybernetics Society IEEE Ultrasonics, Ferroelectrics & Frequency Control Society IEEE Vehicular Technology Society
Technical councils
IEEE technical councils are collaborations of several IEEE societies on a broader knowledge area. There are currently seven technical councils:[16] [18] IEEE Biometrics Council IEEE Council on Electronic Design Automation IEEE Nanotechnology Council IEEE Sensors Council IEEE Council on Superconductivity IEEE Systems Council IEEE Technology Management Council
Technical committees
To allow a quick response to new innovations, IEEE can also organize technical committees on top of their societies and technical councils. There are currently two such technical committees:[16] IEEE Committee on Earth Observation (ICEO) IEEE Technical Committee on RFID (CRFID)
Organizational units
Technical Activities Board (TAB)
119
IEEE Foundation
The IEEE Foundation is a charitable foundation established in 1973 to support and promote technology education, innovation and excellence.[19] It is incorporated separately from the IEEE, although it has a close relationship to it. Members of the Board of Directors of the foundation are required to be active members of IEEE, and one third of them must be current or former members of the IEEE Board of Directors. Initially, the IEEE Foundation's role was to accept and administer donations for the IEEE Awards program, but donations increased beyond what was necessary for this purpose, and the scope was broadened. In addition to soliciting and administering unrestricted funds, the foundation also administers donor-designated funds supporting particular educational, humanitarian, historical preservation, and peer recognition programs of the IEEE.[19] As of the end of 2009, the foundation's total assets were $27 million, split equally between unrestricted and donor-designated funds.[20]
Copyright policy
The IEEE requires authors to transfer their copyright for works they submit for publication.[21] [22] The IEEE generally does not create its own research. It is a professional organization that coordinates journal peer-review activities and holds subject-specific conferences in which authors present their research. The IEEE then publishes the authors' papers in journals and other proceedings, and authors are required to give up their exclusive rights to their works.[21] Section 6.3.1 IEEE Copyright Policies subsections 7 and 8 states that "all authorsshall transfer to the IEEE in writing any copyright they hold for their individual papers", but that the IEEE will grant the authors permission to make copies and use the papers they originally authored, so long as such use is permitted by the Board of Directors. The guidelines for what the Board considers a "permitted" use are not entirely clear, although posting a copy on a personally-controlled website is allowed. The author is also not allowed to change the work absent explicit approval from the organization. The IEEE justifies this practice in the first paragraph of that section, by stating that they will "serve and protect the interests of its authors and their employers".[21] [22] The IEEE places research papers and other publications such as IEEE standards behind a "pay wall"[21] , although the IEEE explicitly allows authors to make a copy of the papers that they authored freely available on their own website. As of September 2011, the IEEE also provides authors for most new journal papers with the option to pay to allow free download of their papers by the public from the IEEE publication website.[23] IEEE publications have received a Green[24] rating the from SHERPA/RoMEO guide[25] for affirming "authors and/or their companies shall have the right to post their IEEE-copyrighted material on their own servers without permission" (IEEE Publication Policy 8.1.9.D[26] ). This open access policy effectively allows authors, at their choice, to make their article openly available. Roughly 1/3 of the IEEE authors take this route . Some other professional associations do not impose the same requirements on authors. For example, the USENIX association[21] requires that the author only give up the right to publish the paper elsewhere for 12 months (in addition to allowing authors to post copies of the paper on their own website during that time). The organization operates successfully even though all of its publications are freely available online.[21]
120
References
[1] "IEEE at a Glance > IEEE Quick Facts" (http:/ / www. ieee. org/ about/ today/ at_a_glance. html#sect1). IEEE. December 31, 2010. . Retrieved March 7, 2011. [2] "IEEE 2009 Annual Report" (http:/ / www. ieee. org/ documents/ ieee_annual_report_09_complete. pdf). IEEE. October 2010. . Retrieved November 11, 2010. [3] "IEEE Technical Activities Board Operations Manual" (http:/ / www. ieee. org/ about/ volunteers/ tab_operations_manual. pdf). IEEE. . Retrieved November 10, 2010., section 1.1 IEEE Incorporation [4] "IEEE Technical Activities Board Operations Manual" (http:/ / www. ieee. org/ about/ volunteers/ tab_operations_manual. pdf). IEEE. . Retrieved December 7, 2010., section 1.3 Technical activities objectives [5] "IEEE - Master Brand and Logos" (http:/ / www. ieee. org/ about/ toolkit/ masterbrand/ index. html). www.ieee.org. . Retrieved 2011-01-28. [6] http:/ / www. ieee. org. za [7] About IEEE (http:/ / www. ieee. org/ about/ ) [8] IEEE's online digital library (http:/ / ieeexplore. ieee. org) [9] IEEE - IEEE Expert Now (http:/ / www. ieee. org/ publications_standards/ publications/ subscriptions/ prod/ elearning_overview. html) [10] IEEE - IEEE Education Partners Program (http:/ / www. ieee. org/ web/ education/ partners/ eduPartners. html) [11] IEEE - The IEEE Standards Education pages have moved (http:/ / www. ieee. org/ portal/ cms_docs/ education/ setf/ index. html) [12] IEEE - IEEE Continuing Education Units (http:/ / www. ieee. org/ web/ education/ ceus/ index. html) [13] Welcome to TryEngineering.org (http:/ / www. tryengineering. org/ ) [14] IEEE Life Member Graduate Study Fellowship (http:/ / www. ieee. org/ portal/ pages/ about/ awards/ sums/ lmfellow1. html). Retrieved on 2010-01-23. [15] Charles LeGeyt Fortescue Graduate Scholarship (http:/ / www. ieee. org/ portal/ pages/ about/ awards/ sums/ fortescue. html). Retrieved on 2010-01-23. [16] "IEEE Societies & Communities" (http:/ / www. ieee. org/ societies_communities/ index. html). IEEE. . Retrieved November 7, 2010. [17] "IEEE Society Memberships" (http:/ / www. ieee. org/ web/ membership/ societies/ index. html). IEEE. . Retrieved November 7, 2010. [18] "IEEE Technical Councils" (http:/ / www. ieee. org/ societies_communities/ societies/ about_technical_councils. html). IEEE. . Retrieved November 8, 2010. [19] IEEE Foundation Home page (http:/ / www. ieee. org/ organizations/ foundation/ index. html) [20] IEEE Foundation Overview page (http:/ / www. ieee. org/ organizations/ foundation/ overview. html) [21] Johns, Chris (March 12, 2011). "Matt Blazes criticism of the ACM and the IEEE" (http:/ / www. ipbrief. net/ 2011/ 03/ 12/ shaking-down-science-matt-blazes-criticism-of-the-acm-and-the-ieee/ ). Washington College of Law Intellectual Property Brief (American University). . Retrieved 2011-04-17. This section uses content available under the CC-BY-SA 3.0 License. The American University Washington College of Law Intellectual Property Brief is licensed by Dan Rosenthal under a Creative Commons Attribution 3.0 United States License and hosted by Dan Rosenthal (http:/ / creativecommons. org/ licenses/ by/ 3. 0/ us/ ). [22] "6.3.1 IEEE Copyright Policies" (http:/ / www. ieee. org/ publications_standards/ publications/ rights/ copyrightpolicy. html) (Available online). IEEE. 2011. . Retrieved 2011-04-17. [23] Davis, Amanda, Most IEEE Journals are now Open Access (http:/ / theinstitute. ieee. org/ briefings/ business/ most-ieee-journals-are-now-openaccess), The Institute, October 7, 2011. [24] Sherpa Romeo color code (http:/ / www. sherpa. ac. uk/ romeoinfo. html#colours) [25] Sherpa Romeo site (http:/ / www. sherpa. ac. uk/ romeo. php) [26] IEEE Publication Policy 8.1.9.D (http:/ / www. ieee. org/ web/ publications/ rights/ policies. html)
External links
Official IEEE website (http://www.ieee.org/) IEEE Global History Network (http://www.ieeeghn.org/) a wiki-based website containing information about the history of IEEE, its members, their professions, and their technologies. IEEE Xplore (http://ieeexplore.ieee.org/) the IEEE Xplore Digital Library, with over 2.6 million technical documents available online for purchase. IEEE.tv (http://ieee.tv/) a video content website operated by the IEEE. IEEE eLearning Library (http://ieee-elearning.org/) an online library of more than 200 self-study multimedia short courses and tutorials in technical fields of interest to the IEEE.
121
Session description
A session is described by a series of fields, one per line.[3] The form of each field is as follows. <character>=<value> Where <character> is a single case-significant character and value is structured text whose format depends upon attribute type. Values are typically a UTF-8 encoding.[4] Whitespace is not allowed immediately to either side of the =.[5] Within an SDP message there are three main sections, detailing the session, timing, and media descriptions. Each message may contain multiple timing and media descriptions. Names are only unique within the associated syntactic construct, i.e. within the session, time, or media.[6] Optional values are specified with =* and each field must appear in the order shown below. Session description v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection informationnot required if included in all media) b=* (zero or more bandwidth information lines) One or more time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) Media description, if present m= (media name and transport address)
Session Description Protocol i=* (media title) c=* (connection informationoptional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines)
122
Attributes
SDP uses attributes to extend the core protocol. Attributes can appear within the Session or Media sections and are scoped accordingly as session-level or media-level. New attributes are added to the standard occasionally through registration with IANA.[7] Attributes take two forms: A property form: a=<flag> conveys a property of the session. A value form: a=<attribute>:<value> provides a named parameter.
Time Formats
Absolute times are represented in Network Time Protocol format (the number of seconds since 1900). If the stop time is 0 then the session is "unbounded." If the start time is also zero then the session is considered "permanent." Unbounded and permanent sessions are discouraged but not prohibited. Intervals can be represented with Network Time Protocol times or in typed time: a value and time units (days ('d'), hours ('h'), minutes ('m') and seconds ('s')) sequence. Thus an hour meeting from 10am on 1 August 2010, with a single repeat time a week later at the same time can be represented as: t=3487140000 3487143600 r=604800 3600 0 Or using typed time: t=3487140000 3487143600 r=7d 3600 0
Notes
[1] Handley, Mark; Van Jacobson (1998-04). "SDP: Session Description Protocol (RFC 2327)" (http:/ / tools. ietf. org/ html/ rfc2327). IETF. . Retrieved 2008-04-19. [2] Handley, Mark; Van Jacobson, Colin Perkins (2006-07). "SDP: Session Description Protocol (RFC 4566)" (http:/ / tools. ietf. org/ html/ rfc4566). IETF. . Retrieved 2008-04-19. [3] Each line is separated from the next by a carriage return/line feed sequence. Implementations are allowed to relax this to omit the carriage return and supply only the line feed. [4] session information and session name values are subject to the encoding specified in any charset attribute of the section. [5] RFC 4566 Section 5 [6] An In-Depth Overview of SDP (http:/ / www. konnetic. com/ Documents/ KonneticSDPTechnicalOverview. pdf) [7] Internet Assigned Numbers Authority SDP site (http:/ / www. iana. org/ assignments/ sdp-parameters)
123
124
125
126
127
128
License
129
License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/