Multimedia Communication

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]

Basic requirements of protocols

Messages are sent and received on communicating systems to establish communications. Protocols should therefore specify rules governing the transmission. In general, much of the following should be addressed:[12] Data formats for data exchange. Digital message bitstrings are exchanged. The bitstrings are divided in fields and each field carries information relevant to the protocol. Conceptually the bitstring is divided into two parts called the header area and the data area. The actual message is stored in the data area, so the header area contains the fields with more relevance to the protocol. Bitstrings longer than the maximum transmission unit (MTU) are divided in pieces of appropriate size.[13] Address formats for data exchange. Addresses are used to identify both the sender and the intended receiver(s). The addresses are stored in the header area of the bitstrings, allowing the receivers to determine whether the bitstrings are intended for themselves and should be processed or should be ignored. A connection between a sender and a receiver can be identified using an address pair (sender address, receiver address). Usually some address values have special meanings. An all-1s address could be taken to mean an addressing of all stations on the network, so sending to this address would result in a broadcast on the local network. The rules describing the meanings of the address value are collectively called an addressing scheme.[14] Address mapping. Sometimes protocols need to map addresses of one scheme on addresses of another scheme. For instance to translate a logical IP address specified by the application to an Ethernet hardware address. This is

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).

Protocols and programming languages

Protocols are to communications what algorithms or programming languages are to computations.[23] [1] This analogy has important consequences for both the design and the development of protocols. One has to consider the fact that algorithms, programs and protocols are just different ways of describing expected behaviour of interacting objects. A familiar example of a protocolling language is the HTML language used to describe web pages which are the actual web protocols. In programming languages the association of identifiers to a value is termed a definition. Program text is structured using block constructs and definitions can be local to a block. The localized association of an identifier to a value established by a definition is termed a binding and the region of program text in which a binding is effective is known as its scope.[24] The computational state is kept using two components: the environment, used as a record of identifier bindings, and the store, which is used as a record of the effects of assignments.[25]

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

A basis for protocol design

Systems 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] To cooperate the protocols have to communicate with each other, so some kind of conceptual framework is needed to make this communication possible. Also note that software is needed to implement both the 'xfer-mechanism' and a protocol (no protocol, no communication). In literature there are numerous references to the analogies between computer communication and programming. By analogy we could say that the aforementioned 'xfer-mechanism' is comparable to a cpu; a 'xfer-mechanism' performs communications and a cpu performs computations and the 'framework' introduces something that allows the protocols to be designed independent of one and another by providing separate execution environments for the protocols. Furthermore, it is repeatedly stated that protocols are to computer communication what programming languages are to computation.[35] [36]

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.

The need for protocol standards

The need for protocol standards can be shown by looking at what happened to the bi-sync protocol (BSC) invented by IBM. BSC is an early link-level protocol used to connect two separate nodes. It was originally not intended to be used in a multinode network, but doing so revealed several deficiencies of the protocol. In the absence of standardization, manufacturers and organizations felt free to 'enhance' the protocol, creating incompatible versions on their networks. In some cases, this was deliberately done to discourage users from using equipment from other manufacturers. There are more than 50 variants of the original bi-sync protocol. One can assume, that a standard would have prevented at least some of this from happening.[6] In some cases, protocols gain market dominance without going through a standardization process. Such protocols are referred to as de facto standards. De facto standards are common on emerging markets, niche markets, or markets that are monopolized (or oligopolized). They can hold a market in a very negative grip, especially when used to scare away competition. From a historical perspective, standardization should be seen as a measure to counteract the ill-effects of de facto standards. Positive exceptions exist; a 'de facto standard' operating system like GNU/Linux does not have this negative grip on its market, because the sources are published and maintained in an open way, thus inviting competition. Standardization is therefore not the only solution for open systems interconnection.

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]

The standardization process

The standardization process starts off with ISO commissioning a sub-committee workgroup. The workgroup issues working drafts and discussion documents to interested parties (including other standards bodies) in order to provoke discussion and comments. This will generate a lot of questions, much discussion and usually some disagreement on what the standard should provide and if it can satisfy all needs (usually not). All conflicting views should be taken into account, often by way of compromise, to progress to a draft proposal of the working group. The draft proposal is discussed by the member countries' standard bodies and other organizations within each country. Comments and suggestions are collated and national views will be formulated, before the members of ISO vote on the proposal. If rejected, the draft proposal has to consider the objections and counter-proposals to create a new draft proposal for another vote. After a lot of feedback, modification, and compromise the proposal reaches the status of a draft international standard, and ultimately an international standard. The process normally takes several years to complete. The original paper draft created by the designer will differ substantially from the standard, and will contain some of the following 'features': Various optional modes of operation, for example to allow for setup of different packet sizes at startup time, because the parties could not reach consensus on the optimum packet size. Parameters that are left undefined or allowed to take on values of a defined set at the discretion of the implementor. This often reflects conflicting views of some of the members. Parameters reserved for future use, reflecting that the members agreed the facility should be provided, but could not reach agreement on how this should be done in the available time. Various inconsistencies and ambiguities will inevitably be found when implementing the standard. International standards are reissued periodically to handle the deficiencies and reflect changing views on the subject.[67]

Future of standardization (OSI)

A lesson learned from ARPANET (the predecessor of the Internet) is that standardization of protocols is not enough, because protocols also need a framework to operate. It is therefore important to develop a general-purpose, future-proof framework suitable for structured protocols (such as layered protocols) and their standardization. This would prevent protocol standards with overlapping functionality and would allow clear definition of the responsibilities of a protocol at the different levels (layers).[68] This gave rise to the ISO Open Systems Interconnection reference model (RM/OSI), which is used as a framework for the design of standard protocols and services conforming to the various layer specifications.[69] In the OSI model, communicating systems are assumed to be connected by an underlying physical medium providing a basic (and unspecified) transmission mechanism. The layers above it are numbered (from one to seven);

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.

Common types of protocols

The Internet Protocol is used in concert with other protocols within the Internet Protocol Suite. Prominent members of which include: Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Internet Control Message Protocol (ICMP) Hypertext Transfer Protocol (HTTP) Post Office Protocol (POP3) File Transfer Protocol (FTP) Internet Message Access Protocol (IMAP)

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

IP addressing and routing

Perhaps the most complex aspects of IP are IP addressing and routing. Addressing refers to how end hosts become assigned IP addresses and how subnetworks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most importantly by internetwork routers, which typically use either interior gateway protocols (IGPs) or external gateway protocols (EGPs) to help make IP datagram forwarding decisions across IP connected networks. IP routing is also common in local networks. For example, Ethernet switches sold today support IP multicast.[3] These switches primarily use IP addresses but also support MAC addresses for compatibility with older layer 2 Ethernet switches.

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

Sample encapsulation of application data from UDP to a Link protocol frame

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)

Internet protocol suite

20

Internet protocol suite

The Internet protocol suite is the set of communications protocols used for the Internet and other similar networks. It is commonly known as TCP/IP from its most important protocols: Transmission Control Protocol (TCP) and Internet Protocol (IP), which were the first networking protocols defined in this standard. Modern IP networking represents a synthesis of several developments that began to evolve in the 1960s and 1970s, namely the precursors of the Internet and local area networks, which emerged during the 1980s, together with the advent of the World Wide Web in the early 1990s. The Internet protocol suite classifies its methods and protocols into four hierarchical abstraction layers. From the lowest to the highest communication layer, these are the link layer, the internet layer, the transport layer, and the application layer.[1] [2] The layers define the operational scope or reach of the protocols in each layer, reflected loosely in the layer names. Each layer has functionality that solves a set of problems in its scope. The link layer contains communication technologies for the local network to which the host is connected directly by hardware components. The internet layer facilitates the interconnection of local networks. As such, this layer establishes the Internet. Host-to-host communication tasks are handled in the transport layer, which provides a general application-agnostic framework to transmit data between hosts using protocols like the Transmission Control Protocol and the User Datagram Protocol (UDP). Finally, the highest-level application layer contains all protocols that are defined each specifically for the functioning of the vast array of data communications services. This layer handles application-based interaction on a process-to-process level between communicating Internet hosts.

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.

Diagram of the first internetworked connection

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

Internet protocol suite

22

Layers in the Internet protocol suite

The concept of layers
The Internet protocol suite uses encapsulation to provide abstraction of protocols and services. Encapsulation is usually aligned with the division of the protocol suite into layers of general functionality. In general, an application (the highest level of the model) uses a set of protocols to send its data down the layers, being further encapsulated at each level. According to RFC 1122, the Internet protocol suite organizes the functional groups of protocols and methods into four layers, the application layer, the transport layer, the internet layer, and the link layer. This model was not intended to be a rigid reference model into which new protocols have to fit in order to be accepted as a standard. The role of layering in TCP/IP may be illustrated by an example network scenario (right-hand diagram), in which two Internet host computers communicate across local network boundaries constituted by their internetworking routers. The application on each host Instantiations of the TCP/IP stack operating on two hosts each executes read and write operations as if the processes connected to its router on the Internet. The flow of user data through the layers used at each hop is shown. were directly connected to each other by some kind of data pipe, every other detail of the communication is hidden from each process. The underlying mechanisms that transmit data between the host computers are located in the lower protocol layers. The transport layer establishes host-to-host connectivity, meaning it handles the details of data transmission that are independent of the structure of user data and the logistics of exchanging information for any particular specific purpose. The layer simply establishes a basic data channel that an application uses in its task-specific data exchange. For this purpose the layer establishes the concept of the port, a numbered logical construct allocated specifically for each of the communication channels an application needs. For many types of services, these port numbers have been standardized so that client computers may address specific services of a server computer without the involvement of service announcements or directory services. The transport layer operates on top of the internet layer. The internet layer is not only agnostic of application data structures as the transport layer, but it also does not distinguish between operation of the various transport layer protocols. It only provides an unreliable datagram transmission facility between hosts located on potentially different IP networks by forwarding the transport layer datagrams to an appropriate next-hop router for further relaying to its destination. With this functionality, the internet layer makes possible internetworking, the interworking of different IP networks, and it essentially establishes the Internet. The Internet Protocol is the principal component of the internet layer, and it defines two addressing systems to identify network hosts computers, and to locate them on the network. The original address system of the ARPANET and its successor, the Internet, is Internet Protocol version 4 (IPv4). It uses a 32-bit IP address and is therefore capable of identifying approximately four billion hosts. This limitation was eliminated by the standardization of Internet Protocol version 6 (IPv6) in 1998, and beginning production implementations in approximately 2006.

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

Layer names and number of layers in the literature

Successive encapsulation of application data descending through the protocol stack

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

"TCP/IP reference [20] model" Application

"Internet model"

"Five-layer Internet model" or "TCP/IP protocol suite" Application

"TCP/IP 5-layer reference model"

"TCP/IP model" "Arpanet reference model"

Application [18] [21] Transport [18] Internet Link [18]

Application

Application

Application

Application/Process

Transport

Transport

Transport

Transport

Host-to-host or transport Internet

Host-to-host

Internet Host-to-network

Internetwork Network interface

Network Data link

Internet

[18]

Data link (Network Network access interface) (Hardware) Physical

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)

Internet protocol suite

[15] Douglas E. Comer, Internetworking with TCP/IP: Principles, Protocols and Architecture, Pearson Prentice Hall 2005, ISBN 0-13-187671-6 (http:/ / books. google. com/ books?id=jonyuTASbWAC& pg=PA155& cad=0_0#PPA161,M1) [16] Charles M. Kozierok, "The TCP/IP Guide", No Starch Press 2005 (http:/ / books. google. com/ books?id=Pm4RgYV2w4YC& pg=PA131& dq="TCP/ IP+ model+ layers"#PPA129,M1) [17] William Stallings, Data and Computer Communications, Prentice Hall 2006, ISBN 0-13-243310-9 (http:/ / books. google. com/ books?id=c_AWmhkovR0C& pg=PA35& dq="internet+ layer"+ "network+ access+ layer") [18] IETF, RFC 1122, p.7-8, "The protocol layers [...] are as follows [...]:[...] Application Layer [...] Transport Layer [...] Internet Layer [...] Link Layer" [19] Andrew Tanenbaum, Computer Networks, section 1.4.3, "[...] the OSI model has seven layers and the TCP/IP has four layers." [20] Tanenbaum, Andrew S. (2002). Computer Networks. Prentice Hall. p.41. ISBN0130661023. "1.4.2 The TCP/IP Reference Model" Excerpt at Google Books (http:/ / books. google. com/ books?id=Pd-z64SJRBAC& pg=PA42& vq=internet+ layer& dq=networks#PPA42,M1) [21] IETF, RFC 1122, p.8, "The application layer is the top layer of the Internet protocol suite." [22] R. Bush; D. Meyer (December 2002). Some Internet Architectural Guidelines and Philosophy (http:/ / www. isi. edu/ in-notes/ rfc3439. txt). Internet Engineering Task Force. . Retrieved 2007-11-20

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

Signalling System No. 7

27

Signalling System No. 7

SS7 protocol suite
OSI layer SS7 protocols

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.

Signalling System No. 7

30

SS7 protocol suite

SS7 protocol suite
OSI layer SS7 protocols

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)

Public switched telephone network

The public switched telephone network (PSTN) is the network of the world's public circuit-switched telephone networks. It consists of telephone lines, fiber optic cables, microwave transmission links, cellular networks, communications satellites, and undersea telephone cables, all inter-connected by switching centers, thus allowing any telephone in the world to communicate with any other. Originally a network of fixed-line analog telephone systems, the PSTN is now almost entirely digital in its core and includes mobile as well as fixed telephones. The technical operation of the PSTN utilizes standards created by the ITU-T. These standards allow different networks in different countries to interconnect seamlessly. There is also a single global address space for telephone numbers based on the E.163 and E.164 standards. The combination of the interconnected networks and the single numbering plan make it possible for any phone in the world to dial any other phone.

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.

Regulation of the PSTN

In most countries, the central government has a regulator dedicated to monitoring the provision of PSTN services in that country. Their tasks may be for example to ensure that end customers are not over-charged for services where monopolies may exist. They may also regulate the prices charged between the operators to carry each others traffic.

Technology in the PSTN

Network topology
The PSTN network architecture had to evolve over the years to support increasing numbers of subscribers, calls, connections to other countries, direct dialling and so on. The model developed by the US and Canada was adopted by other nations, with adaptations for local markets. The original concept was that the telephone exchanges are arranged into hierarchies, so that if a call cannot be handled in a local cluster, it is passed to one higher up for onward routing. This reduced the number of connecting trunks required between operators over long distances and also kept local traffic separate. However, in modern networks the cost of transmission and equipment is lower and, although hierarchies still exist, they are much flatter, with perhaps only two layers.

Public switched telephone network

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.

PSTN and mobile network providers

It is becoming increasingly common for telecommunications providers to use VoIP telephony over dedicated and public IP networks to connect switching centres and to interconnect with other telephony network providers; this is often referred to as "IP backhaul".[4] [5] Smartphones and Wi-Fi enabled mobile phones may have SIP clients built into the firmware or available as an application download.

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

Susceptibility to power failure

Telephones for traditional residential analog service are usually connected directly to telephone company phone lines which provide direct current to power most basic analog handsets independently of locally available power. IP Phones and VoIP telephone adapters connect to routers or cable modems which typically depend on the availability of mains electricity or locally generated power.[18] Some VoIP service providers use customer premise equipment (e.g., cablemodems) with battery-backed power supplies to assure uninterrupted service for up to several hours in case of local power failures. Such battery-backed devices typically are designed for use with analog handsets. Some VoIP service providers implement services to route calls to other telephone services of the subscriber, such a cellular phone, in the event that the customer's network device is inaccessible to terminate the call. The susceptibility of phone service to power failures is a common problem even with traditional analog service in areas where many customers purchase modern telephone units that operate with wireless handsets to a base station, or that have other modern phone features, such as built-in voicemail or phone book features.

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

Compatibility with traditional analog telephone sets

