Http://www.eetchina.com/art_8800105713_617681,675277.htm.d844aaaa
Utilize the primitive-based H.323 protocol stack development VoIP system
Internet time: July 01, 2001
Developing a H.323 protocol stack is an extremely difficult task in the communication design process. It is important that complex protocol stack development needs to invest in several years of engineering design resources, and master these complex standards need to accumulate and Learning process, this article will explore the development of H.323 protocol stacks and VoIP applications encountered problems, ambiguous, difficulty. Brian Krejcarekus Software Company Briank@ussw.com Jonathan@ussw.com Using the primitive-based H.323 protocol stack development IP carrier voice (VoIP) application system is not a small task, because created a Lu The bar's application requires a lot of time to study a vague standard and complex state machine. This article uses an example of the implementation of the process and the primitive definition of the primitive to explain how to build a primitive interface-based application and a simple interface-based alternative. Before developing the protocol stack, it is recommended to browse the basic standards of H.323. H.323 is the standard promulgated by the International Telecommunications Union (ITU), consisting of a series of specific protocols, including Q.931, H.225, H.245 and ASN.1. In order to provide call signaling function, the H.323 partially fuses the H.225 and Q.931 standards. H.245 defines multiple processes to facilitate capacity information exchange (Exchange Capability), master-slave determination and channel signaling. Finally, ASN.1 specifies the data format, so that the endpoint compatible with H.323 can be interoperable. Basic concepts use H.323, it is critical to correctly understand the primitives and processes. The primitive is used to describe the structure or message transmitted between the application layer and the H.323 protocol stack. H.323 defines multiple primitives, there are four types: request, indication, response, and confirmation. The number of parameters of each primitive is variable, which is determined by the relevant process. These parameters represent communication information of the apparatus of the application layer and the protocol stack. A set of processes are defined for each protocol in the H.323 protocol. Each process represents a state machine. In most cases, the state is used to specify a set of messages, which sends and receive in a specific order. These primitives facilitate communication between the apparatus and the lower layer. Process provides specific functions that can be activated during the entire dialog in the entire dialog asynchronous start or termination, or after starting. For example, the H.245 process includes master from judgment, power information interchange, one-way, and two-way channel signaling. Among them, only signaling channels remain activated during the actual dialog process. Others just activate, send and receive data, and then terminate. The Q.931 / H.225 process includes call establishment and demolition. Figure 1 shows an implementation of a complete H.323 protocol stack. It is worth noting that this implementation relies on the network protocol stack and the real-time operating system (RTOS). Most application systems require RTOS to handle multiple processes and / or calls at the same time.
Call signaling As described above, H.323 fuses the Q.391 and H.225 protocol to provide call signaling functions. In fact, Q.931 is an ISDN-related protocol for establishing and removing calls. Although it has never intended to be applied to the VoIP application, it can provide a relatively similar related function to H.323 by adding information on this protocol. Q.931 Packet contains a plurality of parameters called information element. For example, the Q.931 packet may contain a user information unit. H.323 specifies that the user information unit must contain a H.225 message. Additional information of H.323 exists. Most of the information on gateways, gatekeepers and negotiation are carried by H.225. Q.931 and H.225 define call signaling, while H.245 defines many call services. The most common business includes the master's judgment, the ability information interchange, channel signaling. These processes are started when Q.931 establishes a call. At this time, the two terminals have agreed to interconnect, but the multimedia data is not sent and received. The master is determined from the judgment process to determine which terminal is the master, which is from. This process can be applied to: Contact the same type of media data in a negotiation; avoid and solve conflicts caused by dependencies between codons. Capability information interchange process informs the audio, video or data capabilities of the remote terminal. This avoids the ability to guess the process (ie, establish a channel and send data that may not recognize the remote terminal). Logical channel signaling process negotiates establishing a real-time protocol / real-time control protocol (RTP / RTCP) channel for transmitting and receiving multimedia data. Define Data Abstract Syntax Representation (ASN.1) standard details how to represent grammar or structured data packets, which are used to send H.225 and H.245 messages between local and remote endpoints. X.691 specifies the encoding and decoding methods between the ASN.1 syntax structure and the raw data received by the network. ITU standards such as H.225 and H.245 have specified the ASN.1 syntax structure for all protocol messages. RTP and RTCP are also included in H.323. RTP defines a message header, attached to the front end of the multimedia data packet and transmitted by the User Data Data Registration Protocol (UDP). The message header contains information about multimedia data, including sequence numbers and timestamps. RTCP uses these data to collect network performance statistics, such as jitter between groups (irregularity of measurement packet arrival time) and the loss of the packet segment. The Agreement Stack Development and Development H.323 Agreement Stack is a daunting task. Difficulties are in detail in detail and inconsistent. The standard blur causes interoperability problems, and the protocol stack transplantability is poor. Q.931 and H.225 define a call signaling process, but it is not sufficient. Compared with H.245, the primitives defined by the Q.931 and H.225 lack a full text description. In addition, the cause of chaos is an incomplete ASN.1 standard, so developers need to reverse the X.691 encoding format data. There is also a problem with the relationship between RTP / RTCP, H.245 and application layers. In H.323, the Q.931 and H.225 protocols are combined, but the fusion is not good enough. Especially the Q.931 specification contains some of the full flow charts that displays the relationship between related messages, primitives, and timeout. The H.225 marks multiple messages in Q.931 into "disabled", but there is no new process that reflects these changes. In this way, H.225 lacks sufficient information, so the document that the developer gets is not perfect. In contrast, H.245 is a definition definition protocol with a large number of flow charts. Unlike Q.931 and H.225, it specifies the parameters of each primitive. This is extremely useful, and this shows the defects of Q.931 and H.225. Although q.931 is primitive based on primitive, there is no specified item. The entire H.225 standard has only one primitive and does not provide information containing parameters. For each primitive selection field, the developer is left to the developer, so the interface of Q.931 becomes a proprietary and non-portable interface. The main aspects of affecting the H.323 protocol stack development learning curve is ASN.1.
Although asn.1 describes how to describe syntax, there are multiple methods encoding the syntax structure into a word current. X.691 specifies the package coding principle (Per), which is the encoding rule set used by H.225 and H.245. Unfortunately, the shortcomings of X.691 weakened the advantages of ASN.1. ASN.1 has the ability to extend the given syntax, and can be encoded in a fully compatible manner. However, X.691 is only roughly explained how to make coding extensions. In order to make up for the shortcomings of the X.691 standard, there is a need for a large number of reverse engineering work. This task can be avoided by purchasing ready-made protocol stack products. The combination of RTP / RTCP and other H.323 related protocols introduced more difficult to touches standard issues. In order to design a modular H.323 protocol stack, the information structure of each protocol communication is required to be carefully defined within the standard specified. The H.323 standard cannot clearly describe the interoperability of each protocol. RTP / RTCP is an example of this defect. Real-time protocol issues RTP / RTCP is a big problem for designers, as it is difficult to infer its relationship with other protocols from standards. There may be two options: RTP / RTCP processing in the application layer or processed in the lower level protocol. If the RTP / RTCP is processed at the application layer, the application must know the port number used by the RTP channel. Because the protocol stack communication is performed using the primitive, the H.245 primitive must be able to transmit all required port information to the application layer. However, these primitives do not describe the parameters of the remote host port number. Therefore, these primitives are required to modify these primitives in a non-standard manner, and the missing information is required. If RTP / RTCP is processed in the lower layer, the protocol stack requires information about the codec to call the appropriate device driver. However, this solution is not reasonable because the protocol stack must know the specific device information, and this is not portable. Creating a VoIP application To better understand how to use the H.323 protocol stack to implement the VoIP application, let us see several examples, showing the interaction between the lower level protocol and the application layer. To utilize the basic VoIP application system-based H.323 protocol stack implementation, a set of processes defined by the H.323 standard must be implemented. These processes are composed of reusable state machines, and messages based on input or output primitives are executed by state machines. Another alternative is a task, starting a new thread for each process. Either solution, input or output messages expressed with primitives occurs asynchronously. The application system program must keep the status value in these processes, and some processes may have multiple run instances. Each primitive includes multiple parameters that must be defined in the application layer. In Q.931, the parameters are quite simple and easy to understand. However, when learning the H.245 protocol, reading complex ASN.1 table structure is very difficult. The primitives of the Capability Set process are particularly complex, and the ASN.1 structure may nest 5 to 6 layers deep. This is not a simple job for people who are not familiar with Asn.1. The other core development problem of local process timing is timing, that is, to establish or remove calls to the remote host, the timing of the local process. When considering the interoperability of other H.323 implementations or applications, the research timing problem is especially necessary, and the examples of such systems include Microsoft's NetMeeting and NetSpeak's WebPhone. Although the H.323 specification reveals the dependencies between the processes, it is necessary to reveal the timing of initiating calls and establish communication needs by experimental testing and reverse engineering. Figure 2 shows the flow of the H.323 protocol stack must perform when establishing a communication relationship with the remote terminal. Note that the process on the same horizontal line may be run at the same time, but they will continue after they are completed. Q.931 Call Setup Process Starting the Call Setup Process and informs the remote terminal to have an incoming. When the call is established, a terminal may start the H.245 of the master from the judgment process or the ability information interchange process. Each terminal requires an execution information exchange process, but as long as one terminal executive is from the judgment process. The logical channel has been turned on after the interruption of the master is completed.
Finally, the conversation is turned off through another Q.931 process. Although this timing looks directly, and some dependencies are loose in the standard, it is difficult to implement this timing. Because only dependencies account for more 257 pages of the H.245 specification, it is easy to neglect when implementation. Another problem that causes the confusion caused by the flow of asynchronous execution. For example, the primary slave determination process can be performed before or after the ability information exchange process, and may be executed simultaneously or mutually over. More even, the ability information interchange process may be performed on the on the fly overce channel. This can dynamically change the codec during the dialogue, but the work burden is added to the protocol stack development. Implementation Process H.323 Defining Q.931 is the call signaling protocol, here, how to implement the actual flow. Original-based H.323 protocol stack requires application developers to define primitives and communicate with the lower level. In order to facilitate the description of the call setup process, we summarize a flow chart from the 25 pages of the Q.931 specification (Figure 3). When the call setup process is implemented, the establishment request message is first sent, and then the process waits for a alarm indication message. When the indication message is received, the process will wait a confirmation message again. If this confirmation message is also received, the process is terminated, the application can start processing the H.245 process. In order to develop a state machine based on the original H.323 protocol stack process, the developer needs to be proficient in the H.323 protocol, such as the above Q.931 call setup protocol. Note that the H.245 process is more-oriented than Q.931. Each H.245 process must be processed in accordance with the standard specified timing and send request messages. The specific implementation of each state machine will take several months. If an alternative is used, the H.323 protocol stack does not use primitives, and the protocol stack needs to include an intermediate layer that has implemented the above processes and state machines, and provides a simplified application programming interface (API). For the previous example, the protocol stack has to send an outgoing call, just call the following function: In the system implemented using the API, the MakeCall () function accepts the host name (HostName) and IP address of the remote endpoint, and performs all Call the steps of the remote terminal. The program requires a process to construct the aforementioned primitive, implementing a state machine that handles all input output primitives. Using the API-based protocol stack does not need to understand the primitive interface, you can save a monthly development time. Examples of the previous parameter assignment previous examples describe the implementation of the process. The following example shows how to assign values to the original language, as an example of "transfer.request" primitive with the ability information interchange process. "Transfer.Request" primitives have four fields, filled with ASN.1 format. These four fields are Protoid, Muxcap, Captable, and Capdescriptors. Here, we focus on the Captable parameters, which is a list of all codecs supported by a particular terminal. In this example, the padded Captable parameter indicates the following terminal capabilities: a single G.711 A law 64K codec, which is capable of receiving a packet length of 180 ms audio data. The following false code is the basic step of initializing an ASN.1 structural element. The captable parameter is actually an array of CapabilityTableEntry. The first step of populating this parameter is to assign memory space for the array. Each supported codec requires a CapabilityTableEntry. In this example, only one element is only supported by G.711 codec. Each CapabilityTableEntry has two elements: TableEnTryNumber fields and optional capability information structures. CAPTABLE [0] .capability.tableEnTryNumber = 1 (1) In the statement of row 1, CapabilityTableEnTryNumber is arbitrarily set, but the value is different in the same message.
