1. Simulation Tools available for protocol engineering
In the network research area, establishing of network in a real time scenario is very difficult. A single test bed takes a large amount of time and cost. So implementation of a whole network in real world is not easily possible and very costly to. The simulator helps the network developer to check whether the network is able to work in the real time. Thus both the time and cost of testing the functionality of network have been reduced and implementations are made easy.
Simulation is one of the important technologies in modern time. The simulation in computer can model hypothetical and real-life objects on a computer so that it can be studied. The network is also simulated on the computer. A network simulator is a technique of implementing the network on the computer. Through this the behavior of the network is calculated either by network entities interconnection using mathematical formulas, or by capturing and playing back observations from a production network.
Some of the simulation tools are:
NS2 (Network Simulator version2): Network simulator 2 has been developed under the VINT (Virtual Inter Network Testbed) project. It is a discrete event simulator that provides substantial support for simulation of TCP, routing, and ulticast protocols over wired and wireless networks.
NS3 (Network Simulator version3): The ns-3 simulator is a discrete-event network simulator for Internet systems, targeted primarily for research and educational use. It will rely on the ongoing contributions of the community to develop new models, debug or maintain existing ones, and share results.
OPNET (Optimized Network Engineering Tools): This simulator is developed by OPNET technologies; It provides a comprehensive development environment supporting the modeling of communication networks and distributed systems. Both behavior and performance of modeled systems can be analyzed by performing discrete event simulations.
NETSIM (Network Based Environment for Modeling and Simulation): NetSim is a discrete event simulator developed by Tetcos in 1997, in association with Indian Institute of Science. It has an object-oriented system modeling and simulation (M&S) environment to support simulation and analysis of voice and data communication scenarios for High Frequency Global Communication Systems (HFGCS).
OMNET++ (Optical Micro-Networks Plus Plus): It is an extensible, modular, component-based C++ simulation library and framework, primarily for building network simulators.
JSIM (Java-based simulation): It is a Java-based simulation system for building quantitative numeric models and analyzing them with respect to experimental reference data.
OMNET++: It is a component-based, modular and open architecture discrete event simulator framework. The most common use of OMNeT++ is for simulation of computer networks, but it is also used for queuing network simulations and other areas as well. It is licensed under the own Academic Public License, which allows GNU Public License like freedom but only in noncommercial settings. It provides Component architecture for models.
QualNet: It is a commercial network simulator from Scalable Network Technologies, Inc in 2000-2001. It is ultra high-fidelity network simulation software that predicts wireless, wired and mixed-platform network and networking device performance. A simulator for large, heterogeneous networks and the distributed applications that execute on such networks
REAL: REAL is a simulator for studying the dynamic behavior of flow and congestion control schemes in packet switch data networks. It provides users with a way of specifying such networks and to observe their behavior.
Name of Network Simulator Language
NS2 C++,Otcl NS3 C++, Python
OPNET C (C++) NetSim Java
OMNeT++ C++ REAL C
J-Sim Java, Tcl
Name of Network Simulator Language
NS2 C++,Otcl NS3 C++, Python
OPNET C (C++): NetSim Java
2. Survey on protocol specification languages
SDL (Specification and Description Language): is a standardized language used for the description of architecture, behavior, data and static interface. SDL is based on experience within the telecommunications industry in describing systems as communicating state machines.
TTCN3 (Testing and Test Control Notation): TTCN is a standardized language used to write detailed test specifications. TTCN-3 has been used for the development of conformance test implementation in a range of applications
MSC (Message Sequence charts): MSC is a standardized notation used for the description of typical or exceptional message exchanges between entities. MSC diagrams provide a clear description of system communication in the form of message flows.
ECN (Encoding Control Notation): Encoding Control Notation (ECN) is an internationally standardized formal notation used to specify specialized encoding rules forASN.1. While ASN.1 specifications only deal with data that has semantics for the communicating applications, ECN specification defines the way auxiliary fields that are specific to the encoding are inserted.
UML (Unified Modeling Language) : Unified Modeling Language (UML) is a standardized language used for the collection, analysis and processing of requirements as well as for the specification message exchanges and overviews of architecture and behavior specifications. UML is standardized by the Object Management Group (OMG).
Uppaal : Uppaal is a toolbox for verification of real-time systems. It has been applied successfully in case studies ranging from communication protocols to multimedia applications.
Estelle: Estelle is a Formal Description Technique, defined within ISO (International Organization for Standardization) for specification of distributed, concurrent information processing systems. In particular, Estelle can be used to describe the services and protocols of the layers of Open Systems Interconnection (OSI) architecture defined by ISO.
LOTOS (Language Of Temporal Ordering Specification): LOTOS is a Formal Description Technique (FDT) standardized by ISO for the design of distributed systems, and in particular for OSI services and protocols. It is widely used for the specification of large data communication systems. It is mathematically well-defined and expressive: it allows the description of concurrency, no determinism, synchronous and asynchronous communications. It supports various levels of abstraction and provides several specification styles.
Design and implementation of simple FTP
FTP was created with the overall goal of allowing indirect use of computers on a network, by making it easy for users to move files from one place to another. Like most TCP/IP protocols, it is based on a client/server model, with an FTP client on a user machine creating a connection to an FTP server to send and retrieve files to and from the server. The main objectives of FTP were to make file transfer simple, and to shield the user from implementation details of how the files are actually moved from one place to another. To After a TCP connection is established, an FTP control connection is created. Internal FTP commands are passed over this logical connection based on formatting rules established by the Telnet protocol. Each command sent by the client receives a reply from the server to indicate whether it succeeded or failed. A data connection is established for each individual data transfer to be performed. FTP supports either normal or passive data connections, allowing either the server or client to initiate the data connection. Multiple data types and file types are supported to allow flexibility for various types of transfers. This end, FTP is designed to automatically deal with many of the issues that can potentially arise due to format differences in files stored on differing systems. To ensure that files are sent and received without loss of data that could corrupt them, FTP uses the reliable Transmission Control Protocol (TCP) at the transport layer. An authentication system is used to ensure that only authorized clients are allowed to access a server. At the same time, a feature sometimes called anonymous FTP allows an organization that wishes it to set up a general information server to provide files to anyone who might want to retrieve them. The interface between an FTP user and the protocol is provided in the form of a set of interactive user commands. After establishing a connection and completing authentication, two basic commands can be used to send or receive files. Additional support commands are provided to manage the FTP connection, as well as to perform support functions such as listing the contents of a directory or deleting or renaming files. In recent years, graphical implementations of FTP have been created to allow users to transfer files using mouse clicks instead of memorizing commands. FTP can also be used directly by other applications to move files from one place to another.
FTP provides an interactive interface to allow humans to interact with remote servers.
FTP allows the client to specify the type and representation of stored data.
FTP requires clients to authorize themselves by sending a login name and password to the server before requesting file transfers. The server refuses access to clients that cannot provide a valid login and password.
FTP Process Model
User Interface design: - This is used by the client to interact with user. User command put or get starts a file transfer.
File Transfer design: - This component requires two FSMs for the client and the server as the formal protocol. It concentrates on the network packets between the server and the receiver for the file transfer. The events considered are only the receiving of the network
File system module design: - This component is responsible for accessing the file systems of the sender and receiver. The sender and receiver have to read and write corresponding files, respectively. These operations are part of the actions in the FSMs
Network Module design: - This is to hide the details of the network operations and provides a higher-level interface to the FSMs for the actions which needs network interactions.
FSM for the server
The initial state of the server is STANDBY. Its event set E includes the receiving of the five types of packets from the client.
FSM for the client
State INIT is a state of the user interface, does not belong to the state set of FSM client.
1. RSVP Protocol
The Resource Reservation Protocol (RSVP) is a Transport Layer protocol designed to reserve resources across a network for an integrated services Internet. RSVP operates over an IPv4 or IPv6 Internet Layer and provides receiver-initiated setup of resource reservations for multicast or unicast data flows with scaling and robustness. RSVP can be used by either hosts or routers to request or deliver specific levels of quality of service (QoS) for application data streams or flows. RSVP defines how applications place reservations and how they can relinquish the reserved resources once the need for them has ended. RSVP operation will generally result in resources being reserved in each node along a path. RSVP is not a routing protocol and was designed to interoperate with current and future routing protocols.
2. Setting up an MANET
Abstract - Mobile ad hoc networks (MANETs) is an infrastructure-less , dynamic network consisting of a collection of wireless mobile nodes that communicate with each other without the use of any centralized authority. Due to its fundamental characteristics, such as wireless medium, dynamic topology, distributed cooperation, MANETs is vulnerable to various kinds of security attacks like worm hole, black hole, rushing attack etc.
A. MANETs characteristics
1) Distributed operation: There is no background network for the central control of the network operations, the control of the network is distributed among the nodes. The nodes involved in a MANET should cooperate with each other and communicate among themselves and each node acts as a relay as needed, to implement specific functions such as routing and security.
2) Multi hop routing: When a node tries to send information to other nodes which is out of its communication range, the packet should be forwarded via one or more intermediate nodes.
3) Autonomous terminal: In MANET, each mobile node is an independent node, which could function as both a host and a router.
4) Dynamic topology: Nodes are free to move arbitrarily with different speeds; thus, the network topology may change randomly and at unpredictable time. The nodes in the MANET dynamically establish routing among themselves as they travel around, establishing their own network.
5) Light-weight terminals: In maximum cases, the nodes at MANET are mobile with less CPU capability, low power storage and small memory size.
6) Shared Physical Medium: The wireless communication medium is accessible to any entity with the appropriate equipment and adequate resources. Accordingly, access to the channel cannot be restricted.
B. Advantages of MANET
The advantages of an Ad-Hoc network include the following:
ïƒ˜ They provide access to information and services regardless of geographic position.
ïƒ˜ Independence from central network administration. Self-configuring network, nodes are also act as routers. Less expensive as compared to wired network.
ïƒ˜ Scalableâ€”accommodates the addition of more nodes.
ïƒ˜ Improved Flexiblibility.
ïƒ˜ Robust due to decentralize administration.
ïƒ˜ The network can be set up at any place and time.
C. MANETs Challenges
1) Limited bandwidth: Wireless link continue to have significantly lower capacity than infrastructure networks. In addition, the realized throughput of wireless communication after accounting for the effect of multiple access, fading, noise, and interference conditions, etc., is often much less than a radioâ€™s maximum transmission rate.
2) Dynamic topology: Dynamic topology membership may disturb the trust relationship among nodes. The trust may also be disturbed if some nodes are detected as compromised.
3) Routing Overhead: In wireless adhoc networks, nodes often change their location within network. So, some stale routes are generated in the routing table which leads to unnecessary routing overhead.
4) Hidden terminal problem: The hidden terminal problem refers to the collision of packets at a receiving node due to the simultaneous transmission of those nodes that are not within the direct transmission range of the sender, but are within the transmission range of the receiver.
5) Packet losses due to transmission errors: Ad hoc wireless networks experiences a much higher packet loss due to factors such as increased collisions due to the presence of hidden terminals, presence of interference, uni-directional links, frequent path breaks due to mobility of nodes.
6) Mobility-induced route changes: The network topology in an ad hoc wireless network is highly dynamic due to the movement of nodes; hence an on-going session suffers frequent path breaks. This situation often leads to frequent route changes.
7) Battery constraints: Devices used in these networks have restrictions on the power source in order to maintain portability, size and weight of the device.
8) Security threats: The wireless mobile ad hoc nature of MANETs brings new security challenges to the network design. As the wireless medium is vulnerable to eavesdropping and ad hoc network functionality is established through node cooperation, mobile ad hoc networks are intrinsically exposed to numerous security attacks.
D. MANETs Applications
Some of the typical applications include:
1)Military battlefield: Ad-Hoc networking would allow the military to take advantage of commonplace network technology to maintain an information network between the soldiers, vehicles, and military information head quarter.
2) Collaborative work: For some business environments, the need for collaborative computing might be more important outside office environments than inside and where people do need to have outside meetings to cooperate and exchange information on a given project.
3) Local level: Ad-Hoc networks can autonomously link an instant and temporary multimedia network using notebook computers to spread and share information among participants at a e.g. conference or classroom. Another appropriate local level application might be in home networks where devices can communicate directly to exchange information.
4) Personal area network and Bluetooth: A personal area network is a short range, localized network where nodes are usually associated with a given person. Short-range MANET such as Bluetooth can simplify the inter communication between various mobile devices such as a laptop, and a mobile phone.
5) Commercial Sector: Ad hoc can be used in emergency/rescue operations for disaster relief efforts, e.g. in fire, flood, or earthquake. Emergency rescue operations must take place where non-existing or damaged communications infrastructure and rapid deployment of a communication network is needed.
1. TCP Protocol
Petri net model of protocol TCP is represented in Fig. 1. Notations of right system contain prefix â€œxâ€. States of diagram are represented by places of the same name. At that the additional places corresponding to flags SYN, FIN, ACK of packetsâ€™ headers are used. These places constitute the communication subsystem. Flags of packets transmitting by right interacting system have prefix â€œxâ€. Notice that, for clearness of model the flag of acknowledgement ACK is represented by separate places corresponding to its receiving either as answer on flag SYN (SYNACK), or as answer on flag FIN (FINACK). Moreover, since model does not contain the descriptions of application level protocols, commands OPEN, CLOSE, SEND are represented merely in notations of corresponding transitions. The names of residuary transitions are chosen as first letters of flags waiting for which are represented in standard state diagram of protocol.
Fig. Petri net model of protocol TCP
2. Stop and wait protocol
SPIN is a general tool for verifying the correctness of distributed software models in a rigorous and mostly automated fashion. It was written by Gerard J. Holzmann and others in the original Unix group of the Computing Sciences Research Center at Bell Labs, beginning in 1980. The software has been available freely since 1991, and continues to evolve to keep pace with new developments in the field. Unlike many model-checkers, SPIN does not actually perform model-checking itself, but instead generates C sources for a problem-specific model checker. This technique saves memory and improves performance, while also allowing the direct insertion of chunks of C code into the model.
PROMELA (Process or Protocol Meta Language) is a verification modeling language introduced by Gerard J. Holzmann. The language allows for the dynamic creation of concurrent processes to model, for example, distributed systems. In PROMELA models, communication via message channels can be defined to be synchronous (i.e., rendezvous), or asynchronous (i.e., buffered). PROMELA models can be analyzed with the SPIN model checker, to verify that the modeled system produces the desired behavior. An implementation verified with Isabelle/HOL is also available, as part of the Computer Aided Verification of Automata project.
In the mid 1980's, Estelle was proposed as a formal description technique for the specification of communication protocols. Dr. Paul Amer has been actively involved in Estelle's development since 1985 when he spent a sabbatical year in Paris, France helping define Estelle's formal semantics and syntax with Piotr Dembinski and Stanislav Budkowski. In 1989 with Professor Richard Tenney (Univ. of Mass, Boston) as Editor, Estelle was approved as an ISO International Standard. Based on communicating extended finite state machines, Estelle has a formal, mathematical, implementation-independent semantics. It is an expressive, well-defined, well-structured language that is capable of specifying distributed, concurrent information processing systems in a complete, consistent, concise and unambiguous manner.
There is little need to explore yet additional languages for formal specification; an international ISO standard based on ten years of study exists. The real challenge is to fully exploit the benefits of Estelle thereby making it as appealing and user friendly as possible to protocol specifiers. We need high quality software design tools based on Estelle: language-based graphical editors that facilitate the writing and modification of Estelle specifications, compilers that convert any Estelle specification to implementation code, simulators that emulate the message passing and extended finite state machine transition firing of any Estelle specification, etc.
The description in full LOTOS consists of two parts:
â€¢ XDT service specification
â€¢ XDT protocol specification
The protocol description is limited as with the other descriptions on the virtual communication between the protocol entities. The description of the data formats is integrated into the service and the protocol specification.
XDT service specification
The XDT service specification describes the behavior of the service interface with the service access points Sender_SAP and Receiver_SAP, referred to as S and R. The specification uses the resource-oriented style, because thereby the dependencies between the processes at the service access points can be illustrated in more detail. The specification consists of the three main processes sender, association and receiver.
Example: sender[S] |[SA]| association[SA,RA] |[R]| receiver[R]
XDT protocol specification
The protocol specification introduces three new data type definitions: XdtPduType, XdtBufferType and TimerMsgType. The other data types are taken from the service specification. The XDT PDUs are specified in the data type XdtPduType while the data type XdtBufferType describes the buffer for the DT-copies and the associated operations. The last data type TimerMsgType describes timer events. Furthermore, the signals ack_N, go_back_N, abort and end for internal communication between the processes transfer_s and ack_handler are introduced on the transmitter side.
Sliding Window Protocol
In the SWP, n sequence numbers are used ranging from 0 to nâˆ’1. Both the sender and receiver maintain a window, representing a set of sequence numbers they are allowed to send or receive respectively. The sender may send as many octets as the size of its window before it has to wait for an acknowledgement from the receiver. Once the receiver sends an acknowledgement for m octets, its window â€˜slidesâ€™ forward by m sequence numbers. Likewise, the senderâ€™s window â€˜slidesâ€™ forward by m sequence numbers if this acknowledgement arrives. For the SWP to function correctly over mediums that may lose data, the maximum size of the window is n 2. If window sizes are larger, a retransmission of a segment with sequence number i may be mistaken for a fresh segment with the same sequence number, resulting in a corrupted byte stream. As a consequence, only n 2 octet buï¬€ers are required at the receiving side. Intuitively, the SWP is a generalisaton of the ABP in which the sequence number space is split into two parts, the ï¬rst part representing the 0-bit that was used in the ABP and the second part representing the 1-bit. As an example, consider a sequence number space of size 8 and a window of size 4. Initially, both the sender and receiver have available windows of size 4. Now, the sender buï¬€ers octets 0...3 and sends two segments, one containing octets 0 and 1 and the other containing octets 2 and 3. The sender will have to wait for an acknowledgement before it can send additional data, as it has used up its entire window space. Once the ï¬rst segment arrives at the receiver, it forwards the octets in the segment to the application layer and sends an acknowledgement. Subsequently, it â€˜slidesâ€™ its window by 2. The sender also updates its window as it receives this acknowledgement. It may now send octets 4 and 5.
The implementation of the SWP that is used in TCP is diï¬€erent from our example, since octets may be acknowledged before they are forwarded to the application layer and therefore still occupy a position in the receive buï¬€er. In this case, the receiving entity reduces the size of the window through the acknowledgement segment that it sends to the sending entity, resulting in a situation. By doing this, it ensures that the sending entity does not send new data that will overï¬‚ow its buï¬€er. Once the octets are forwarded to the application layer, it may reopen the window.
During its lifetime, a connection progresses through several states. Of course, both initially and after ï¬nishing the communication the connection does not exist. In this case, the connectionâ€™s state is described as CLOSED. To initiate communications, a connection must be established. Connection establishment is initiated by issuing the OPEN call from the application layer to TCP. Opening a connection can be done either actively, meaning that the initiating side has the intention to send data, or passively, indicating that the initiating side is willing to accept incoming connection requests. Due to this asymmetry, we identify the following two scenarios:
1. The local TCP entity actively opens a connection In this case, the TCP entity instantiates the TCB in which all state information relevant for the connection will be stored. It then sends a segment with the SYN ï¬‚ag set and progresses the connectionâ€™s state from CLOSED to SYN SENT. While in this state, the TCP entity waits for an acknowledgement of the segment that has the SYN ï¬‚ag set. Upon receiving this acknowledgement, it will send back an acknowledgement and progress to the ESTABLISHED state.
A variation to this scenario is possible where the local TCP entity receives a segment with only the SYN ï¬‚ag set while in the SYN SENT state, as a result of the remote entity also actively opening the connection. In this case, the local TCP entity will send a segment with both the SYN and ACK ï¬‚ags set and progress to the SYN RCVD state.
2. The local TCP entity passively opens a connection In the second case, the TCP entity again instantiates the TCB after which the connectionâ€™s state will progress to LISTEN. While in this state, the TCP entity waits until it receives a segment with the SYN ï¬‚ag set.1 Upon receiving such a segment, it responds by sending a segment with the SYN and ACK ï¬‚ag set and progresses to the state SYN RCVD. It will then wait for an acknowledgement of this segment and progress to the ESTABLISHED state.
Again, there is a variation to this scenario where a passively opened connection may be transformed into an actively opened connection as the result of a SEND call issued from the application layer of the local TCP entity while this entity is in the LISTEN state. In this case, the local TCP entity will send a segment with the SYN ï¬‚ag set and progress to the SYN SENT state, after which the procedure will be as described before.
We see that in both scenarios, ï¬rst the initiating side sends a SYN segment. As a response to this segment, a SYN, ACK segment is sent. As this segment is acknowledged, the connectionâ€™s state at either end progresses to ESTABLISHED. This procedure is called the three-way handshake, after the three segments that are exchanged during its course.
Once the connection has reached the ESTABLISHED state, both entities have reached an agreement on the conï¬guration to use for the connection and either end will have stored the relevant data in their TCB. For both entities, among other things, this data involves the initial sequence number that the entity will use for outgoing data (ISS), the size of the send window for the entity (SND.WND), indicating the maximum number of octets that it may send at once, and the size of the receive window for the entity (RCV.WND), indicating the maximum number of octets that it is prepared to accept at once. From this point on, data transfer between the entities may take place through consecutive calls of the SEND and/or RECEIVE function from the application layer.
After having obtained a model from our System Speciï¬cation, we could verify the correctness of TCPâ†’. First, we will deï¬ne what correctness entails. In our research question, we formulated the following hypothesis for incorrect behaviour of the protocol:
1. There is a byte that is delivered to the receiverâ€™s transport layer corrupted, or
2. There are bytes that are delivered to the application layer of the receiver in a diï¬€erent order as the order in which they were delivered to the transport layer of the sender, or
3. There are bytes that are delivered to the application layer of the sender, but never delivered to the application layer of the receiver, or
4. There are scenarios in which the execution of the protocol gets stuck
For reasons discussed in chapter 4, our speciï¬cation abstracts from corrupted segments. Furthermore, we have seen that TCP performs a check on each incoming segment to see whether it starts with the octet that it expects to receive next. If this is not the case, the segment is dropped. If this check is implemented correctly, it is not possible that bytes are delivered to the application layer of the receiver in a diï¬€erent order as the order in which they were delivered to the transport layer of the sender. The third and fourth case, however, are more likely to occur in the event of an error.
Therefore, our veriï¬cation eï¬€orts focused on two aspects of our model. First of all, we veriï¬ed that its state space does not contain any deadlocks, since they are a sign of an error as a result of how we approached the speciï¬cation. If m octets must be sent and everything works correctly, the application layer at the sending end issues the SEND call m times and the receiving TCP instance issues the RECEIVE call m times, after which the protocol will indeï¬nitely perform the CONNECTION_CLOSED action. It should be clear that a deadlock does not ï¬t into this expected behaviour, and that therefore deadlocks may not occur in our model.
Second, we compared the external behaviour of our model, deï¬ned in terms of the SEND and RECEIVE calls as issued by the application layers at either end, to the external behaviour of a FIFO queue. We chose this approach over model checking since we expected the latter technique to be infeasible on a state space as large as that of TCPâ†’. The reason to model the external behaviour as a FIFO queue is that from a such a queue, elements are taken in the same order as that they were put into the queue. If the SEND call of TCP is seen as putting something into a queue and the RECEIVE call as taking something from it, it becomes immediately clear that the external behaviour of the FIFO queue is the desired behaviour for TCP: the sending entity puts some data elements into the transport medium and the receiving entity takes them all out of this medium in exactly the same order.
SIP - Session Initiation Protocol
The Session Initiation Protocol (SIP) is a communications protocol for signaling and controlling multimedia communication sessions. The most common applications of SIP are in Internet telephony for voice and video calls, as well as instant messaging, over Internet Protocol (IP) networks. The protocol defines the messages that are sent between endpoints, which govern establishment, termination and other essential elements of a call. SIP can be used for creating, modifying and terminating sessions consisting of one or several media streams. SIP is an application layer protocol designed to be independent of the underlying transport layer. It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP) . SIP works in conjunction with several other application layer protocols that identify and carry the session media. Media identification and negotiation is achieved with the Session Description Protocol (SDP). For the transmission of media streams (voice, video) SIP typically employs the Real-time Transport Protocol (RTP) or Secure Real-time Transport Protocol (SRTP). For secure transmissions of SIP messages, the protocol may be encrypted with Transport Layer Security (TLS).
SIP Conformance Analyzer is an advanced testing solution for SIP enabled products widely used in today's VoIP and 3G networks. Comprehensive tests, protocol simulation and analysis tools verify SIP compliance according to ETSI TS 102 027 / RFC 3261 ensuring high probability of interoperability. Offering a full suite of over 600 test cases, the SIP Conformance Analyzer is an automatic conformance testing solution that significantly reduces testing time and facilitates problem identification & solution, improving time-to-market. This solution is available as a SIP conformance analyzer stand-alone software product or as an option provided in the TCA8200 Conformance Analyzer or TCA 4100 Telephony Conformance Analyzer.
â€¢ Fully automatic testing of SIP protocol (RFC 3261) according to ETSI TS 102-027
â€¢ TTCN-3 suites for User Agent, Proxy, Redirect server, Registrar
â€¢ Tests for valid, invalid and inopportune SIP protocol behavior and syntax variations
â€¢ User-friendly test parameter (PICS/PIXIT values) setting
â€¢ User-configurable tests suites
â€¢ On-line and off-line analysis
â€¢ Real time display of protocol traces and test results
â€¢ Logging of trace and results to file
â€¢ Automatic test reports in text and MS Word format
â€¢ Powerful management features
...(download the rest of the essay above)