Some analog telephone adapters do not decode pulse dialing from older phones. They may only work with push-button telephones using the touch-tone system. The VoIP user may use a pulse-to-tone converter, if needed.[43]

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.

Support for other telephony devices

Another challenge for VoIP implementations is the proper handling of outgoing calls from other telephony devices such as digital video recorders, satellite television receivers, alarm systems, conventional modems and other similar devices that depend on access to a PSTN telephone line for some or all of their functionality. These types of calls sometimes complete without any problems, but in other cases they fail. If VoIP and cellular substitution becomes very popular, some ancillary equipment makers may be forced to redesign equipment, because it would no longer be possible to assume a conventional PSTN telephone line would be available in consumer's homes.

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

Session Initiation Protocol

The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol widely used for controlling communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. Sessions may consist of one or several media streams. Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer and online games. The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport Layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP).[1] It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).[2]

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]

Session Initiation Protocol

51

Instant messaging and presence

The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is the SIP-based suite of standards for instant messaging and presence information. MSRP (Message Session Relay Protocol) allows instant message sessions and file transfer.

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

Session Initiation Protocol

[12] Stallings, p.214 [13] Stallings, pp.214-215 [14] Stallings, pp.216-217 [15] James Wright. "SIP - An Introduction" (http:/ / www. konnetic. com/ Documents/ KonneticSIPIntroduction. pdf) (PDF). Konnetic. . Retrieved 2011-01-11. [16] Experiences of Using TTCN-3 for Testing SIP and also OSP (http:/ / portal. etsi. org/ ptcc/ downloads/ TTCN3SIPOSP. pdf) [17] http:/ / www. sipit. net [18] Jonsson, Lars; Mathias Coinchon (2008). "Streaming audio contributions over IP" (http:/ / tech. ebu. ch/ webdav/ site/ tech/ shared/ techreview/ trev_2008-Q1_coinchon. pdf) (PDF). EBU Technical Review. . Retrieved 2010-12-27. [19] "RFC3372: SIP-T Context and Architectures" (http:/ / www. ietf. org/ rfc/ rfc3372. txt). 2002-09. . Retrieved 2011-01-11. [20] White Paper: "Why SIP-I? A Switching Core Protocol Recommendation" (http:/ / www. 4gamericas. org/ documents/ 3G_Americas_SIP-I_White_Paper_August_2007-FINAL. pdf)

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)

User Datagram Protocol

The User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768. UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[1] If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose. UDP's stateless nature is also useful for servers answering small queries from huge numbers of clients. Unlike TCP, UDP supports packet broadcast (sending to all on local network) and multicasting (send to all subscribers).[2] Common network applications that use UDP include: the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP), IP tunneling protocols and many online games.

User Datagram Protocol

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

Source Port Number Destination Port Number Length Data Checksum

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:

User Datagram Protocol

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.

Reliability and congestion control solutions

Lacking reliability, UDP applications must generally be willing to accept some loss, errors or duplication. Some applications such as TFTP may add rudimentary reliability mechanisms into the application layer as needed.[2] Most often, UDP applications do not employ reliability mechanisms and may even be hindered by them. Streaming media, real-time multiplayer games and voice over IP (VoIP) are examples of applications that often use UDP. In these particular applications, loss of packets is not usually a fatal problem. If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or erasure codes may be used instead. Potentially more seriously, unlike TCP, UDP-based applications don't necessarily have good congestion avoidance and control mechanisms. Congestion insensitive UDP applications that consume a large fraction of available bandwidth could endanger the stability of the internet, as they frequently give a bandwidth load that is inelastic. Network-based mechanisms have been proposed to minimize potential congestion collapse effects of uncontrolled, high rate UDP traffic loads. Network-based elements such as routers using packet queuing and dropping techniques are often the only tool available to slow down excessive UDP traffic. The Datagram Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding end host TCP-friendly congestion control behavior to high-rate UDP streams such as streaming media.

User Datagram Protocol

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]

Comparison of UDP and TCP

Transmission Control Protocol is a connection-oriented protocol, which means that it requires handshaking to set up end-to-end communications. Once a connection is set up user data may be sent bi-directionally over the connection. Reliable TCP manages message acknowledgment, retransmission and timeout. Multiple attempts to deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there's either no missing data, or, in case of multiple timeouts, the connection is dropped. Ordered if two messages are sent over a connection in sequence, the first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers the out-of-order data until all data can be properly re-ordered and delivered to the application. Heavyweight TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control. Streaming Data is read as a byte stream, no distinguishing indications are transmitted to signal message (segment) boundaries. UDP is a simpler message-based connectionless protocol. Connectionless protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver. However, one primary benefit of UDP over TCP is the application to voice over internet protocol (VoIP) where any handshaking would hinder clear voice communication. It is assumed in VoIP UDP that the end users provide any necessary real time confirmation that the message has been received. Unreliable When a message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission or timeout. Not ordered If two messages are sent to the same recipient, the order in which they arrive cannot be predicted. Lightweight There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP. Datagrams Packets are sent individually and are checked for integrity only if they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent. No congestion control UDP itself does not avoid congestion, and it's possible for high bandwidth applications to trigger congestion collapse, unless they implement congestion control measures at the application level.

User Datagram Protocol

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.

User agent identification

Some user agents identify their software as part of the clientserver conversation. In HTTP and SIP, the identity is transmitted via the User-Agent field in the request header, as described by RFC 1945 [3]. This string is then used by the communications partner to characterize the client and optionally select suitable content or operating parameters for the session. For example, this may be used to provide properly formatted content for desktop computers and for smartphones. The user agent string is one of the criteria by which Web crawlers may be excluded from accessing certain parts of a Web site using the Robots Exclusion Standard (robots.txt file).

Possible privacy issue

The information could help distinguish Internet users from one another because it differs, often considerably, from user to user and on average browser versions carry 10.5 bits of identifying information.[4]

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

User agent experience to joining meetings.

59

User agent spoofing

The popularity of various Web browser products has varied throughout the Web's history, and this has influenced the design of Web sites in such a way that Web sites are sometimes designed to work well only with particular browsers, rather than according to uniform standards by the World Wide Web Consortium (W3C) or the Internet Engineering Task Force (IETF). Web sites often include code to detect browser version to adjust the page design sent according to the user agent string received. This may mean that less-popular browsers are not sent complex content, even though they might be able to deal with it correctly or, in extreme cases, refused all content.[5] Thus, various browsers have a feature to cloak or spoof their identification to force certain server-side content. For example, the Android browser identifies itself as Safari in order to aid compatibility[6] . Other HTTP client programs, like download managers and offline browsers, also have the ability to change the user agent string. Spam bots and Web scrapers often use fake user agents. At times it has been popular among Web developers to initiate Viewable With Any Browser campaigns,[7] encouraging developers to design Web pages that work equally well with any browser. A result of user agent spoofing may be that collected statistics of Web browser usage are inaccurate.

User agent sniffing

The term user agent sniffing refers to the practice of Web sites showing different content when viewed with a certain user agent. On the Internet, this will result in a different site being shown when browsing the page with a specific browser. A useful example of this is Microsoft Exchange Server 2003's Outlook Web Access feature. When viewed with Internet Explorer 6 (or newer), more functionality is displayed compared to the same page in any older browsers, because older browsers could not render the same content. User agent sniffing is mostly considered poor practice, since it encourages browser-specific design and penalizes new browsers with unrecognized user agent identifications. Instead, the W3C recommends creating HTML markup that is standard,[8] allowing correct rendering in as many browsers as possible, and to test for specific browser features rather than particular browser versions or brands.[9] Web sites specifically targeted towards mobile phones, like NTT DoCoMo's I-Mode or Vodafone's Vodafone Live! portals, often rely heavily on user agent sniffing, since mobile browsers often differ greatly from each other. Many developments in mobile browsing have been made in the last few years, while many older phones that do not possess these new technologies are still heavily used. Therefore, mobile Web portals will often generate completely different markup code depending on the mobile phone used to browse them. These differences can be small, e.g., resizing of certain images to fit smaller screens, or quite extensive, e.g., rendering of the page in WML instead of XHTML.

Encryption strength notations

Web browsers created in the United States, such as Netscape Navigator and Internet Explorer, use the letters U, I, and N to specify the encryption strength in the user agent string. Until the United States government allowed encryption with keys longer than 40 bits to be exported, in 1996, vendors shipped various browser versions with different encryption strengths. "U" stands for "USA" (for the version with 128-bit encryption), "I" stands for "International" the browser has 40-bit encryption and can be used anywhere in the world and "N" stands (de facto) for "None" (no encryption).[10] Following the lifting of export restrictions, most vendors supported 256-bit encryption.

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/)

Hypertext Transfer Protocol

61

Hypertext Transfer Protocol

HTTP
Persistence Compression HTTPS Request methods OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT Header fields Cookie ETag Location Referer DNT X-Forwarded-For Status codes 301 Moved permanently 302 Found 303 See Other 403 Forbidden 404 Not Found

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]

Hypertext Transfer Protocol

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.

Idempotent methods and web applications

Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.[1] In contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once. Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it isn't.

Hypertext Transfer Protocol

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.

HTTP session state

HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. For example, when a web server is required to customize the content of a web page for a user, the web application may have to track the user's progress from page to page. A common solution is the use of HTTP cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URL-rewriting using URI-encoded parameters, e.g., /index.php?session_id=some_unique_session_code.

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

Hypertext Transfer Protocol

[13] "Apache Week. HTTP/1.1" (http:/ / www. apacheweek. com/ features/ http11). . 090502 apacheweek.com [14] Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST" (http:/ / www. w3. org/ 2001/ tag/ doc/ whenToUseGet. html#checklist). Technical Architecture Group finding. W3C. . Retrieved 26 September 2010. [15] "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections" (http:/ / www. kb. cert. org/ vuls/ id/ 150227). US-CERT. 2002-05-17. . Retrieved 2007-05-10. [16] Dusseault, Lisa; Snell, James M.. "RFC 5789: PATCH Method for HTTP" (http:/ / tools. ietf. org/ html/ rfc5789). . [17] "HTTP 1.1 Section 5.1.1" (http:/ / tools. ietf. org/ html/ rfc2616#section-5. 1. 1). Tools.ietf.org. . Retrieved 2010-08-01. [18] "6.1 Status-Line" (http:/ / www. w3. org/ Protocols/ rfc2616/ rfc2616-sec6. html#sec6. 1). W3.org. . Retrieved 2010-08-01. [19] Tools.ietf.org (http:/ / tools. ietf. org/ html/ draft-ietf-http-range-retrieval-00), Byte Range Retrieval Extension to HTTP

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 Network Elements

Terminals Terminals in an H.323 network are the most fundamental elements in any H.323 system, as those are the devices that users would normally encounter. They might exist in the form of a simple IP phone or a powerful high-definition videoconferencing system. Inside an H.323 terminal is something referred to as a Protocol stack, which implements the functionality defined by the H.323 system. The protocol Figure 1 - A complete, sophisticated protocol stack stack would include an implementation of the basic protocol defined in ITU-T Recommendation H.225.0 and H.245, as well as RTP or other protocols described above. The diagram, figure 1, depicts a complete, sophisticated stack that provides support for voice, video, and various forms of data communication. In reality, most H.323 systems do not implement such a wide array of capabilities, but the logical arrangement is useful in understanding the relationships.

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

H.323 Network Signaling

H.323 is defined as a binary protocol, which allows for efficient message processing in network elements. The syntax of the protocol is defined in ASN.1 and uses the Packed Encoding Rules (PER) form of message encoding for efficient message encoding on the wire. Below is an overview of the various communication flows in H.323 systems. H.225.0 Call Signaling Once the address of the remote endpoint is resolved, the endpoint will use H.225.0 Call Signaling in order to establish communication with the remote entity. H.225.0 messages are: Setup and Setup acknowledge Call Proceeding Connect Alerting

Information Release Complete

H.323 Facility Progress Status and Status Inquiry Notify

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

H.323 and Videoconference services

A videoconference, or videoteleconference (VTC), is a set of telecommunication technologies allowing two or more locations to interact via two-way video and audio transmissions simultaneously. There are basically two types of videoconferencing; dedicated VTC systems have all required components packaged into a single piece of equipment while desktop VTC systems are add-ons to normal PC's, transforming them into VTC devices. Simultaneous videoconferencing among three or more remote points is possible by means of a Multipoint Control Unit (MCU). There are MCU bridges for IP and ISDN-based videoconferencing. Due to the price point and proliferation of the Internet, and broadband in particular, there has been a strong spurt of growth and use of H.323-based IP videoconferencing. H.323 is accessible to anyone with a high speed Internet connection, such as DSL. Videoconferencing is utilized in various situations, for example; distance education, telemedicine and business.

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.

ITU-T Recommendations of the H.323 System

ITU-T H.323 Core Recommendations ITU-T Recommendation H.323 (http://www.itu.int/rec/T-REC-H.323/en/), Packet-based multimedia communications systems. ITU-T Recommendation H.225.0 (http://www.itu.int/rec/T-REC-H.225.0/en/), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T Recommendation H.245 (http://www.itu.int/rec/T-REC-H.245/en/), Control protocol for multimedia communication. ITU-T Recommendation H.246 (http://www.itu.int/rec/T-REC-H.246/en/), Interworking of H-series multimedia terminals with H-series multimedia terminals and voice/voiceband terminals on GSTN and ISDN.

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)

Implementing H.323 (Zip) (http://hive.packetizer.com/users/h323forum/papers/basic_h323_von_99.zip)

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

Skinny Call Control Protocol

80

Skinny Call Control Protocol

The Skinny Call Control Protocol (SCCP, or short Skinny) is a proprietary network terminal control protocol originally developed by Selsius Systems. The SCCP technology is now owned and defined by Cisco Systems, Inc.. SCCP is a lightweight protocol for session signaling with Cisco CallManager.[1] Examples of SCCP clients include the Cisco 7900 series of IP phones, Cisco IP Communicator softphone and the 802.11b wireless Cisco 7920, along with Cisco Unity voicemail server. CallManager acts as a signaling proxy for call events initiated over other common protocols such as H.323, Session Initiation Protocol (SIP), ISDN and/or MGCP.

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)

Real Time Streaming Protocol

81

Real Time Streaming Protocol

The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between end points. Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server. The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, however some vendors implement proprietary transport protocols. The RTSP server from RealNetworks, for example, also features RealNetworks' proprietary RDT stream transport. RTSP was developed by the Multiparty Multimedia Session Control Working Group (MMUSIC WG) of the Internet Engineering Task Force (IETF) and published as RFC 2326 in 1998.[1]

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

Winamp Windows Media Player xine

Real Time Streaming Protocol JetAudio

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

Real-time Transport Protocol

The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features. RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number. RTP is one of the technical foundations of Voice over IP and in this context is often used in conjunction with a signaling protocol which assists in setting up connections across the network. RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.

Real-time Transport Protocol

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.

Profiles and Payload formats

One of the design considerations of RTP was to support a range of multimedia formats (such as H.264, MPEG-4, MJPEG, MPEG, etc.) and allow new formats to be added without revising the RTP standard. The design of RTP is based on the architectural principle known as application level framing (ALF). The information required by a specific application's needs is not included in the generic RTP header, but is instead provided through RTP profiles and payload formats.[2] For each class of application (e.g., audio, video), RTP defines a profile and one or more associated payload formats.[2] A complete specification of RTP for a particular application usage will require a profile and payload format specification(s).[13]

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

Real-time Transport Protocol

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.

Real-time Transport Protocol

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)

RTP Control Protocol

The Real-Time Transport Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in the RTP specification RFC 3550,[1] superseding its original standardization in 1996 (RFC 1889). RTCP provides out-of-band statistics and control information for an RTP flow. It partners RTP in the delivery and packaging of multimedia data, but does not transport any media streams itself. Typically RTP will be sent on an even-numbered UDP port, with RTCP messages being sent over the next highest odd-numbered port.[2] The primary function of RTCP is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session. RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec. RTCP itself does not provide any flow encryption or authentication methods. Such mechanisms may be implemented, for example, with the Secure Real-time Transport Protocol (SRTP) defined in RFC 3711.

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.

RTP Control Protocol

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.

Scalability in large deployments

In large-scale applications, such as in Internet Protocol Television (IPTV), very long delays (minutes to hours) between RTCP reports may occur, because of the RTCP bandwidth control mechanism required to control congestion (see #Protocol functions). Acceptable frequencies are usually less than one minute. This affords the potential of inappropriate reporting of the relevant statistics by the receiver or cause evaluation by the media sender to be inaccurate relative to the current state of the session. Methods have been introduced to alleviate the problems:[4] RTCP filtering, RTCP biasing and hierarchical aggregation.[5]

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.

RTP Control Protocol

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.

Telephone number mapping

Telephone number mapping is the process of unifying the telephone number system of the public switched telephone network with the Internet addressing and identification name spaces. Telephone numbers are systematically organized in the E.164 standard, while the Internet uses the Domain Name System for linking domain names to IP addresses and other resource information. Telephone number mapping systems provide facilities to determine applicable Internet communications servers responsible for servicing a given telephone number by simple lookups in the Domain Name System. The most prominent facility for telephone number mapping is the E.164 NUmber Mapping (ENUM) standard. It uses special DNS record types to translate a telephone number into a Uniform Resource Identifier or IP address that can be used in Internet communications.

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.

Telephone number mapping

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.

Telephone number mapping

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.

Application scenario for Voice over IP (VoIP) with ENUM.

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

Telephone number mapping

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.

Called party facility

ENUM can also be viewed as a called party facility. Basically, it is an indirect dialling service designed to work seamlessly on PSTN and VoIP that builds on the great value of the e.164 numbers: billions of people knowing how to dial using numbers. If the called person has opted to use ENUM she/he will have published the ENUM number and have entered (via ENUM NAPTR) his/her wishes for how the call should be terminated. This might be a single VoIP identifier, but most likely it will be a list of how the call should be forwarded to various fixed-line, cellphones, secretarial or voice mail services, either at the IP or at the PSTN side of the network. It is the called party choice to opt-in ENUM and also to decide to let the calling party know her/his wishes. Today when a user places a regular phone call, he has to begin deciding how to establish the call with the other party: via VoIP, Fixed-line PSTN, cellphone, entering a URI or dialling a number. With ENUM indirect dialling it is

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.....

Parties having a direct interest in ENUM

Various parties are involved with ENUM. These include: The registrant or subscriber The registrant is the person or subscriber that makes his access information available to others through ENUM. The registrant or subscriber is thus the person whose information has been included in ENUM and must not be confused with the person who uses the Internet to find an address through ENUM. The registrar The registrar is the party who manages the registrants access information and ensures that it is publicly available on the Internet. The registry The registry is the manager of a national ENUM zone. The registry forms, as it were, the top of the national ENUM hierarchy and ensures that reference is made to the registrars servers on which the access information is located. Because of the hierarchical structure of the DNS, there can only be one registry for every national ENUM zone. To prevent abuse of this position, requirements are strict with respect to the impartiality of the registry and the costs and quality of the service. In addition every registrant must receive equal and open access. The government or the regulator Usually a governmental entity or a regulatory authority has control over the National zone of ENUM and will play a role in the appointment of the registry. The number holder operator Telephony services or telecommunication services operators have being assigned blocks of numbers by the regulator. They subsequently enable their users to use individual telephone numbers from those number blocks. Examples are the numbers for fixed telephony and mobile telephony. The number holder operator will be interconnected to other operators and will receive from them calls to his assigned range of numbers, for the

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]

Telephone number mapping

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]

"Real time" standardization

The rise of the personal computer industry in the early 1980s created a new common practice among both consumers and businesses of adopting "bleeding edge" communications technology even if it was not yet standardized. Thus, standards organizations had to put forth standards much faster, or find themselves ratifying de facto standards after the fact. The ITU-T now operates under much more streamlined processes. The time between an initial proposal of a draft document by a member company and the final approval of a full-status ITU-T Recommendation can now be as short as a few months (or less in some cases). This makes the standardization approval process in the ITU-T much more responsive to the needs of rapid technology development than in the ITU's historical past.[8] New and updated Recommendations are published on an almost daily basis, and much of the library of over 3,270 Recommendations is now free of charge online.[9] [10] [11] (Specifications jointly maintained by the ITU-T and ISO/IEC are not free.[12] ) ITU-T has moreover tried to facilitate cooperation between the various forums and standard-developing organizations (SDOs). This collaboration is necessary to avoid duplication of work and the consequent risk of conflicting standards in the market place.[13]

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

Series and Recommendations

ITU-T Recommendations are the names given to telecommunications and computer protocol specification documents published by ITU-T. Many of the Recommendations that define OSI are also ISO standards. Standards for Internet protocols are typically developed in the IETF, and standards for mobile telephone systems are developed in ETSI and other forums.

Series of ITU Recommendations

ITU-T issues Recommendations that have names like X.500, where X is the series and 500 is an identifying number. When a Recommendation is updated, it will (mostly) keep the same number, so the year of issue may be necessary to identify a specific version of a Recommendation. The term "X.500" is used both to refer to the specific X.500 Recommendation, and to the entire family of Recommendations named X.5xx, where the specific X.500 Recommendation forms the introduction and overview to the set.
Series A B C D E F G H I J K L M N O P Q R S T U V Organization of the work of ITU-T Means of expression: definitions, symbols, classification General telecommunication statistics General tariff principles Overall network operation, telephone service, service operation and human factors Non-telephone telecommunication services Transmission systems and media, digital systems and networks Audiovisual and multimedia systems Integrated services digital network Cable networks and transmission of television, sound programme and other multimedia signals Protection against interference Construction, installation and protection of cables and other elements of outside plant Telecommunication management, including TMN and network maintenance Maintenance: international sound programme and television transmission circuits Specifications of measuring equipment Telephone transmission quality, telephone installations, local line networks Switching and signalling Telegraph transmission Telegraph services terminal equipment Terminals for telematic services Telegraph switching Data communication over the telephone network Description

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

International Telecommunication Regulations (ITRs)

In addition to the ITU-T Recommendations, which have non-mandatory status until they are adopted in national laws, ITU-T is also the custodian of a binding international treaty, the International Telecommunication Regulations. The ITRs go back to the earliest days of the ITU when there were two separate treaties, dealing with telegraph and telephone. The ITRs were adopted, as a single treaty, at the World Administrative Telegraphy and Telephone Conference held in Melbourne, 1988 (WATTC-88).[21] In line with the current Constitution and Convention of ITU, the ITRs can be amended through a World Conference on International Telecommunications (WCIT), and the next is scheduled for 2012. Before then a process of review of the ITRs, which began in 1998, will continue.[22] The ITRs comprise ten articles which deal, inter alia, with the definition of international telecommunication services, cooperation between countries and national administrations, safety of life and priority of telecommunications and charging and accounting principles. The adoption of the ITRs in 1988 is often taken as the start of the wider liberalization process in international telecommunications, though a few countries, including United States and United Kingdom, had made steps to liberalize their markets before 1988.[23]

ITU-T

102

Key standards published by ITU

ASN.1 (Abstract Syntax Notation One) Coding of audio G.711 and G.72x series Coding of still images JPEG T.80 and JPEG 2000 T.800 series Coding of video coding H.262/MPEG2-Video and H.264/MPEG-4 AVC Construction, installation and protection of cables and other elements of outside plant, L-series Data communicationover the telephone network, V-series Fax standards T.2 T.4, T.30, T.37, T.38 G.hn (Next generation wired home networking over powerlines, phonelines and coaxial cable) H.323 family of standards for multimedia and VoIP Interconnection rate harmonization, D-series International Emergency Preference Scheme E.106 IMSI codes used in SIM cards E.212 ISDN and PSTN/3G videoconferencing systems, H.320 and H.324 ISDN (Integrated Services Digital Network) Q.931 Open Systems Interconnection Optical Transport Network (OTN) G.709, G.798 Passive optical networks (PON) G.983, G.984, G.987 Public Key Infrastructure (PKI) X.509 Public telecommunication numbering plan, E.164 Security framework X.805 Signalling System 7 Q.7xx series Standards relating to Quality of Service (QoS) Specification and Description Language Synchronous Digital Hierarchy (SDH) G.707 G.803 Wavelength-division multiplexing (WDM) X.25 (x)DSL (Digital Subscriber Line) series of standards for broadband telecoms

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)

European Telecommunications Standards Institute

104

European Telecommunications Standards Institute

The European Telecommunications Standards Institute (ETSI) is an independent, non-profit, standardization organization in the telecommunications industry (equipment makers and network operators) in Europe, with worldwide projection. ETSI has been successful in standardizing the Low Power Radio, Short Range Device, GSM cell phone system and the TETRA professional mobile radio system. Significant ETSI standardisation bodies include TISPAN (for fixed networks and Internet convergence) and M2M (for machine-to-machine communications). ETSI inspired the creation of, and is a partner in 3GPP. ETSI was created by CEPT in 1988 and is officially recognized by the European Commission and the EFTA secretariat. Based in Sophia Antipolis (France), ETSI is officially responsible for standardization of Information and Communication Technologies (ICT) within Europe. These technologies include telecommunications, broadcasting and related areas such as intelligent transportation and medical electronics. ETSI has 740 members from 62 countries/provinces inside and outside Europe, including manufacturers, network operators, administrations, service providers, research bodies and users in fact, all the key players in the ICT arena. A list of current members can be found here [1]. In 2010, ETSI's budget exceeded 22 million, with contributions coming from members, commercial activities like sale of documents, plug-tests and fora hosting (i.e. the hosting of forums[2] ), contract work and partner funding. [3] About 40% goes towards operating expenses and the remaining 60% towards work programs including competency centres and special projects. ETSI is a founding partner organization of the Global Standards Collaboration initiative. ETSI was criticised for the preemptive inclusion of wiretapping capabilities in their telecommunication standards, encouraging governments to pass their wiretapping laws accordingly. (see Lawful Interception)

ETSI deliverable types

European Standard, telecommunications series (EN) - Used when the document is intended to meet needs specific to Europe and requires transposition into national standards, or when the drafting of the document is required under an EC/EFTA mandate. ETSI Standard (ES) - Used when the document contains normative requirements and it is necessary to submit the document to the whole ETSI membership for approval. ETSI Guide (EG) - Used when the document contains guidance on handling of technical standardization activities, it is submitted to the whole ETSI membership for approval. Special Report (SR) - Used for various purposes, including giving public availability to information not produced within a technical committee. ETSI SRs are also used for 'virtual' documents, e.g. documents that are dynamically generated by a query to a database via the web. An SR is published by the technical committee in which it was produced. ETSI Technical Specification (TS) - Used when the document contains normative requirements and when short time-to-market, validation and maintenance are essential, it is approved by the technical committee that drafted it. ETSI Technical Report (TR) - Used when the document contains mainly informative elements, it is approved by the technical committee that drafted it. ETSI Group Specification (GS) - Used by Industry Specification Groups according to the decision making procedures defined in the group's Terms of Reference. This deliverable type is approved and adopted by the Industry Specification Group that drafted it. This list is gathered from the European Telecommunications Standards Institute website.[4]

European Telecommunications Standards Institute

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

Internet Engineering Task Force

106

Internet Engineering Task Force

Internet Engineering Task Force
Abbreviation Formation Type Purpose/focus Regionserved IETF Chair IETF January 16, 1986 Standards Organization Creating standards applying to the internet to improve internet usability. Worldwide Russ Housley

Parentorganization Internet Society Website ietf.org [1]

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.

Internet Engineering Task Force

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.

Internet Engineering Task Force

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.

Request for Comments

109

Request for Comments

In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems. Through the Internet Society, engineers and computer scientists may publish discourse in the form of an RFC, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.

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]

Request for Comments

110

Production and evolution

The RFC Editor assigns each RFC a unique serial number. Once assigned a number and published, an RFC is never rescinded or modified; if the document requires amendments, the authors publish a revised document. Therefore, some RFCs supersede others; the superseded RFCs are said to be deprecated, obsolete, or even obsoleted (sic). Together, the serialized RFCs compose a continuous historical record of the evolution of Internet standards and practices. For more details about RFCs and the RFC process, see RFC 2026, "The Internet Standards Process, Revision 3".[7] The RFC production process differs from the standardization process of formal standards organizations such as ISO. Internet technology experts may submit an Internet Draft without support from an external institution. Standards-track RFCs are published with approval from the IETF, and are usually produced by experts participating in working groups, which first publish an Internet Draft. This approach facilitates initial rounds of peer review before documents mature into RFCs. The RFC tradition of pragmatic, experience-driven, after-the-fact standards authorship accomplished by individuals or small working groups can have important advantages over the more formal, committee-driven process typical of ISO and national standards bodies. Most RFCs use a common set of terms such as "MUST" and "NOT RECOMMENDED" (as defined by RFC 2119), Augmented BackusNaur Form (ABNF) (as defined by RFC 5234) as a metalanguage, and simple text-based formatting, in order to keep the RFCs consistent and easy to understand.[7]

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.

Request for Comments

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.

Request for Comments

112

Status "best current practice"

The best current practice (BCP) subseries collects administrative documents and other texts which are considered as official rules and not only informational, but which do not affect over the wire data. The border between standards track and BCP is often unclear. If a document only affects the Internet Standards Process, like BCP 9,[12] or IETF administration, it is clearly a BCP. If it only defines rules and regulations for Internet Assigned Numbers Authority (IANA) registries it is less clear; most of these documents are BCPs, but some are on the standards track. The BCP series also covers technical recommendations for how to practice Internet standards; for instance the recommendation to use source filtering to make DoS attacks more difficult (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing") is BCP 38 [13].

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

Request for Comments

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.

Institute of Electrical and Electronics Engineers

The Institute of Electrical and Electronics Engineers (IEEE, read I-Triple-E) is a non-profit professional association headquartered in New York City that is dedicated to advancing technological innovation and excellence. It has more than 400,000 members in more than 160 countries, about 45% of whom reside outside the United States.[1] [2]

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]

Picture of the place where an office of IEEE

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

Standards and development process

IEEE is one of the leading standards-making organizations in the world. IEEE performs its standards making and maintaining functions through the IEEE Standards Association (IEEE-SA). IEEE standards affect a wide range of industries including: power and energy, biomedical and healthcare, Information Technology (IT), telecommunications, transportation, nanotechnology, information assurance, and many more. In 2005, IEEE had close to 900 active standards, with 500 standards under development. One of the more notable IEEE standards is the IEEE 802 LAN/MAN group of standards which includes the IEEE 802.3 Ethernet standard and the IEEE 802.11 Wireless Networking standard.

Membership and member grades

Most IEEE members are electrical and electronics engineers, but the organization's wide scope of interests has attracted people in other disciplines as well (e.g., computer science, mechanical and civil engineering) as well as biologists, physicists, and mathematicians. An individual can join the IEEE as a student member, professional member, or associate member. In order to qualify for membership, the individual must fulfil certain academic or professional criteria and abide to the code of ethics and bylaws of the organization. There are several categories and levels of IEEE membership and affiliation: Student Members: Student membership is available for a reduced fee to those who are enrolled in an accredited institution of higher education as undergraduate or graduate students in technology or engineering. Members: Ordinary or professional Membership requires that the individual have graduated from a technology or engineering program of an appropriately-accredited institution of higher education or have demonstrated professional competence in technology or engineering through at least six years of professional work experience. An associate membership is available to individuals whose area of expertise falls outside the scope of the IEEE or who does not, at the time of enrollment, meet all the requirements for full membership. Students and Associates have all the privileges of members, except the right to vote and hold certain offices. Society Affiliates: Some IEEE Societies also allow a person who is not an IEEE member to become a Society Affiliate of a particular Society within the IEEE, which allows a limited form of participation in the work of a particular IEEE Society. Senior Members: Upon meeting certain requirements, a professional member can apply for Senior Membership, which is the highest level of recognition that a professional member can directly apply for. Applicants for Senior Member must have at least three letters of recommendation from Senior, Fellow, or Honorary members and fulfill other rigorous requirements of education, achievement, remarkable contribution, and experience in the field. The Senior Members are a selected group, and certain IEEE officer positions are available only to Senior (and Fellow) Members. Senior Membership is also one of the requirements for those who are nominated and elevated to the grade IEEE Fellow, a distinctive honor. Fellow Members: The Fellow grade of membership is the highest level of membership, and cannot be applied for directly by the member instead the candidate must be nominated by others. This grade of membership is conferred by the IEEE Board of Directors in recognition of a high level of demonstrated extraordinary accomplishment.

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

Technical field awards

IEEE Biomedical Engineering Award IEEE Cledo Brunetti Award (for nanotechnology and miniaturization) IEEE Components, Packaging, and Manufacturing Technologies Award IEEE Control Systems Award IEEE Electromagnetics Award IEEE James L. Flanagan Speech and Audio Processing Award IEEE Andrew S. Grove Award (for solid-state devices) IEEE Herman Halperin Electric Transmission and Distribution Award

IEEE Masaru Ibuka Consumer Electronics Award IEEE Internet Award

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

Prize paper awards

IEEE Donald G. Fink Prize Paper Award IEEE W.R.G. Baker Award

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]

Institute of Electrical and Electronics Engineers

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

IEEE Components, Packaging & Manufacturing 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)

Institute of Electrical and Electronics Engineers

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]

Institute of Electrical and Electronics Engineers

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.

Session Description Protocol

121

Session Description Protocol

The Session Description Protocol (SDP) is a format for describing streaming media initialization parameters. The IETF published the original specification as an IETF Proposed Standard in April 1998,[1] and subsequently published a revised specification as an IETF Proposed Standard as RFC 4566 in July 2006.[2] SDP is intended for describing multimedia communication sessions for the purposes of session announcement, session invitation, and parameter negotiation. SDP does not deliver media itself but is used for negotiation between end points of media type, format, and all associated properties. The set of properties and parameters are often called a session profile. SDP is designed to be extensible to support new media types and formats. SDP started off as a component of the Session Announcement Protocol (SAP), but found other uses in conjunction with Real-time Transport Protocol (RTP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP) and even as a standalone format for describing multicast sessions.

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)

Session Description Protocol

123

References External links

Rosenberg, J.; Schulzrinne, H. (2002-06). "An Offer/Answer Model with the Session Description Protocol(RFC 3264)" (http://tools.ietf.org/html/rfc3264). IETF. Retrieved 2010-07-25.

Article Sources and Contributors

124

Article Sources and Contributors

Communications protocol Source: http://en.wikipedia.org/w/index.php?oldid=461392792 Contributors: 16@r, Ahoerstemeier, Aldie, Allan McInnes, Amillar, Ardonik, B4hand, BAxelrod, Bctwriter, Bert490, Bhamv, Bloodshedder, Bodachi, BodyTag, BonsaiViking, Brainmachine, Brian2wood, Byrial, Calle, Can't sleep, clown will eat me, CanadianLinuxUser, CapitalR, Charivari, Chowells, Christian75, Chuunen Baka, Ciampix, Coasterlover1994, Conti, Conversion script, Cremepuff222, DVdm, Dairyintheillawarra, Damian Yerrick, David Woodward, Dekisugi, Denisutku, Dgreen34, Dyl, Eddie Nixon, Edward, ElComandanteChe, Elmindreda, Enric Naval, EoGuy, Eugene-elgato, Eumolpo, Ferryca, Flowanda, Fumblebruschi, Gensanders, Glenn, Graham87, Guaka, Hairy Dude, Hannes Hirzel, Harryzilber, Heavenlyhash, Helland, Helmsjs, Hgilbert, Hwardsil, IlyaKorolev, Intelati, J.delanoy, JEG, JLaTondre, JTN, Jacen6788, Javlonson, Jennypei, Jim.henderson, Jnc, Jncraton, Joe102283, Jphastings, Jsoon eu, Kbdank71, Kbrose, Kevinalewis, Kku, KnowledgeOfSelf, Kvng, Kyz, Leafyplant, Leptictidium, Lerdsuwa, Liempt, LilHelpa, Lockley, Mange01, Materialscientist, Matthuxtable, Matusz, Maximaximax, Michael Hardy, MichaelJanich, Mild Bill Hiccup, MischaO, Miym, Moazami, Moogwrench, Mormegil, Mrpeterobrien, Mulad, Mushroom, Mwanner, Mxn, Nageh, Niteowlneils, Nixdorf, Orange Suede Sofa, Oscarthecat, Oyvind.misje, Pegasus1138, Petruss, Phatom87, Piet Delport, Pillaidee, Radagast83, RedWolf, Regin LARSEN, Rememberway, RexNL, Rich Farmbrough, Rick Block, Rick Sidwell, Riick, Rjstott, Robofish, Romangs, RyanCross, S.K., Sachipra, Salsal99, Samtheboy, ShaunMacPherson, SimonP, Skarg, Smalljim, Smallman12q, Snoyes, Sonja Connell, Tagishsimon, Takanoha, The Anome, The Rambling Man, Thierryc, Tirupur123451, Tristanb, Una Smith, Undsoft, Unyoyega, Vegetator, Velella, Vonkje, Vrenator, WhisperToMe, Whosasking, Wiki alf, Wtshymanski, X!, Yekrats, Ykhwong, Youandme, Yyy, Zipz0p, Zondor, 275 anonymous edits Internet Protocol Source: http://en.wikipedia.org/w/index.php?oldid=464756848 Contributors: 2w133, A-moll9, A. B., ARUNKUMAR P.R, Abb615, Abdull, Adagio Cantabile, Addihockey10, Aggelos.Biboudis, Ahoerstemeier, Aldie, Altesys, Alvin-cs, Andareed, Andre Engels, Andywandy, Angelo.biboudis, Antiuser, Anttin, Anwar saadat, Ardonik, Arkrishna, Attilios, BAxelrod, Badanedwa, Bdesham, Beefman, Bennor, Bentogoa, Biot, Bjornwireen, Blanchardb, Blehfu, Blue520, Bobguy7, Bobo192, Borislav, Brest, Brianga, Bridgecross, Brim, Brouhaha, Bryan Derksen, Bryanbuang1993, CALR, Calltech, Camilo Sanchez, Capricorn42, Caramdir, Carlo.Ierna, Casey Abell, Cbdorsett, Cburnett, Cdyson37, Ceo, CesarB, Chealer, Chenzw, Christian List, Closedmouth, Conversion script, Coolcaesar, Coralmizu, Corruptcopper, Courcelles, Cverska, Cwolfsheep, Cybercobra, Cyclonenim, Cynthia Rhoads, DARTH SIDIOUS 2, Dan D. Ric, Daniel Staal, Daniel.Cardenas, DanielCD, DeadEyeArrow, Defyant, Demian12358, Denisarona, Dmaftei, Dnas, Doria, DrBag, Drugonot, Dwheeler, EagleOne, Echuck215, Eclipsed, Eequor, El C, Elfguy, Enjoi4586, Epbr123, Erodium, EverGreg, Evil saltine, FGont, Felipe1982, Ferkelparade, Fish147, Florentino floro, Formulax, Forton, Fredrik, FrummerThanThou, F, Galoubet, Gamera2, GaryW, General Wesc, Giftlite, Glane23, Glenn, Goatbilly, Graciella, GraemeL, Grafen, Graham87, Hairy Dude, Hardyplants, Harvester, Hayabusa future, Helix84, Hemanshu, Hetar, Hughcharlesparker, I am Me true, Iamregin, Imcdnzl, Imroy, Intgr, Ixfd64, J.delanoy, JHolman, JTN, Jack Phoenix, Jadounrahul, JamesBWatson, Jasper Deng, Jauhienij, JavierMC, Jdforrester, Jeff Carr, Jheiv, Jiddisch, Jimgeorge, Jimys salonika, Jnc, Jno, JohnGrantNineTiles, JonHarder, Justsee, KD5TVI, Karl McClendon, Karol Langner, Katalaveno, Kbrose, Kgfleischmann, Kim Bruning, Kocio, Krellis, Kubigula, Kukini, Kvng, L Kensington, Latitudinarian, Liangent, Lion789, Looxix, Lotje, Love manjeet kumar singh, Maerk, Mahabub398, Mailtomeet, Mammad2002, Mange01, Manop, ManuelGR, Markr123, Marr75, Max Naylor, Melter, Mike Rosoft, Mikieminnow, Mindmatrix, Mion, NGNWiki, Naive cynic, Nakon, NawlinWiki, NeoNorm, Nialldawson, Nightraider0, Nimiew, Nixdorf, Noformation, Noldoaran, Northamerica1000, Nubcaike, Nubiatech, Nugzthepirate, O, Ogress, Olathe, Otolemur crassicaudatus, Oxymoron83, Paolopal, Patrick, Paul, PaulHanson, PedroPVZ, Phatom87, Philip Trueman, Pinkadelica, Piotrus, Plustgarten, Poeloq, Poweroid, Ppchailley, Python eggs, Rabbit67890, Recognizance, Reedy, Reub2000, Rgclegg, Rich Farmbrough, Richard Ye, Rjgodoy, Rkrikorian, RobertG, Robocoder, Rsduhamel, Ryamigo, Ryanmcdaniel, Sandstein, SasiSasi, Scientizzle, Scientus, Shiftoften66, Shlomiz, Shoeofdeath, Sir Arthur Williams, Sjaak, SkyLined, SmilingBoy, Smyth, Some jerk on the Internet, Sonicx059, Sophus Bie, SpaceRocket, SpeedyGonsales, Stephenb, Stevey7788, Supaplex, Suruena, Sysiphe, THEN WHO WAS PHONE?, TakuyaMurata, Tarquin, Teles, Template namespace initialisation script, Tezdog, The Anome, The Transhumanist (AWB), Thorpe, Timwi, Tiuks, TkGy, Tobias Bergemann, Tommy2010, Torla42, Trevor MacInnis, Tristantech, TutterMouse, UncleBubba, Urvabara, V-ball, Varnav, Vary, Versageek, Versus22, VillemVillemVillem, Voyagerfan5761, Warren, Wayiran, Wayne Slam, Wcourtney, Wereon, Where, Whitepaw, Wik, Wikibob, Wikisierracharlie, William Avery, Wknight94, Woohookitty, Wrs1864, Wtmitchell, Yahoolian, Yamamoto Ichiro, Yausman, Yidisheryid, Yyy, Zarcillo, Zundark, Zzuuzz, , , 493 anonymous edits Internet protocol suite Source: http://en.wikipedia.org/w/index.php?oldid=464338629 Contributors: 130.243.79.xxx, 203.109.250.xxx, 213.253.39.xxx, 66.169.238.xxx, A8UDI, Aapo Laitinen, Abdull, Abdullais4u, Acceptus, Acroterion, Aeonx, Ahoerstemeier, Alansohn, Albanaco, Aldie, Ale2006, Alek Baka, AliMaghrebi, Aliasptr, Alireza.usa, AlistairMcMillan, Amungale, Ana Couto, Anna Lincoln, Anororn, Arcenciel, ArchonMagnus, Arteitle, ArticCynda, Avant Guard, Avicennasis, Axcess, AxelBoldt, B4hand, Barberio, Barnacle157, Bender235, Bentogoa, Bernard Franois, Betterworld, Bezenek, Bhavin, Biot, Bloodshedder, Bmicomp, Branko, Brian.fsm, Brion VIBBER, Camw, Canthusus, CaptainVindaloo, Carnildo, Casey Abell, Cate, Cburnett, Chadernook, Cheesycow5, Ckatz, Coasting, Conversion script, Coolcaesar, CrinklyCrunk, Ctm314, Cybercobra, Cynthia Rhoads, DARTH SIDIOUS 2, Damian Yerrick, Daniel Staal, DanielCD, Darkhalfactf, DavidDW, DavidDouthitt, Denisarona, DerekLaw, Dgtsyb, Dicklyon, Disavian, Dmeranda, Dnas, Dogcow, Doradus, Dorgan65, Doug Bell, Drphilharmonic, Duffman, EagleOne, Ed g2s, Edmilne, Edward, Edwardando, Eeekster, Ekashp, Electron9, Ellywa, Elwood j blues, EncMstr, Enjoi4586, Epbr123, Eptin, Equendil, Ericl234, Erik Sandberg, Ethanthej, Etu, Evil Monkey, Evil saltine, Expensivehat, Falcon9x5, Ferkelparade, Fixman88, Fr34k, Freyr, GaelicWizard, Geneb1955, Gilliam, Glane23, Glenn, GlobalEdge 2010, Globemasterthree, Golbez, GordonMcKinney, Graham87, Gringo.ch, Gsl, Guy Harris, Haakon, Hadal, Hairy Dude, HarisM, Harryzilber, Hcberkowitz, Headbomb, Helix84, Here, Hoary, Holylampposts, Hpnguyen83, Hyad, IMSoP, Ilario, Imcdnzl, Imran, Indeterminate, Inhumandecency, Inomyabcs, Intgr, Itai, J.delanoy, JTN, Jackqu7, James Mohr, JamesBWatson, Jantangring, Jatkins, JesterXXV, Jimp, Jmdavid1789, Jnc, Joanjoc, John Vandenberg, Johnblade, Johnuniq, JonHarder, Jorunn, Jrogern, Jsoon eu, Jusdafax, JustAGal, KYPark, Kaare, Kasperd, Katieh5584, Kbrose, Kim Bruning, Kim Rubin, KnowledgeOfSelf, Konman72, Koyaanis Qatsi, Krauss, Krellis, Kungming2, Kusma, Kvng, Kyng, Labongo, Larree, Law, Layer, Leapfrog314, Lee Carre, Logictheo, Lova Falk, Luna Santin, Magister Mathematicae, Maltest, Mandarax, Mange01, Manop, Marcika, Martyman, Martyvis, Master Conjurer, Matt Dunn, Mattbrundage, Matthew Woodcraft, Matusz, Mav, Mckoss, Mechanical digger, Mendel, Merlissimo, Metaclassing, Michael Hardy, Miles, MilesMi, Mintguy, Mothmolevna, Mrzaius, Mukkakukaku, Mwarren us, Mzje, NMChico24, Nasz, Navedahmed123, NawlinWiki, Nealcardwell, Nealmcb, NewEnglandYankee, Ngriffeth, Nhorton, Nick C, Niteowlneils, Nivix, Nixdorf, Nknight, Nmacu, Northamerica1000, Nubiatech, Nv8200p, Obradovic Goran, Oheckmann, Olathe, Otets, OttoTheFish, Oxwil, Oxymoron83, Palfrey, Papadopa, Patilravi1985, Paul, Paul Koning, Paulkramer, Perfectpasta, Peripitus, Pfalstad, Pharaoh of the Wizards, Phgao, Piano non troppo, PioM, Plugwash, Pokeywiz, Poslfit, Pps, Public Menace, Punjabi101, Putdust, Quinxorin, R'n'B, RaNo, Radagast83, Ramnath R Iyer, Rayward, Reaper Eternal, RedWolf, Reliablesources, RevRagnarok, Rich Farmbrough, Rich257, Richardwhiuk, Rick Block, Rick Sidwell, Rjd0060, Rjwilmsi, RobEby, RobertG, RobertL30, Roberta F., Robost, Rodeosmurf, Ross Fraser, Rrelf, Rserpool, Runis57, Ruthherrin, SJP, STHayden, SWAdair, Samjoopin, SasiSasi, Seaphoto, Sheldrake, Shii, Shiraun, Shiro jdn, Shizhao, Sietse Snel, Sjakkalle, Skullketon, Smartse, Smjg, Snaxe920, SnoFox, Spmion, Stahla92, Stefan Milosevski, Stephan Leeds, Stephenb, Suffusion of Yellow, Sully, SuperWiki, Suruena, Svick, Swhitehead, Swpb, Ta bu shi da yu, Tagishsimon, Tarquin, Techmonk, Techpro30, Template namespace initialisation script, Tfl, That Guy, From That Show!, Thatguyflint, The Anome, The Nut, TheOtherJesse, Theresa knott, Thingg, Thumperward, Thunderboltz, Thw1309, Tide rolls, Tim Watson, Timwi, TinaSDCE, Tmaufer, Tmchk, Tobias Hoevekamp, TomPhil, Topbanana, Tr606, Tyler, Typhoon, Ukexpat, Unyoyega, Vanis314, Vegaswikian, Victor Liu, Violetriga, W163, Wadamja, Waggers, Weregeek, West.andrew.g, Weylinp, Whereizben, Wiki104, Wikid77, Wikiklrsc, William Avery, Wimt, Wolfkeeper, Wonderstruck, Woohookitty, Wrs1864, XJamRastafire, Xeesh, Xojo, Xos, Yakudza, Yas, Ydalal, Yudiweb, ZNott, Zac439, Zeerak88, Zfr, Zigger, Zoicon5, Zondor, Zundark, Zvezda1111, ^demon, , 787 anonymous edits Signalling System No. 7 Source: http://en.wikipedia.org/w/index.php?oldid=458984637 Contributors: A. B., Abhayani, Agoode, Aldie, Alohawolf, AndyAicken, Arbitrarily0, Austin512, Beardybloke, Beetstra, Beland, Bellhead, Betterusername, Bluezy, Bobblewik, Bouvierjr, Bradams, Burgee, Cacoethes curiositas, Cacophony, Calltech, CecilWard, Cela Etant, ChrisUK, Chuckiesdad, Cmdawson, Cmihaic, Crissov, CyberSkull, DanMS, Derek Ross, Dgtsyb, Djames42, DragonflySixtyseven, Drevil55, Dstasiak, Dwonak, Edwardando, Eeekster, Epolk, Falcon Kirtaran, Fsiler, Gabi S., Galmicmi, Graham87, Gsl, Guthrie, Guy Harris, Harryzilber, Highspeed, Hoho, Hollomis, IANCEE, Ian Geoffrey Kennedy, Isidrov, Jamelan, JanCeuleers, Jarsyl, Jbonocore, JeremyA, Jim.henderson, Jl20777, Joaopaulo1511, Johnuniq, JonRoma, Joshaidan, Just Another Dan, Karada, Kbrose, Khalid hassani, Kotasik, LeaveSleaves, Leedryburgh, Leeyc0, Lincoln Josh, Longhair, Ludwigs2, Lyndon.bye, MER-C, Madspiral, Manuelamsp, MarkWahl, Maury Markowitz, Nikevich, Noono, Oystein, PPBlais, PhilippeAntras, Pjacobi, Rafael Vargas, Rahulmoksha, Requestion, Rich Farmbrough, Rob.au, Sam Hocevar, Sfisher, Sharkb, SimonP, Sirgorpster, Some standardized rigour, Tagishsimon, Teknotelecom, The Anome, Thenickdude, Tonyhansen, Txomin, Tyler.szabo, Ulf Abrahamsson, Voidxor, VoxLuna, Waskage, William Avery, Witt04gti, Xorsyst, Yaronf, 237 anonymous edits Public switched telephone network Source: http://en.wikipedia.org/w/index.php?oldid=463646455 Contributors: -ramz-, 213.253.40.xxx, Abdulraheemsidz, Abtinb, Adamn, Adrian Sampson, Agnvoip, Alan Millar, Aldie, Ale jrb, AlephGamma, AmiDaniel, Andre Engels, Anthony.selby, Austria156, Bellhead, Birczanin, BobbyLee, Bobo192, Bunnyhop11, Calltech, Cameron Dewe, Chetvorno, ChrisUK, Closedmouth, Conversion script, Crissov, Cryptic, Darkaddress, DavidCary, Deadlyturtletank, Dgtsyb, Dicklyon, Disneyfreak96, Doug, DrDorkus, Dragont, Duckbill, Dwandelt, Dysprosia, Ebernat, Elkman, EoGuy, Espoo, Falcon Kirtaran, Fourpointsix, GeorgeLouis, Glenn, Gloop, Graham87, Gsl, Guy Harris, H, Harryzilber, HenryLi, Hirudo, Hm2k, I-baLL, Ian Geoffrey Kennedy, Iridescent, Isdnip, JMiall, JTN, Jan Friberg, Jim.henderson, JohnOwens, JohnTechnologist, Joseph Solis in Australia, Jpbowen, Kbrose, Kgfleischmann, Kvng, Leonard G., Looxix, Loupeter, MBisanz, Machina.sapiens, Mahehere, Makru, Manassehkatz, MarkWahl, Markus Kuhn, Max Schwarz, MerlinMM, Michael Hardy, Miguelito2010, MikkoM, Mlaffs, Monkey Bounce, Mysid, Nethgirb, Netmonger, New2way, NickBush24, Niteowlneils, Nobodyinpart, Nono64, Oli Filth, OwenX, Patrick, Petri Krohn, Pmj, Polaralex, Poweroid, Quietbritishjim, Radiojon, Ranjandutta, Rchandra, Redlentil, Rfc1394, Richardelainechambers, Rick7425, Rjwilmsi, Rkononenko, Rohaq, Rsrikanth05, SEWilco, Sharkb, SimonInns, Sln3412, Snafflekid, SteveDay, Steverapaport, Tagishsimon, Taroaldo, The Anome, Tony1, Tusixoh, Verkhovensky, Vipinhari, Voipsatellite, WikHead, William Avery, WordyGirl90, Youandme, Yukoba, Yunghkim, Yurik, Zahakiel, ^demon, 250 anonymous edits Voice over IP Source: http://en.wikipedia.org/w/index.php?oldid=460387511 Contributors: .::Arbitrary::., 123microsoft123, 159753, 16@r, 23skidoo, 28421u2232nfenfcenc, 6birc, A. B., A.Ward, A876, AJR, AVMsoftware, Abesford, Academic Challenger, Acalamari, Acce245, Accountwiki2, Acidburn24m, Adam78, Adclark88, Addihockey10, Adjektiv, Adoresoftphone, Aelman, Agnvoip, Ahoerstemeier, Ajrichens, Akram1997, Alansohn, Ale jrb, Alejo2083, Alex de carvalho, Alexander Straub, AlistairMcMillan, Alokagga, Alphachimp, Altesys, Alw75, Alxeedo, Amalia07, Amandavpi, Amescreative, Ananth t, Andre nsi, AndrewKay, Andromeda451, Andypandy.UK, Angr, Anon2, Antonio Lopez, Apapadop, Apyule, Archelon, Aresnika, Argon233, ArkansasHistory, Ashton1983, Ashumit02, Asimzaidi123, Atlant, Atlasvoice, Ausinha, Avi.dorfman, Av, Azazello, BRUTE, Babajobu, Banes, Bansaribarot, Beboy10, Beetstra, Beland, Ben.c.roberts, BenFrantzDale, Bender235, Beno1000, Bevo, Bfurst, Biggkid5, Bigtex 1, Billhunt, Billkor, Binksternet, Biot, Bluezy, Bobblewik, Bobo192, Boffin, Bogdanwiki, Bonius,

Article Sources and Contributors

Boogachamp, Bowmanjj, Box News, Bozsingdani, Bphenix, Bprincipi, Bradleyyard, Braeside, Brandon, Brest, Brocha, BrokenSegue, Brycen, By97aa, C172rg, CTZMSC3, Cabiria, CalamityGNDM, Caliqt84, Calltech, Caltas, CambridgeBayWeather, Camie333, Camptown, Can't sleep, clown will eat me, CanisRufus, Canthusus, CapitalR, Capricorn42, CardinalDan, CaribDigita, Cbarbry, Ccowling, CesarB, Chaldor, Charles Matthews, Chealer, ChrisJMoor, Chrislk02, Christopher Mahan, Churb75, Cielomobile, Cindyt27, Civil Engineer III, Ckatz, Clairecare, Cliconnect, Clq, Cluth, Coffee, Colin Keigher, Colonies Chris, Combes, CommEvo, Computerjoe, Connelly, Coolmac860, Coreyxbs, Cre8d, Crosbiesmith, Crutter, CsamFord, Cst17, Cweath7, Cyberdyme, Cyrilfr, Cyrius, D.c.camero, DDeckert, DaMenace123, Daev, Daikiri, Dan100, DanielCD, DanielVonEhren, Danr2k6, Dapps007, Daquell, Dask137, DaveSymonds, Daven200520, Daveslomo, Davfox, David Johnson, David Sorf, David.a.gelman, Dawnseeker2000, Db11710, Dbollard99, DeadEyeArrow, Deeahbz, Deeprig9, Deineka, Dennis70, DennisDaniels, Depill.is, DerHexer, Desecrator, Deserthawks, Dgtsyb, Diberri, Diego.viola, Diverman, Dlsieradzki, Dlyons493, Dmar198, Dobregon, Dobrien, Docboat, Donama, Doretel, DoretelCom, Double DKool, DrDorkus, Dreadstar, Dreamafter, Drinking.coffee, Dspanalyst, Duckdad, Ed Poor, Edgeley, Edtealdi, Efrondozo, Egstcm, Ejwma, ElBenevolente, Elbperle, EncMstr, Enochlau, Enric Naval, Eorlov, Epastore, Epbr123, Epl18, Erianna, Ethan01, Europrobe, Evanwolf, Everyking, Evice, Expertu, F, F Notebook, FT2, Falcorian, Faradayplank, Fastfission, FayssalF, Fennelcm, Firetrap9254, Flambib, Flod logic, Fluffernutter, Foodeei, Foofy, Forkqueue, Fram, Francis Good, Francs2000, Fred Bradstadt, Fred Gandt, Free Bear, Freeness, Fresheneesz, Freshtel, Freyr, Frizzle, Funkyguy, Fvp, Fyrael, GRD, GULFSIP.Engineer, GULFSIP.voip.engineer, Gabrielyan, Gadfium, Gail, Galoubet, Garvanet, Gbleem, Ged Davies, Ged UK, Geekking, Geep23, Gfoley4, Ghadsall, Giftlite, Gilliam, Gimpmask, Glendonflowers, Glenitec610, GlobalEdge 2010, Globaltransmitter, Gobbagoo, Goblin, Gogo Dodo, GoingBatty, Gopalkrishnan83, Goplett, GraemeL, Graham87, GregA, GrooveDog, Guaka, Gubbay, Gurchzilla, Gwernol, Gwicke, HUnger, HWSager, Haakon, Hack-Man, Hadal, Hairy Dude, HappyInGeneral, Harryzilber, Headbomb, Henrygb, Hetar, Hgarciagg, Hipvoice, Hnram96, HockeyInJune, Holme053, Hooiemajoris, Hooman.marandi, Hooperbloob, Hope work, Hopper96, Hrbrendan, Hugh168, Hughzhu, Husond, Hydrargyrum, IMac4ME, Ibanix, Ignorance is strength, Ikanreed, Imcdnzl, InShaneee, Incnis Mrsi, Indangermouse, Infrogmation, Inotbf, Insanephantom, Intelafone, Interchangegroup, Intercompages, Interiot, Ipatrol, IronGargoyle, IronHelix, Iskitoofast4u, It Is Me Here, Itsme, Itusg15q4user, Ixfd64, J Milburn, J Santoso, J.delanoy, JHunterJ, JSsoftware, Jadams76, Jafeluv, Jaho, Jalal0, James086, JanCeuleers, Jana Grare, Janahan, Jasenlee, Jasonon, Jasper Deng, Javacava, Javamen, Jbrock11, Jcline0, Jcyrus80, Jebba, Jeffholton, Jeffman78, Jeffq, Jehochman, JeremyR, Jerome Charles Potts, JetLover, Jezaraknid, Jhessela, Jhknight, Jidanni, Jignesh.4soni, Jim.henderson, Jimp, Jimthing, Jjspirko, Jmabel, Jnavas, Joe1945-01, JoeSmack, John Doe or Jane Doe, John Vandenberg, Johnflan, Johnleemk, Johnnie ong, JohnnyB, JonHarder, JonTeh, Jone5050, Jongrant, Jonolumb, Jonuday, Joseph Solis in Australia, Joy, Jptdrake, Jreconomy, Jroddi, Jrtayloriv, KF, KVDP, Kaare, Kamaniskeg, Karada, Karl-Henner, Karl2620, Karn, Katalaveno, Katiker, Kazvorpal, Kbrose, KelleyCook, Ken Olsen, Kevincw01, Kevinmon, Key134, Kgfleischmann, Kglavin, Kgrr, Kikos, King adan, King of Hearts, Kingkobus, Kingpin13, Kiscica, Kku, Klapouchy, Koavf, Kozuch, KrakatoaKatie, Krallja, Kristof vt, Kryn1030, Kushal one, Kusma, Kvng, Kw27, Kylu, Kyng, LOL, Landroni, Lankiveil, Lansal, Larry2342, Lazydaisy, LeaveSleaves, Leeyc0, Lerdsuwa, Lethe, Leuk he, Linkspamremover, Linuxerist, Liquid Chrome1, LittleOldMe, Lolwarrior, Lootzy, LorenzoB, Lotje, Louietyj, Lozza, Lrlfrance, Luke Bales, Luna Santin, Lupo, MBK004, MER-C, MLD7865 Auto, Mac100, MacGyver07, Macdmq, Mad Carew, Maggu, Makefreecalls, MamboJambo, Manickaselvam, MansonP, Manticore, Manuel Anastcio, Manuelamsp, Marc Lacoste, Marco79, MarcoAurelio, Maris Jansons, Mark v1.0, MartinHarper, MartrtinS, MartynDavies, MasterfulTroll, Matanya (renamed), Matthew Yeager, Matthewbulat, MattieTK, MattisManzel, Mattsday, MaxDowney, Mcfutech, Mclowes, Mcsboulder, Meaghan, Mehrdadd, Mendel, Merkel, Michael Hardy, Mike Gale, Miken2005, Miladchik, Miltiades490bc, Mindmatrix, Mingthemad, Misterbigbrain, Mkzz, Mmccalpin, Mobidick0, Mobutu LM2006, Mohammed 77b, MonoAV, Monsieur champs, Mormegil, Morruga, Morte, Mote, Motoroflife, Mr.chetanladdha, Muhandes, Mukat, Mulligatawny, Murdamw, Muru, MusicTree3, Mws1979, Mxn, Myleslong, Mylivetech, Mysdaao, Mysekurity, Mysidia, N Yo FACE, NTK, Nageh, Nandini, Natl1, Naudefj, Navstar, NawlinWiki, Neilc, NerdyNSK, Nethgirb, Neustradamus, New2way, Newton2, Niazza, NickW557, Nikzbitz, Nishkid64, Nitinkrgupta, Nloth, Nneonneo, Noel Streatfield, Nono64, Nonodename, Notwist, Novum, Nubiatech, Nww mag, Oblivious, Ochib, Ohnoitsjamie, Oli Filth, Oliver.Shepherd, Oliver202, Olivier, Omegatron, OverlordQ, Ozeki, Paidup, ParticleMan, Paul August, Pchov, PdDemeter, Peruvianllama, Pessi, Peter Hitchmough, Petrb, Pfwebadmin, Pgilman, Phatom87, Philip Trueman, Phoenix-forgotten, Phyzome, Piano non troppo, Picaroon, Pinnocchio, Pjbrockmann, Pjrich, Pnm, Poeloq, Pogostokje, Pol098, Polscifreak, Ponyo, Poorleno, Postdlf, Poweroid, Pparazorback, ProblemAssassin, Prunk, Pseudomonas, Pshibles, Pugglewuggle, Pugliavi, Quiensabe, Quintin3265, Qwyrxian, R'n'B, R3m0t, RadioKirk, Radioraiders, Rafehh, Rainman74, Rajarshic02, Ramshi1, Randy Johnston, Rapido, Rasmus Faber, RasputinAXP, Rchamberlain, Rearden9, Reedy, Reffidini, Remember the dot, Renffeh, RexNL, Rhobite, Rich Farmbrough, Richardjohnstone, Rick7425, Rillian, Ringbang, Rishishringan, Ritterrat, Rjwilmsi, Robertbricker, Robertvan1, RoboAction, RoccoKIT, RockMFR, Ronz, Rose Booth, Rrburke, Rrw, Rubgwobouhgrwoosf, Rudykog, Ruhrfisch, Rupertb, S.K., S3000, SJP, SMC, SUparJErk, Saaga, Sadads, Samw, SasiSasi, Schmidtja, SchuminWeb, Scott0485, Scottperry, Seajay1979, Seajay19791, Sean Whitton, Secretflower, Shadowjams, Shandris, Shara77, Sharonpfingo, Sharonxiv, Shebazahmed, Shii, Shinjodenn, Shizane, Signalhead, Silverfox196, SimonInns, SimonP, Simsim4, Skarmachild, Skinkie, Slon02, Smalljim, Smasafy, Smitty, Smostowfi, Smyth, Soptep, Sosodank, Spacestationshuttle, Sparklyfeet, Spearhawk, Spencer.fry@yale.edu, Spiko-carpediem, Splatg, Splendour, SqueakBox, Squideshi, Squids and Chips, Squiquifox, Squire of the Infernal Knight-Lord of Penguins, StaticGull, Stefano85, Stepa, Stephan Leeds, Stephen Lange Ranzini, Steven312, Stevertigo, Stevevogelnu, Stilldavid, Strait, Strib, Stuart Ward UK, Stupid2, Stwalkerster, Sumantu.mittal, Superm401, Surge79uwf, Susyr, Sweetpoet, Sylverboss, Symbianguru, Synchrite, Sywyk, T2X, TJJFV, Tabletop, Tarquin, Tarret, Tassedethe, TastyPoutine, Tchin-NJITWILL, Tckma, Tcncv, Techman224, Tecpc2001, Teemuk, Telecom.portal, Tenbaset, Tgeairn, Tglovoip, Thakkar v, Thane Eichenauer, The Anome, The Belgain, The Rambling Man, The Storm Surfer, The Thin Man Who Never Leaves, The bellman, TheKMan, Thedp, Theh1982, Therebelcountry, Thingg, Thinkingphones, Thiseye, Thomas Blomberg, Thompsontough, Tim Ivorson, Timrem, Tizio, Tkoeppe, Tliberty10, Tmaufer, Tmnmt, ToP Racer, Tom k&e, Tombomp, Tomjenkins52, Tomwalden, Toniher, Tony1, Towel401, Toytoy, Tran Quoc123, Trevor MacInnis, Tslocum, Twizler3, Tylko, Ulf Abrahamsson, Ulric1313, UltraMagnus, Unixer, Unused0030, Utcursch, VCA, VSteiger, Val42, Vanished user 39948282, Vaquerito, VegaDark, Vegaswikian, Veinor, Veledan, Veromark, Versageek, Vespristiano, Vickygarg, Villarinho, Vina, Vinnythejinny, Vinogradovisoleksii, ViperSnake151, Vipinhari, Vmart, VoIPExpert, Voice99, VoiceNet, Voicepulse, Voidvector, Voip-solution, Voip.world, Voipfone, Voipphoneservice, Voiptopia, Voixium, Volker, Voskypro, Votingontheinternet, Voxbone, Vrenator, Vy0123, W Nowicki, WR:ichibantel, Wafulz, Waggers, Wannabav8r, Wavelength, Welsh, Weregerbil, Werelnon, West.andrew.g, WhaleyTim, Whicky1978, Whiskers9, WhiteBoy, Who, Who123, Wholived, WibblyLeMoende, WikHead, Wiki alf, WikiBlogger61, Wikidmoz, Wikieditor06, Wikivoip, Wile E. Heresiarch, WilliamKF, Wimt, Windharp, Wlpekar, Wmahan, Wongm, Woohookitty, Wrathchild, Wtmitchell, Wtshymanski, Wwwqq, Xdenizen, Yahoolian, Yamamoto Ichiro, Yaronf, YongKim, Yoshboy, Yueni, Yurik, Zachripples, Zervaman, ZimZalaBim, Zimbabweed, Zondor, Zwz8406, Zzuuzz, Zzyzx11, ZzzBrett, , , 2172 anonymous edits Session Initiation Protocol Source: http://en.wikipedia.org/w/index.php?oldid=461284626 Contributors: A.M., AIMSzpc, Adem reid, Agnvoip, Alan Smithee, Alansohn, Alf Boggis, Algocu, AlistairMcMillan, Altesys, Amirshaheen, Amniarix, Andyparkins, Antzervos, Armando, Ashleyarmitt, Ausinha, Avi.dorfman, Azurepalm, B timmins, B1ll1ngsl34, Batsonjay, Bazza37, Bchatelet, Bender235, Biot, Blatkinson, Bluezy, Bobet, Bpadinha, Brandon, Brazil4Linux, Brest, Bubuka, Calltech, Can't sleep, clown will eat me, Carlos-alberto-teixeira, Carre, Cburnett, Cfeet77, Chris Roy, Christopher Mahan, Codecmdr, Conversion script, Cub001, Curtis Newton, Cybercobra, Cyrius, DabMachine, Daniel.Cardenas, Dariuspomaha, DataSurfer, David Johnson, DavidAyers, DeadEyeArrow, Dewikipeder, Dgtsyb, Dhughes, Donsez, Doug Bell, DrMac, EagleEye96, Ed Poor, Edcolins, Edward Waverley, Edwilson97, Ehjelmeland, Ejabberd, Elgaard, Emvee, Enjoi4586, Ennustaja, Eproulx, Equendil, Eric boutilier, Erikgje, Eshouthe, Etu, Excirial, Faico, Fanf, Flambib, Franl, Frap, Fred Gandt, GentlemanGhost, Geomaster1, Gogo Dodo, Graham87, GreyCat, Gronky, Gshaham, Gtamas, Guaka, Hairy Dude, Harryzilber, Hopper96, Hu12, Hujaza, I don't remember my username, I'm not human, IMSoP, Ibc wiki, Int21h, Isnow, Itai, Jadahl, James nits, Jay.Here, Jbonocore, Jcgriffiths, Jdi153, Jeffme, Jehochman, JesperANielsen, Jfayel, Jharrell, Jniemi, Joehamiltonjr, Joevf, Johnpseudo, Johnthesmith, JonTeh, Jpdemont, Judzillah, Julesd, Kasperd, Kat, Kbrose, KenCFTeam, Kgfleischmann, Kinema, Kjtobo, Kkkdddiii, Kmorozov, Koavf, Kvng, Kyng, Laurie G, Layer, Leandrod, Liftarn, Lincoln Josh, Linkminer, Lion789, Logixoul, Lradrama, Lupin, Luser, Lzur, MMuzammils, MSGJ, Magnus Manske, Malcolmredheron, Mange01, MartynDavies, Master of Puppets, MathsPoetry, Matt Darby, Matt tw, Matthi2, Maury Markowitz, Mboedick, McCarthur, Metamagician3000, Miguel.lima, Mindmatrix, Molestash, Monk127, Morte, Mpm777, MrJones, MrOllie, Mram80, Mranga, MrsJonesical, Mulad, Mulligatawny, Neustradamus, Nexus501, Noahspurrier, Notheruser, Now3d, Nubiatech, Nyco, Odd bloke, OldMan, Olle.johansson, Oxymoron83, PM800, Pagingmrherman, ParadialEditor, Patcito, Pbranfield, PeterB, Pgk, Phatom87, Pinkunicorn, Pmsyyz, Pnetz, Pugliavi, R'n'B, Raanoo, Rathee, Rchamberlain, RedWolf, Requestion, RichiH, Rick Block, Riffic, Ringbang, Rjwilmsi, RobLa, Russellbryant, Rzelnik, Salmar, Satch69, Schweini, Scienceguy8m, Sdrtirs, SeanLegassick, Seav, Serych, Seyhan Aydin, Sgodin, ShaunMacPherson, Sietse Snel, Silverfox196, Sim, Sipexpert, Skowa, Smyth, SpaceFlight89, Strait, Strongsauce, SudoMonas, Surf08008, Suruena, Taed, Tanovic, Teemuk, Tekalpha, Thane Eichenauer, TheMandarin, Tietew, Tliberty10, Tom Morris, Torzsmokus, Touisiau, Towel401, Ttlkr, Ttwaring, Tuxa, Tzury, UncleBubba, Utcursch, Verdatum, Voidxor, Voip81, Voixium, WR:ichibantel, Wensong, Will Beback Auto, Wk muriithi, Wongm, Wormhole80, Wrs1864, Yaronf, YordanGeorgiev, Yun-Yuuzhan (lost password), Zhong.xie, Zoicon5, 523 anonymous edits User Datagram Protocol Source: http://en.wikipedia.org/w/index.php?oldid=464994264 Contributors: 28421u2232nfenfcenc, A5b, Aapo Laitinen, Alfio, Ali@gwc.org.uk, Alison22, Alvin-cs, Aram33, Ardonik, Ashmoo, Ayeroxor, BAxelrod, Beacon11, Beefman, BenAveling, Bender235, Benqmonitor, Bentogoa, Bobby Caudwell, Bobstopper, Borgx, Bryan Derksen, Burisch, Cassan, Cburnett, Chenzw, Chiefmanzzz, Cincaipatrin, Conrad.Irwin, Conversion script, CraSH, CrookedAsterisk, Cvalda, DSatz, Damian Yerrick, Daniel Staal, DavidSol, DeadEyeArrow, DennyColt, DesTroy, Dfurbeck, Dicentra, Djordjes, Dkogh, E Wing, E090, Eagleal, Eclipsed, Enjoi4586, Erik Garrison, Esmond.pitt, Falcon9x5, Fennec, Fightin' Phillie, Flewis, Fredrikh, FrisoB, Frodet, Fromageestciel, Fubar Obfusco, Fudgefr, Gamera2, Giftlite, Ginkgo100, Gnipahellir, Golwengaud, Gordoni, Gorryf, Gracefool, Graham87, Gsmgm, Guy Harris, Hdante, Headbangerkenny, Hitherebrian, I dream of horses, Icestorm815, Ideoplex, InverseHypercube, Irrypride, Itai, JNighthawk, JTN, Jengelh, Jjinno, Jncraton, Joachim Wuttke, Joanjoc, Johnny 0, Johnuniq, Jtk, Jna runn, Kbrose, Kgfleischmann, Kinema, Kovianyo, Krellis, Kvng, Kwamikagami, Kyng, Lissajous, Locos epraix, MLeb, Mahjongg, Mam711, Mange01, Mani1, Materialscientist, Matt Darby, Michael Zimmermann, Mike Dill, Mike6271, Misterdom, Modulatum, Mpeg4codec, Mwholt, Neilc, Nixdorf, Nroets, Nubiatech, Od Mishehu, Ouimetch, Oxymoron83, Paulish, PedroPVZ, Pelesl, Petri Krohn, Phatom87, Plugwash, Public Menace, Quiddity, R2richar, Razorflame, Rebecca, Recurring dreams, RedWolf, Rememberway, Reub2000, RevRagnarok, Reywas92, Rick Sidwell, Robbe, RobertL30, Romanm, Ronz, Rwwww, S-n-ushakov, SWAdair, Samersarhan83, Sammydee, Samuel, Sci13960, Smeggysmeg, Spearsall, Ssd293, Suruena, Tdangkhoa, Teemuk, Teh roflmaoer, Template namespace initialisation script, The Anome, The Monster, The Utahraptor, The-tenth-zdog, Thray, Tjdw, Tobias Bergemann, Towel401, Tpbradbury, Twinxor, UncleBubba, Upadhyaykc, Vinu Padmanabhan, Voidxor, WestwoodMatt, Wiarthurhu, Wkcheang, Xezbeth, Zara1709, ^demon, , , 327 anonymous edits User agent Source: http://en.wikipedia.org/w/index.php?oldid=457507603 Contributors: ATMB, AVRS, Ac565, Adamhauner, Afed, Aidan W, Ajunne, Alansohn, Ale2006, Alias777, AlistairMcMillan, Andrew-916, Andyluciano, Angrykeyboarder, Antidrugue, Anrion, Arthuran, Asutherland flpt, Atomic1fire, BACbKA, Barek, BarkerJr, Beanboy89, BelDonah, Bensin, Bruce89, Btipling, Btrem, Burgundavia, C:Amie, Calrfa Wn, CanisRufus, Cattyman, Ceedia, Chris83, Chrispederick, Closedmouth, Computerjoe, CosineKitty, CryptoDerk, Curriegrad2004, Curtissthompson, DePiep, Diego Moya, Ehheh, ElfQrin, Eraserhead1, Ernstdehaan, Fennec, Fmccown, Frap, Gaius Cornelius, Ge0rge, Geraldaine, Geremia, Gheesh, Gorndog, Grawity, H2g2bob, HPSCHD, Hadlock, Hairy Dude, Hd86, Herve s, Holek, Hu12, Hydrargyrum, Hydrogen Iodide, IMSoP, Ice Ardor, Ikkejw, Imroy, Ivan Btora, Jeltz, Jeremyb, JetarR, Jhsounds, Jidanni, John Broughton, JonHarder, Jor, Joshua Issac, Karora, Kaze0010, Kbrose, Kim Bruning, Koavf, Kyhwana, Lamarca, LarrHoff, Lazugod, Leif, Lesoria, Levineps, Liebeskind, Lobner, LunaticBeatnik, M1ss1ontomars2k4, MaXiMiUS, Mabdul, Macinta, Marcus Wendel, Martin lindhe, Mathiastck, Max David, Mbloore, Mboverload, Mets501, Michael Hardy, Midoribe, Mike Rosoft, Minesweeper, Minghong, Mmj, MobiMe, Modulatum, MoofOntario, Moronicles, Motophil, MrOllie, MuZemike, Mvp, Nagle, Nandesuka, Nickshanks, Ojigiri, Omgoleus, Omniplex,

125

Article Sources and Contributors

Passani, Pathoschild, PaulMEdwards, Pbb, Pcr, Peng, Pigman, Pinball22, Pinecar, Plrk, Quadratic, QueenCake, Qwertydesign, Rich Farmbrough, Rktur, Robert.maclean, Ronz, RossPatterson, Ryanrs, ST47, Schapel, Sdfisher, ShakataGaNai, SithBoxer, Skierpage, Sl, SmilingRob, Softtest123, SpH1nX, Sperxios, Splibubay, Stephan Leeds, Stephenpace, Taka, Taras, Tgotchi, Thecheesykid, Thivierr, Thumperward, TrentonLipscomb, Tristen.wentling, Tutv, Tyomitch, Typhoon, Vikingstad, Warren, Wavelength, Wereon, WikHead, Wikiacc, Wikieditor06, Wouter, Wrs1864, Young7, Zidane2k1, Zigamorph, 343 anonymous edits Hypertext Transfer Protocol Source: http://en.wikipedia.org/w/index.php?oldid=461742239 Contributors: 1234r00t, A!eX, A-moll9, Aapo Laitinen, Abdull, Abu ali, Acdx, Adoniscik, Agawish, Agupte, Ahoerstemeier, Aitias, Alansohn, Aldie, AlefZet, Alerante, Ali@gwc.org.uk, AlistairMcMillan, Amalthea, Andareed, Andkim99, Andre Engels, Android Mouse, Angus Lepper, Anna Lincoln, AnotherSprocket, Anwar saadat, Apparition11, Arch o median, Ash, Ashley Y, Asj123fds, Asteiner, Astroview120mm, Atemperman, Audriusa, Avb, Avnjay, Baa, Babbage, Babedacus, Babysabre, Bamkin, BaronLarf, Basil.bourque, BeakerK44, Beefyt, Beinder, Beland, Ben-Zin, BenBildstein, Benandorsqueaks, Benanhalt, Bernfarr, Betacommand, Betterworld, Bevan7, Bevo, Bg, Bgwwlm, Bihco, Bjankuloski06en, Blade44, Blanchardb, Blm, Bluemask, Bluerasberry, Bobo192, Bongwarrior, Booyabazooka, Bpantalone, Brian.fsm, Brownsteve, Bull3t, C. A. Russell, C.Fred, CWii, Callmederek, Calor, Caltas, Calvin 1998, Cameltrader, Can't sleep, clown will eat me, Canderson7, Capricorn42, CardinalDan, Catamorphism, Cburnett, CecilWard, Cedy, Chadfiller, Charles Gaudette, Chasingsol, Checking, Chenqiang.prc, ChongDae, Christian75, Chruck, Coasting, Conversion script, Coroberti, Corpx, Cryptic, Cwolfsheep, Cyberstrike3000X, CyrilB, DKEdwards, DVdm, Daf, Dalitvoice, Damian Yerrick, Damnreds, DanBLOO, DanBishop, Danculley, Daniboydl07, Danielfolsom, DasRakel, Davidjk, Davilima, Dawn Bard, Dcoetzee, Ddas, De728631, DeadEyeArrow, Delicates, Delirium, DerBorg, DerHexer, DigitalNinja, Dionyziz, Discospinster, Dmyersturnbull, Doria, Dr bab, Drcwright, Dspradau, ENeville, Earthlyreason, Edward, Ehn, El C, ElKevbo, Electron9, Eli the Bearded, Elimerl, Ellywa, Elving, Englishrose, Enjoi4586, Ent, Epbr123, EphemeralJun, Equendil, Esanchez7587, Evil Monkey, Ewawer, Extransit, Eyreland, Femto, Ferkelparade, Firetrap9254, Flockmeal, Frap, Fred Bradstadt, Furrykef, Fuzzygenius, GJHC1, GW Simulations, Gaccolin, Gaius Cornelius, Gamernotnerd, Gdo01, Gen. von Klinkerhoffen, Gfoley4, Giftlite, GimliDotNet, Godtrog, GordonMcKinney, Gracenotes, Graciella, Graham87, Grantglendinning, Gregkaye, Grouse, Gscshoyru, Gsiegman, Gurchzilla, Guy Harris, Haakon, Habbabuba91, Haiiiiilllsatana, Ham Pastrami, Hans Genten, HappyCamper, Happysailor, HarisM, Haseo9999, Hashar, Hashproduct, Helix84, HexaChord, Horsten, Hrafnkell.palsson, Hrvoje Simic, Htonl, Hu12, Hydrogen Iodide, Hyperthermia, IMSoP, IShadowed, Icairns, Idyllic press, Ihatejava, Iluvcapra, Imnotminkus, Imroy, Incnis Mrsi, InfoRetrieval, Interiot, Intgr, Irrypride, Itpastorn, Ivank06, Ivko, Ixfd64, J.delanoy, JHolman, JTN, Jaan513, Jacobolus, JamesBWatson, Jarkospratt, Jarkspratt, Jdowland, Jeffq, Jeltz, Jennica, Jleedev, Jmar777, John Quiggin, John Vandenberg, John of Reading, Jojhutton, Jonathan O'Donnell, Jonnabuz, JonoF, Josh3736, Joyous!, Jrobinjapan, Jstrater, Jusdafax, JustAnotherJoe, KAtremer, KGasso, Ka-Ping Yee, Karingo, Karl Dickman, Kbrose, Kesac, Kesla, Kgfleischmann, Kinema, Kiwi128, Knutux, Koavf, Kocio, Konniret3, Korealin, KrakatoaKatie, Krellion, Krellis, Ksn, Kundor, Kungfuadam, KurtRaschke, Kvng, Kwi, Kylu, Kymacpherson, La Parka Your Car, Lady Serena, Lannm, Leafyplant, Lee Carre, Lee J Haywood, Lethe, Lezek, Lightdarkness, Lilac Soul, Linusnk, Lloydpick, Lotje, Lotu, Lproven, Luna Santin, Lupinoid, Lysdexia, M4gnum0n, MLauba, Mabdul, Macademe, MackSalmon, Madhero88, Maebmij, Magaman dude, Magioladitis, Mange01, Marek69, Martin BENOIT, Marx01, Materialscientist, Mathiastck, Mdd, Mdf, Meekohi, Mehfuz, Meneth, MikeF, Mikerlynn, Mindmatrix, Mjb, Mlibby, Mmj, Mnot, Modster, Mohammedsheikh786, Mormegil, Moustafaza, Mpeylo, Mr Stephen, MsDivagin, Mschel, Mumia-w-18, Mwarren us, Mwtoews, Nanshu, NawlinWiki, Negrulio, Nevyn, NewEnglandYankee, Newone, Nezzadar, Nicolas1981, Nigelj, Nightraider0, Nightstallion, Nikola Smolenski, Ninly, Niqueco, Nixdorf, Nixeagle, Nknight, Nlu, No Guru, Nubiatech, Nurg, Nyelvmark, ObfuscatePenguin, Okyea, Omniplex, Oneiros, Optiguy54, Orbnauticus, OsoLeon, Oxymoron83, Papadakis2007, Part Deux, Pascal666, Patrick, Paul Mackay, Paul-L, Pb30, Persian Poet Gal, Petero9, Pforret, Phatom87, Philip Trueman, Piano non troppo, Pioneerking, Pip2andahalf, Praefectorian, Produke, Psychonaut, Pxma, Qff828, R3m0t, RHaworth, RJaguar3, RainbowOfLight, Rainman-sr, Raise exception, RandomHumanoid, Ravik, Reach Out to the Truth, RedWolf, Reschke, Retiono Virginian, RexNL, Rhaskallion, Rich Farmbrough, Rischmueller, Rjwilmsi, Rmhermen, Rmosler2100, RobMattson, Robert Xia, RockMFR, Ronhjones, RossPatterson, Rror, RyanCross, Ryulong, SJP, SWAdair, Sae1962, Saebjorn, Sakkath, Salvio giuliano, Samuel, Sander Sde, Saoshyant, Saturn star, SchnitzelMannGreek, Schwallex, Scientus, Sdrtirs, Sean Whitton, Seb-Gibbs, Sekro, Shadowjams, Sharon08tam, SheeEttin, Shiftoften66, Sietse Snel, SiobhanHansa, SixSix, SkE, Socrates2008, SoftX, Spaceman85, Spandrawn, Sparky132, SqueakBox, Sri Krishna Geova Allah, Sses401, Stephan Leeds, StephenBuxton, Stephenb, SteveLoughran, Stevenup7002, Stolee, Stupid Corn, Suppie, Suruena, Syrthiss, T-borg, THEN WHO WAS PHONE?, Tabledhote, TakuyaMurata, Tbhotch, TechTony, Template namespace initialisation script, Tempodivalse, TenOfAllTrades, Th.matt.wiki, The Anome, The Thing That Should Not Be, The Utahraptor, TheJosh, Think777, Thumperward, Tide rolls, Timc1212, Timmywimmy, Timneu22, Tlesher, Tobias Bergemann, Tobias382, Todd Vierling, Tomaxer, Tommy2010, TonyAiuto, Toto Mommam, Tpbradbury, Tpirfan28, Tregoweth, Trusilver, TuukkaH, UU, Uncle Dick, Uncle G, UncleBubba, Universalss, Universimmedia, Uruiamme, Utcursch, VMS Mosaic, Versus22, VictorAnyakin, Vinoth.t, Voxii, Wayne Hardman, Wikipe-tan, Wikipelli, Wintonian, Wizzard2k, Wolfomatic5, Woohookitty, Wtmitchell, Yacht, Yaronf, Yomcat, Yonatan, Yuhong, Zachlipton, Zalnas, Zvn, ^demon, le flottante, 1192 anonymous edits H.323 Source: http://en.wikipedia.org/w/index.php?oldid=457803432 Contributors: Aegis Maelstrom, Aesopos, Ali@gwc.org.uk, Andreas Kaufmann, Arteitle, Avi.dorfman, Bedel23, Beland, Blehfu, Bluezy, Bobet, Bontenbal, Brandon, Calltech, Cbarbry, Ceros, CosineKitty, Cwhuang, DaveHowe, Deeahbz, Dgtsyb, Donnyw, DopefishJustin, EdgeOfEpsilon, ElTyrant, Ernestvoice, Fleminra, FoeNyx, Folajimi, GChriss, Giraffedata, Graham Rule, Guaka, Gurch, Haakon, Harryzilber, Hu12, Hvtuananh, ICU Global, ITU-T, Igoldste, Ilbc, JanCeuleers, Jdiegmueller, Johnny.cespedes, Jose.anda, Kbrose, Kcordina, Kenyon, Kgfleischmann, KillerChihuahua, Konrads, Kvng, Lupo, MER-C, Marc Mongenet, MarkWahl, Mikecron, Mikewax, Mindmatrix, Miraculix, Mulligatawny, Munford, NMChico24, Nasa-verve, Nimeshc, Nit-RAM, Nunners, Onewhohelps, PanagosTheOther, Paulej, Phatom87, Phoenix-forgotten, Qz, R'n'B, Razorflame, Rchandra, Rg3, Rjwilmsi, Rorymcd, Royk, Sergey999, Slashdevslashtty, SudoMonas, Tagishsimon, TheMandarin, Tipiac, Tonkie, WR:ichibantel, YordanGeorgiev, Yurik, 162 anonymous edits H.225.0 Source: http://en.wikipedia.org/w/index.php?oldid=460846408 Contributors: Ab762, Angela, Ascendmax, DragonflySixtyseven, Guy Harris, Harryzilber, JanCeuleers, Key134, MarkWahl, Microwaven, Natl1, Nit-RAM, Prof3G, Saxbryn, 16 anonymous edits Skinny Call Control Protocol Source: http://en.wikipedia.org/w/index.php?oldid=443591361 Contributors: Alex.ryazantsev, Bibster, Brandon, Cwolfsheep, DagErlingSmrgrav, Ewlyahoocom, Gabi S., Guaka, Ibenjamin, Infectecide, JTN, Jbond00747, Jeheyer, Kbrose, LoveMutt, Lrm242, ManosFate, Mav, Mellowiz, Oystein, Philip Trueman, RocksInABox, Sietse Snel, The gorilla, TheTito, Theloniouszen, Varano, Wiwaxia, Wk muriithi, Yaronf, 39 anonymous edits Real Time Streaming Protocol Source: http://en.wikipedia.org/w/index.php?oldid=458139198 Contributors: 6birc, Adeian, Aldie, Alerante, Alexh19740110, Alone Coder, Andrew1214, Armando, Barek, Ceefour, CesarB, Chenzw, Conversion script, Daniel.Cardenas, Davidjsmith67, Dcljr, DennisRobinson, Developer anu, Diberri, DonDiego, Dplore, Enjoi4586, Fabriciodosanjossilva, Facorread, Fudoreaper, Guaka, Hatsandcats, Hello32020, Hummerim, Hymek, Ice Ardor, Int21h, J. M., John smith4092, Johnny shaw, Kate, Kbrose, Koenige, Kostmo, Kuldip.sagar, Kvng, Lee Carre, Login to my passion, Mamaberry11, Mange01, Maxlapshin, Mishka.medvezhonok, Mithaca, Mulad, NeilFraser, NellieBly, Now3d, Ottexpert, Phatom87, Pravisas3, Purplefeltangel, Pxma, ReCover, Rentier, Rezd, RoyBoy, Roychai, Rrjanbiah, Sampart, Sdrtirs, SpaceFlight89, Suruena, TRiG, Technobadger, Telecomtom, TheMandarin, Tobias Hoevekamp, UncleBubba, Venkytv, Vina, WikHead, Ykanada, Zanetu, 198 anonymous edits Real-time Transport Protocol Source: http://en.wikipedia.org/w/index.php?oldid=460153585 Contributors: Alerante, Allefant, Andy pryor, Antoncampos, Arunsjamwal, Avi.dorfman, Bobo192, Bodnotbod, Brandon, Brigman, Cedars, CesarB, Ceyockey, Chaotic Mind, Conversion script, Cory Donnelly, Csabka, Cschim, DKEdwards, Dac04, Daniel.Cardenas, Dcoetzee, Dgtsyb, Diana cionoiu, Dokaspar, Doncrawley, DrMac, E n sh, Echoray, Enjoi4586, Fleminra, FrankTobia, Gaius Cornelius, Gduffy, Glenn, Hairy Dude, Honeyman, Hu12, Itai, Itsgeneb, JTN, JirkaHnidek, Joaopais, John smith4092, JohnOwens, Josemariasaldana, Juliancolton, Karn, Kbrose, Keancaptinh, Kenyon, Kgfleischmann, Kinema, Kkailas, Ko-, Koavf, Kurienmathew, Kvng, Ling.Nut, Lzur, MMuzammils, Malcolmst, Mange01, Marlogger, Mazevedo, MementoVivere, Mgream, Michael Devore, Mikewax, Mild Bill Hiccup, Muriel Gottrop, Mwtoews, Nixdorf, Pagingmrherman, Prasado, Puckly, RN1970, RTP123, Rapsar, Sceptre, SciComTech, Sdrtirs, Smartyepp, Snuffkin, Soumyasch, Stan3, Strait, Suruena, Susantab, TechMaker, Teemuk, Tero, Tfelber, Thakkar v, TheKMan, TheMandarin, Thelittlemouse, Tresiden, TwilligToves, Tzartzam, Vadmium, Victor Trac, Vina, Wikisierracharlie, Woolf44, Wrs1864, Yaronf, YordanGeorgiev, Yurik, 169 anonymous edits RTP Control Protocol Source: http://en.wikipedia.org/w/index.php?oldid=450319509 Contributors: A.Petrenko, Burgundavia, Calle, DKEdwards, Fabricationary, Glenn, Grokus, Hairy Dude, Honeyman, Karlviistuhat, Kbrose, Kgfleischmann, Kvng, Largesock, Mange01, Mgream, Muhandes, Radone1, Rentier, Ruud Koot, Scaife, Some birdie, Stillwaterising, Suruena, TheMandarin, Timc, Vaclav.preclik, YordanGeorgiev, Yrithinnd, Yurik, 53 anonymous edits Telephone number mapping Source: http://en.wikipedia.org/w/index.php?oldid=441886532 Contributors: Abasota, ArchiSchmedes, David Kernow, Ed Poor, Eequor, Ellmist, Farrokhi, Frank Shearar, Fudoreaper, Gaius Cornelius, Gwachob, Hairy Dude, Herwart.wermescher, Hm2k, Jacobly, Jamelan, John Vandenberg, Josep1c, Just Another Dan, Kaisershatner, Kbrose, Kozuch, Kusma, Lzur, Marx Gomes, Newsocialmedias, NoGringo, OwenBlacker, Owl Jolson, Petr Kopa, Phatom87, Prunk, Psheld, Purplepiano, Pvr12, Radiojon, Raybellis, RedWolf, Rjwilmsi, Rogper, Saxifrage, Smyth, Tabor, Vatsid, WilliamKF, WirelessMike, Wmahan, , 103 anonymous edits ITU-T Source: http://en.wikipedia.org/w/index.php?oldid=450607068 Contributors: 802geek, Alvestrand, Anrie Nord, Arkrishna, Armando, Ashwin, Awesimo, AxelBoldt, Behind The Wall Of Sleep, Benpierce, BertK, Bkonrad, Bmastenbrook, Bobblewik, Byrial, Cat5nap, Cavrdg, Celendin, Chaosfeary, Colonies Chris, Conversion script, Coolcaesar, Creative1985, Crissov, Damyot, Danceswithzerglings, Derek56, Deville, Edward, Emperorbma, Eyreland, Fanf, Fbahr, Fgcscm, Georgia guy, Ghettoblaster, Glenn, Guy Harris, H, Harryzilber, Himanshu0812, Huub v H, ITU-T, Icairns, Isnow, JanCeuleers, Jeremy Visser, Jfdontigny, Jiraffe, Jivemind, Jsbee1954, KAMiKAZOW, Kemorgan, Ksn, Kurykh, Kvng, Lotje, Lousyd, Mac, MacJuan, MarkPos, MarkWahl, MementoVivere, Merlion444, NBS, Nibblus, Nixdorf, Nono64, Odam, OverlordQ, PDH, PPBlais, PaulHanson, Pawnbroker, Pcb21, Peter.Ramez, PrologFan, Quistnix, R3m0t, Radagast83, Random Task, RatherJovialTim, RedWolf, Rholton, Rjm656s, RobLa, Sam8, SamH, ShoobyD, SudoMonas, Superm401, Tagishsimon, Talkie tim, The Anome, TimVickers, Timwi, Tobias Ahl, Urhixidur, UtherSRG, W Nowicki, Waveletrules, Webwat, West London Dweller, Wk muriithi, Wtmitchell, Xag, Yaronf, 99 anonymous edits European Telecommunications Standards Institute Source: http://en.wikipedia.org/w/index.php?oldid=458197351 Contributors: Alexwiththehair, Alkeno, Astronautics, Bernopedia, Chaitanya.lala, Charliearcuri, Cleared as filed, Conversion script, Cybercobra, Cyrus XIII, Edcolins, Fastily, Ffirmin, Ghettoblaster, Glenn, Guti jorge, Harryzilber, Hu.alexandre, Iandiver, Icairns, Ida Shaw, Jannex, Jondel, Joy, KnightRider, Koyn, Kurushima, Kurykh, Kvng, LA2, Liftarn, Mac, Mahjongg, Malepheasant, Mange01, Matt Crypto, Neelix, Open2universe, Pap3rinik, Pegship, Pgan002, Poseidon 5190, Pvosta, Rich Farmbrough, SDJ, Stevegiacomelli, The Anome, Tuir, Unyoyega, WO2, Ykanada, 30 anonymous edits

126

Article Sources and Contributors

Internet Engineering Task Force Source: http://en.wikipedia.org/w/index.php?oldid=457917789 Contributors: Abhayakara, Adzinok, Akradecki, Aldnonymous, Alvestrand, Am088, Andrewpayneaqa, AnnaFrance, Aperson1234567, Athletic ro, Bazza 7, Behind The Wall Of Sleep, Behnam, Bkkbrad, Blobglob, Borgx, BuffStuffer, Cbl62, Charlierichmond, Chester Markel, Cjkporter, CodeCaster, Conversion script, Coolcaesar, Coopkev2, Css, Cybercobra, Darguz Parsilvan, E Wing, FrenchIsAwesome, Ghettoblaster, Glenn, Graham87, Gregbard, Guanxi, HJ Mitchell, Hardaker, Howcheng, Icairns, Jeffreyschiller, Jlenthe, Jnc, JonHarder, Joseph Solis in Australia, Jovianeye, Jrp, Jules.lt, Knuckles, Koavf, Krauss, LA2, Liftarn, Livingthingdan, Looxix, Lotje, Luksuh, Magnus.de, Matthewdingley, Mindmatrix, Ninly, Noldoaran, Now3d, Olrick, P199, Paolopal, Paul, Paul Foxworthy, Paulehoffman, Philosopher, Polimerek, Reallycoolguy, Rich Farmbrough, Rjwilmsi, Rob evans, RobLa, Spearhead, Stephen Gilbert, Sunray, Suruena, SusanLesch, The Anome, Tonyhansen, Tothwolf, TruthPraiser, Ummit, Uncle G, Vrenator, W163, Wayne Slam, Wikiborg, Y(J)S, Yakovsh, Zearin, Zigger, 82 anonymous edits Request for Comments Source: http://en.wikipedia.org/w/index.php?oldid=458269549 Contributors: Abune, Ahoerstemeier, Ais523, Alex rosenberg35, Alvestrand, Amalthea, Ancheta Wis, Andre Engels, AndrewWTaylor, Angela, Antandrus, Anthony Appleyard, Ardonik, Bevo, Bk0, Blahma, BonsaiViking, Bsdlogical, Byrial, CanisRufus, Carlosguitar, Cate, Cburnett, ChrisRuvolo, Christian List, Circeus, CodeMonk, Conversion script, Coolcaesar, Cspan64, Deineka, Delirium, DerHexer, Dilbert, Dismas, Dori, Dtobias, EdC, Edcolins, ElKevbo, Elchonon Edelson, Emperorbma, Emurphy42, Esampathj, Espoo, Evercat, Evertype, Folajimi, Furrykef, Galoubet, Gerrit, Grafman, GregorB, Grendelkhan, Gtrmp, Hairy Dude, Hayabusa future, Hooloovoo, Howcheng, IMSoP, Javawizard, Jeekc, Jerith, Jiy, Jkrey, Jnc, John254, Jor, Jrp, Kaihsu, Kbrose, Kdz, Kieff, Kingpin13, Klemen Kocjancic, Knuckles, LA2, LC, Liftarn, Looxix, Lotje, Lucio, Lupin, MER-C, Mac, Malcolmj1, Man It's So Loud In Here, Marco Krohn, Marnanel, MartinSpamer, Maurice Carbonaro, Mav, McGinnis, Mel Etitis, Mendalus, Mike Rosoft, Mindmatrix, Mormegil, Mrwojo, Mykolas OK, Nanshu, NapoliRoma, Nate Silva, Nazi 2007, Nealmcb, Noumenorian, Nuno Tavares, Omniplex, Outlyer, Paul1337, PaulHanson, Phantomsteve, Philip Trueman, Philosopher, Pkarjala, Polimerek, Qwerty0, RandallJones, Randolf Richardson, RedWolf, Rfc1394, Riana, Rich Farmbrough, Rick Block, Ringbang, RobLa, Rossj81, RoySmith, Rune.welsh, SchuminWeb, Scurra, Shadowlynk, Skarebo, Spellmaster, Srbanator, Stephan Leeds, Stephen Gilbert, Suruena, Tero, The Anome, The Belgain, Thickslab, Timwi, Tobias Bergemann, Tothwolf, Ttlkr, Vary, VeryVerily, W Nowicki, Wanion, Weppos, Wilinckx, Wrs1864, Yaronf, Zhen Lin, Zippedmartin, Zundark, Zzyzx11, var Arnfjr Bjarmason, , 165 anonymous edits Institute of Electrical and Electronics Engineers Source: http://en.wikipedia.org/w/index.php?oldid=461323981 Contributors: 092platinum, 17Drew, 1rankman, 4meter4, A. di M., AKMask, Abdull, Abelson, AdjustShift, Adpete, Aeons, Aintneo, Alam bakshi, Aldie, AleaJactaEst, Alexei Polkhanov, AlistairMcMillan, Alphaknave, Altenmann, Alvestrand, Amr9090, Andrei Stroe, Andres, Ansell, Anterman, AnthonyMastrean, Ap, Apoc2400, Armando, ArnoldReinhold, ArsniureDeGallium, Aspenlogic, Asumboler, Avraham, Benji Franklyn, Benyang, Bodnotbod, Borgx, Borlandersja, Borminjeth, Bovester, Bradlito, Bratsche, Brozozo, Bryan Derksen, Charles Matthews, Chrisc62, Christian List, CiscoManager, Clifflandis, Cntras, Colejohnson66, Coolcaesar, Countblack, Crimson Twilight, Croben, Csrus, Cybercobra, Cyrius, DARTH SIDIOUS 2, DGG, Da Joe, Daderot, David.Monniaux, Debsdelectables, DeePatton, Dingy, Dogcow, Domitori, Don Braffitt, Donarreiskoffer, Drae, DragonflySixtyseven, Dsc, Dsp13, Dtneilson, Dtwitkowski, Dverma, Eaolson, Edcolins, Edinborgarstefan, Emvee, Enochlau, Epbr123, Erkan Yilmaz, EscapingLife, Esrever, Ethicalhacker, Eye heart pizza, Faisal zubaer, Fereidunian, Firien, Folajimi, Gaius Cornelius, Galois fu, Galoubet, Geni-pmd, Giftlite, Gimboid13, Gioto, Githin, Gleask, Greeney, Gsmgm, Gsp8181, Guillaume2303, Guy Macon, HarisM, Harryzilber, Head, Hermite, Herrnieman, Honbicot, Horndinkle, Hrudaya, IEEE07, Iantresman, Inconsequential, Interiot, Inwind, Itai, J5hale3, Jadedrick, Jaisaacs, JamesTeterenko, Janto, Japo, Jarekadam, Jeff G., Jim.henderson, Jimfbleak, Jll, JoeBoxer522, Joelthelion, John Vandenberg, Jon Harald Sby, Jondel, JordoCo, Jpbowen, Jtbarr4, Jube82, Juhlster1021, Julesd, Julie Dancer, Kbdank71, Kimiko, Klonimus, Koyle, KoyleJ, Kschader, Kshuyler, Kuru, Kwamikagami, LOL, LanceBarber, Lantay77, Lardon10, Latitudinarian, Leebo, Leeroyjenkins, Leflyman, Lepsteinn, Leuko, Light current, Lotje, LouScheffer, Lperez2029, MIT Trekkie, Mac, Malepheasant, MarkusHagenlocher, Marra, Martarius, Martg76, Matthew Stannard, Matthew V Ball, Matusz, Maximaximax, Mdd, Mebden, Megalibgwilia, Menchi, MithrandirMage, Miym, Mkeranat, Mlongsho315, Mmmeg, Mnemo, Monsuco, Moshekam, Mr. PIM, Mr.Z-man, MrRadioGuy, Mulligatawny, Mxn, Mysid, NAHID, Neutrality, Nick, Nikosmastorakis, Nixdorf, Nmaddali, Noel Streatfield, Nopetro, Notjim, Ntsimp, Ohconfucius, Olexandr Kravchuk, Optichan, Orderud, Osvat, Ozhiker, PamD, PaulHanson, Pbryan, PearlSt82, Pearle, Pgan002, Pgk, PhnomPencil, Pichpich, Pink!Teen, Pjacobi, Poculum, Polluks, PrimeHunter, Psuar1, Qaddosh, R'n'B, RSRScrooge, Racepacket, Raghith, Raistolo, Raul654, Razorflame, Rdchambers, Rettetast, Rhobite, Richj, Rlsheehan, RobertG, Robsomebody, RogerDP, Rollinsk, Romanm, Rookkey, S2piDLuveR, SJK, Sabbah67, Sanjaynediyara, Schibs, SchreyP, Sebastian37, Seglea, Sgg61991, Shanel, Shortride, Sigmundg, Snoyes, Sobullubos, Splash, Ssinha1981, Staecker, Stangaa, Stephengmatthews, Steve Quinn, StevenDH, Suwa, TAeiluj, TKD, Taiko3615, Tarawneh, Tarquin, Technion, ThatWikiGuy, The Anome, Theleprechaum, Thumperward, Tiddly Tom, Truthanado, Tsunaminoai, Tweedman, UltraMagnus, Ultrasonic o ke, Urhixidur, Utuado, Visorstuff, WaltBusterkeys, Walter Grlitz, WaltonBC, Wdfarmer, Whithamcp, Wilbern Cobb, Willy on Wheels over Ethernet, Winjay, Wirpstein, Wizardist, Wmahan, Woohookitty, Wrs1864, Wtshymanski, XanderJ, Xvani, Xyrex, Yanw82, Yk Yk Yk, Zr40, Zureks, 372 anonymous edits Session Description Protocol Source: http://en.wikipedia.org/w/index.php?oldid=455554511 Contributors: Aldie, AvicAWB, Birczanin, Conversion script, Dokaspar, Doug Bell, Fsiyavud, Giwa-jp, Hamilkar, Hefo, Hu12, Inkling, JTN, JesperANielsen, Kate, Kbrose, Kgfleischmann, Kinema, Kvng, Mange01, Mark McLoughlin, Maximaximax, Melamed katz, Mgream, Otherox, Raanoo, RedWolf, Rich Farmbrough, RobLa, Robertabela, Ryans.ryu, Shenshu, SixSix, Stuuf, SystemBuilder, Wrs1864, 38 anonymous edits

127

Image Sources, Licenses and Contributors

128

Image Sources, Licenses and Contributors

File:Internet layering.svg Source: http://en.wikipedia.org/w/index.php?title=File:Internet_layering.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: Jsoon eu (talk) File:Message flows.svg Source: http://en.wikipedia.org/w/index.php?title=File:Message_flows.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: Jsoon eu (talk) File:Message flows and Routing.svg Source: http://en.wikipedia.org/w/index.php?title=File:Message_flows_and_Routing.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: Jsoon eu (talk) File:Protocol and Software layering.svg Source: http://en.wikipedia.org/w/index.php?title=File:Protocol_and_Software_layering.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: Jsoon eu (talk) File:IP stack connections.svg Source: http://en.wikipedia.org/w/index.php?title=File:IP_stack_connections.svg License: GNU Free Documentation License Contributors: en:User:Kbrose File:UDP encapsulation.svg Source: http://en.wikipedia.org/w/index.php?title=File:UDP_encapsulation.svg License: GNU Free Documentation License Contributors: en:User:Cburnett original work, colorization by en:User:Kbrose File:SRI First Internetworked Connection diagram.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SRI_First_Internetworked_Connection_diagram.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Russavia File:SRI Packet Radio Van.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SRI_Packet_Radio_Van.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Russavia Image:IP stack connections.svg Source: http://en.wikipedia.org/w/index.php?title=File:IP_stack_connections.svg License: GNU Free Documentation License Contributors: en:User:Kbrose Image:UDP encapsulation.svg Source: http://en.wikipedia.org/w/index.php?title=File:UDP_encapsulation.svg License: GNU Free Documentation License Contributors: en:User:Cburnett original work, colorization by en:User:Kbrose File:Voip-typical.gif Source: http://en.wikipedia.org/w/index.php?title=File:Voip-typical.gif License: Creative Commons Attribution 1.0 Generic Contributors: JMPerez, - File:SIP signaling.png Source: http://en.wikipedia.org/w/index.php?title=File:SIP_signaling.png License: Public Domain Contributors: Dewikipeder, Noir, Ysangkok, 1 anonymous edits Image:Http request telnet ubuntu.png Source: http://en.wikipedia.org/w/index.php?title=File:Http_request_telnet_ubuntu.png License: Public Domain Contributors: TheJosh File:Typical H.323 Stack.png Source: http://en.wikipedia.org/w/index.php?title=File:Typical_H.323_Stack.png License: Public Domain Contributors: ITU-T (talk). Original uploader was ITU-T at en.wikipedia File:H.323 Architecture.png Source: http://en.wikipedia.org/w/index.php?title=File:H.323_Architecture.png License: Public Domain Contributors: ITU-T (talk) File:Establishment of an H.323 call.png Source: http://en.wikipedia.org/w/index.php?title=File:Establishment_of_an_H.323_call.png License: Public Domain Contributors: ITU-T (talk) File:H.323 High-level call flow.png Source: http://en.wikipedia.org/w/index.php?title=File:H.323_High-level_call_flow.png License: Public Domain Contributors: ITU-T (talk) File:A typical H.245 exchange.png Source: http://en.wikipedia.org/w/index.php?title=File:A_typical_H.245_exchange.png License: Public Domain Contributors: ITU-T (talk) Image:Ejemplo ENUM.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Ejemplo_ENUM.jpg License: Public domain Contributors: Conscious, Joey-das-WBF, Kozuch, Petr K Image:Call Forwarding with ENUM.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Call_Forwarding_with_ENUM.jpg License: Public domain Contributors: Conscious, Incnis Mrsi, Joey-das-WBF, Petr K File:IEED UD.jpg Source: http://en.wikipedia.org/w/index.php?title=File:IEED_UD.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Countblack

License

129

License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/