Application Note. Communication Services Framework Fundamentals

Transcription

1 Application Note Communication Services Framework Fundamentals

2 Application Note Communication Services Framework Fundamentals Executive Summary The Communication Services Framework (CSF) is a set of starting points for developing media and signaling communications applications with Dialogic products, allowing developers to significantly shorten their development and launch cycles. This application note takes up where Introduction to the Communication Services Framework at Svcs_Frmwk.pdf ended, by describing fundamental design concepts of the CSF. This paper focuses on the application of several well-known design patterns to manage states, handle events, and coordinate actions between CSF software elements. These mechanisms are combined to present a design for a hardware abstraction layer, non-telephony services integration, and application startup/shutdown management. This application note can be used by software architects and C++ programmers to understand the design of the CSF and as a prelude to examining the source code for further detail.

3 Communication Services Framework Fundamentals Application Note Table of Contents Introduction... 2 Communication Services Framework Software Model... 2 State Pattern... 3 CSF Abstraction Layer Design... 4 Command Pattern... 5 Eventing Model... 6 Observer Pattern...8 Collaborating Objects in the CSF... 9 Application Management...10 Summary References Acronyms For More Information

4 Application Note Communication Services Framework Fundamentals Introduction Characteristics common to telephony applications are that they are event driven, asynchronous in nature, and require a high level of interaction between objects in different software layers, as well as between objects within a given software layer. Telephony applications are seldom limited to just control of telephony hardware and associated operations; they also include the integration of a wide variety of services such as protocol stacks, external speech services, database services, etc. Multithreading is usually required to avoid timeouts in signaling and media streaming protocols while also accommodating the integration of third-party components. These characteristics require that the runtime application state be carefully controlled, that events be handled within the current state and in the order the events are received, and that data synchronization be maintained. From a software design standpoint, care must also be taken to manage complexity when designing stateful handling of asynchronous events by maintaining a high degree of decoupling between objects. These application characteristics and software design challenges are not unique to telephony applications. They appear in a broad range of applications, and a multitude of solutions have been developed. Over time, experienced developers noticed that some solutions ended up being the best solution over and over again. Elements of these recurring solutions, expressed in patterns of classes and communicating objects, have been identified as design patterns. A set of 23 basic and wellknown design patterns are documented in the book Design Patterns: Elements of Reusable Object-Oriented Software [Gamma, Helm, Johnson, and Vlissidies]. The Communication Services Framework (CSF) is a C++ framework for creating Linux and Windows communication services applications that use Dialogic communications products. One of the fundamental purposes of the CSF is to explore and communicate best-known method (BKM) implementations. Design patterns from both mainstream software engineering and the specialized field of communication service engineering are applied to accomplish this. Another aspect of telephony application design is insulating the business layer from the platform. The business layer software must be independent from the telephony hardware and other services so that, except for configuration activities, the business application layer is not specific to the actual hardware and other technologies in use. The CSF is designed with an abstraction layer that provides interfaces to the business application layer that are independent of the underlying hardware and other technologies. This application note presents the fundamental design concepts used in the CSF. The presentation of this application note assumes that the reader is experienced with object-oriented concepts, C++, and Unified Modeling Language (UML) diagrams. Communication Services Framework Software Model The Communication Services Framework software model consists of three layers (see Figure 1): Application Layer Framework Services Media Abstraction Layer Call Control Abstraction Layer Service Components Drivers and O/S Figure 1. Communication Services Framework Software Model 2

5 Communication Services Framework Fundamentals Application Note The drivers and operating system layer consists of the operating system, hardware drivers (like the Dialogic System Release software), and other components (such as protocol stacks) The abstraction layer consists of technology-specific implementations of abstract interface The application layer consists of the objects that implement the business logic Framework Services span the abstraction and application layers and provide functionality used in both; for example, application startup/shutdown management and logging. their state to be able to handle both valid and invalid operations. All commands and events must be handled in a deterministic fashion where, for a given state, appropriate action is taken for commands and events valid for the state, and all other commands and events are handled as errors. Traditional methods for implementing state machines are nested switch statements, state tables, and the State pattern as described in the book, Design Patterns: Elements of Reusable Object-Oriented Software. Although nested switch statement implementations of state machines are simple in design, they tend to become unwieldy for anything other than the simplest cases: Application Layer Public Interfaces Network Voice Fax Conf... Technology-Specific Implementations Driver Layer Figure 2. Abstraction Layer The abstraction layer shown in Figure 2 provides a set of interfaces to the application layer that are independent of the underlying hardware and technologies. Implementations within the abstraction layer are specific to the hardware and technologies of the underlying platform, and support the abstract interfaces that are known to the application layer. The result of this software model is an architecture that allows a high degree of decoupling between the application business layer and the underlying platform hardware and technologies. State Pattern Stateful handling of commands and events is critical to a robust telephony application. In an asynchronous environment, objects in all software layers must maintain Performance degrades with increasing numbers of states and triggers Large nested switch statements are prone to programmer error because the logic is distributed across one of the nesting levels There tends to be a significant amount of repeated code, which is difficult to modify and extend due to the sheer number of lines of code required State tables provide a more convenient implementation than nested switch statements. They allow for code reuse and performance that is often better than with nested switch statements. The state tables grow rather large with real-world state machines, require complicated initialization, and are prone to programmer error during maintenance due to the unforgiving structure of the table declarations and the difficulty of data entry verification. 3

6 Application Note Communication Services Framework Fundamentals -state Context +Handle( ) State +Handle( ) state->handle( ) ConcreteStateA ConcreteStateB +Handle( ) +Handle( ) Figure 3. State Pattern Class Diagram The State pattern implementation of state machines consists of a class for every state to which the context object delegates all commands and events. Concrete state classes are subclasses of an abstract state class and implement the context class s state machine. The general form of the State pattern is shown in Figure 3. See Design Patterns: Elements of Reusable Object-Oriented Software for a complete description of the State pattern. The abstract state class implements the default behavior for all commands and events: handle them as an error condition with no change to the state. Error handling in the abstract state is application-specific and may be nothing more than logging the error. Each concrete state class encapsulates the behavior for all valid comments and events for the state so that the code is localized in each class. State classes can be hierarchical, which reduces the code duplication typical in nested switch statements and state tables. Performance is typically better than with state tables, since it is independent of the number of states. Memory utilization is efficient when the state classes are designed without class member variables. From the user point of view, the states and event handling methods are easy to read and subject to some automated verification by the compiler. CSF Abstraction Layer Design The general design of the CSF abstraction layer consists of a set of abstract classes that defines the public interfaces. Each abstract interface class has a set of private state classes that implements the state machine and a set of concrete subclasses that contain the technology-specific implementations for that interface. The abstract interface classes provide the application layer with a consistent interface and underlying state machine for all concrete classes of the same type. For instance, an analog network interface has the same commands, events, and state machine as does an ISDN network interface. The application layer logic is designed to the interfaces and state machines of the abstract classes and is therefore independent of the actual technology in use. The CSF abstraction layer uses the State pattern in a form slightly modified from that described in the book, Design Patterns: Elements of Reusable Object-Oriented Software. As in the State pattern, each abstract interface class acts as a context that enforces its state machine by delegating the public interface commands and events to the current state object. The CSF implementation is different in that the state classes delegate the actual behavior to the concrete subclasses of the abstract interface class. This is accomplished by designing the abstract classes to have a protected interface of pure virtual primitive functions that each concrete subclass must implement in the appropriate technology-specific manner to support the abstract class s state machine. The state classes call these primitive or prim functions to do everything except change state. Figure 4 shows how the State pattern is implemented in the CSF abstraction layer. Within the CSF, the term subject is used instead of the State pattern term context. When public interface functions are called on a concrete subject, the command is delegated to the current state object by the abstract class s implementation. If the command is implemented in the current concrete state class, a Primitive function of the concrete subject class is called. If the command isn t implemented in the concrete state class, the default behavior of the abstract state class is executed to log an error message. 4

7 Communication Services Framework Fundamentals Application Note AbstractSubject -state +CommandA( ) +CommandB( ) #PrimCommandA( ) #PrimCommandB( ) AbstractState +CommandA(in subject) +CommandB(in subject) state->commanda(subject) ConcreteStateA +CommandA(in subject) ConcreteStateB +CommandB(in subject) ConcreteSubject1 -PrimCommandA( ) -PrimCommandB( ) ConcreteSubject2 -PrimCommandA( ) -PrimCommandB( ) if (subject->primcommanda( ) = = SUCCESS) subject->setstatetoconcretestateb( ) Figure 4. State Pattern in the CSF There are several positive consequences of this design (see Table 1). The responsibilities of the different classes are well-defined and coupling between them is minimized. Also, there is no duplication of code inherent in the design. Command Pattern The Command pattern, as described in the Design Patterns: Elements of Reusable Object-Oriented Software book consists of: A client (called source in CSF), which is the source of commands A receiver ( target in CSF), which is the target of commands The invoker ( event processor in CSF), which is the mechanism by which commands are executed, possibly at a later time Figure 5 (on next page) shows the class diagram for the Command pattern. There are two consequences of the Command pattern that are central to the CSF design: Command targets are decoupled from command sources Commands are first-class objects that can be manipulated like any other object Command sources need only know how to create command objects and direct them to the target. Executing commands is solely the responsibility of the command object. This level of decoupling greatly simplifies software design and adds the flexibility needed to enable distributed systems. Commands are first-class objects that have behaviors and may have private attributes. Commands are manipulated just as State Pattern Class AbstractState AbstractSubject ConcreteState ConcreteSubject Responsibility Handles error conditions caused by commands and events that are invalid for the current state Defines the public interface Owns the state classes that make up the state machine Initiates actions and changes to a new state in response to commands and events valid for the current state Specific primitive behaviors Table1. State Pattern Class Responsibilities 5

8 Application Note Communication Services Framework Fundamentals Client Invoker AbstractCommand +Execute( ) Receiver +Action( ) ConcreteCommand +Execute( ) receiver->action( ); Figure 5. Command Pattern Class Diagram any object can be, including being stored in STL containers and passed as parameters in function calls. Eventing Model The CSF eventing model is an implementation of the Command pattern for handling commands and events, and also addresses threading and data synchronization. The Command pattern is easily extended to include events. Events can be modeled as a specialization of a command where the Execute() function of the event class performs an action appropriate for the event type or simply passes the event data to the target as a parameter to a HandleEvent() function for handling. Commands and events are considered to be symmetric. The benefit of this approach is that commands and events use the same processing mechanism. In the CSF, commands and events are considered equal and are encapsulated within objects of related classes. For the remainder of this application note, the terms are equivalent unless specifically noted otherwise. Figure 6 shows how the Command pattern is applied in the CSF. CommandOrEventSource EventProcessor AbstractCommand +Execute( ) Target +Action( ) +HandleEvent( ) ConcreteCommand +Execute( ) ConcreteEvent +Execute( ) target->action( ) target->handleevent( ) Figure 6. Command Pattern in the CSF 6

9 Communication Services Framework Fundamentals Application Note Source Event -target -eventtype -eventdata +Execute( ) EventProcessor -thread -queue -queuemutex -condition -conditionmutex +QueueCommand( ) Target -eventprocessor +PostEvent( ) +HandleEvent( ) target->handleevent(this) target->postevent(event) eventprocessor->queuecommand(event) Figure 7. CSF Eventing Model The CSF eventing model addresses event serialization and data synchronization by using object-centric worker threads encapsulated in EventProcessor objects. The CSF EventProcessor class is the Command pattern invoker object and includes a queue to hold event and command objects and a worker thread. Each target object is assigned an event processor by the application at instantiation. This lets the application determine how many application threads to use and which set of objects to group for a thread. Event and command objects are queued to the event processor and handled in the order received. The queue is thread-safe so that events and commands may be queued from any thread. The source obtains and initializes a command or event object and queues it to an event processor. As no processing of the command and event is done in the source s thread, an absolute minimum number of execution cycles is used. This can be critical in many situations where the source thread has soft real-time response requirements, such as a thread that communicates with a network driver. The event processor worker thread waits on a condition variable that is triggered when items are added to the queue. When an event or command item is added to the queue, the worker thread pops the command or event object from the queue and calls the object s Execute() function. This provides event serialization events and commands are processed in the order they are received. Because all command and event processing for an object is performed in the worker thread of its assigned event processor, data synchronization mechanisms at the data element level normally associated with multithreaded applications are not necessary. Data synchronization for the entire object is provided by the event processor queue. Figure 7 shows the class diagram for the event processor and associated classes. A CSF application can have any number of event processors. Each command target/event handler object is assigned an event processor as part of instantiation. The number of event processors, and which objects use each, are under application control. The best number of event processors and their use is dependent on application characteristics best determined by experiment. The event processor objects need to be globally controlled and accessible. The Singleton Pattern as described in Design Patterns: Elements of Reusable Object-Oriented Software can be used to manage a single instance of a class and provide global access. The Singleton Pattern class diagram is shown in Figure 8 (on next page). 7

10 Application Note Communication Services Framework Fundamentals -instance Singleton +Instance( ) if (instance = = 0) { instance = new Singleton( ) } return instance Figure 8. Singleton Pattern Class Diagram Whenever a pointer to the Singleton instance is needed, application code can call Singleton::Instance(). The pattern uses lazy initialization so the Singleton instance is created the first time the Instance() function is called. The static function always returns a pointer to a single instance of the class. This design is insufficient for use in the CSF. It doesn t address multithreading issues or support managing a set of instances. The Singleton design used for the event processor class in the CSF addresses both these issues. A double-checked locking mechanism is used in the Instance() function to ensure that only one instance is created in a multithreaded environment. This extension of the Singleton pattern is shown in Figure 9. Managing a set of instances is accomplished by replacing the instance pointer with a map of instance pointers keyed by a string ID, and by adding a string ID parameter to the Instance() static function that is used to enter the map. A default Instance() function with no ID string defaults to an event processor named SYSTEM. Observer Pattern In nearly all applications there are situations where objects need to collaborate, where one or more objects take some action based on the state change of another. Often this is an event multiplexing scenario where several dependent objects need to take different actions in response to a state change of a subject object. A software design can become extremely complex with a large number of highly coupled classes if some decoupling mechanism is not employed. The most common solution to this problem is the Observer pattern, also known as publish and subscribe. In the Observer pattern, any number of observer objects register with a subject to be notified of state changes. MtSingleton -instance -mutex +Instance( ) if (instance = = 0) { scoped_lock lock(mutex) if (instance = = 0) { instance = new MtSingleton( ) } } return instance Figure 9. Multithreaded Singleton Class Diagram 8

11 Communication Services Framework Fundamentals Application Note Subject +Attach(in observer) +Detach(in observer) +Notify( ) for all o in observers { 0->Update( ) } +Update Observer ConcreteSubject -subjectstate +GetState( ) +SetState( ) ConcreteObserver -observerstate +Update( ) return subjectstate observerstate = subject->getstate( ) Figure 10. Observer Pattern Class Diagram When the subject s state changes, all of the observer objects are notified without the subject having to know explicitly who the observers are. Figure 10 shows the class diagram for the Observer pattern. See Chapter 5 of Design Patterns: Elements of Reusable Object-Oriented Software for more information. In addition to providing a decoupled interface between objects, the Observer pattern also allows any number of observers to be notified of a subject s state changes. This is useful for monitoring designs to support status reporting and conformance features. This design makes it quite simple to make any object a subject or observer by simply inheriting from the abstract classes. Concrete subject classes need only call the Subject::Update() function at appropriate times and concrete observer classes need only implement the Update() function. It is common for concrete classes to be both a subject and an observer. Collaborating Objects in the CSF The general form of the Observer pattern is extended in the CSF to provide more granularity to observer notification of subject state changes and to use the CSF eventing model. Observer notifications include an observer notification identifier and observers register for specific notification IDs, as required. Instead of subjects issuing an Update() function call on observers, observer notifications are delivered to observers as events with optional event data. Another way of describing this is that observer notifications are application events. Those are handled just as all other events and commands within the CSF. The result of this design for object collaboration is that the CSF eventing model Command pattern implementation is reused in the Observer pattern implementation and a high degree of object decoupling can be realized. Figure 11 (on next page) is the class diagram for the CSF implementation of the Observer pattern. Observer subjects support a set of observer notification IDs that correspond to state changes that are of interest to other objects. Observers register with an observer subject for notification of specific observer notification IDs. When during an observer subject s logic processing one of the predefined state changes occurs, the observer subject s logic calls the AbstractObserverSubject class NotifyObservers() function. The AbstractObserverSubject class implementation of this function creates an event and posts it to each observer registered for that notification. The observer subject is now acting as an event source. The event is ultimately handled by the concrete observer acting as an event handler. 9

12 Application Note Communication Services Framework Fundamentals Event AbstractEventSource -target -eventtype -eventdata +Execute( ) EventProcessor AbstractObserverSubject +QueueCommand( ) -registrations +RegisterForNotification(in observer, in id) +Unregister(in observer, in id) +NotifyObservers(in id, in eventdata) AbstractEventHandler -eventprocessor +PostEvent(in event) +HandleEvent(in event) for all reg in registrations where reg.id = = id { event = new Event(reg.observer, id, eventdata) reg.observer->postevent(event) } ConcreteSubject Concrete Observer +HandleEvent(in event) NotifyObservers(SOME_ID, someeventdata) Figure 11. Observer Pattern in the CSF Application Management One common design challenge in applications is that of startup and shutdown processing. This is particularly important in telephony applications that use hardware, operating systems, and network-based services and devices. The typical application startup scenario is that the event processing and logging are started, device- and service-related objects are started, and then the application layer objects are started. Application shutdown occurs in reverse. Event processing and logging are made available first so that the facilities are available to support instantiation and startup of the device resource- and service-related objects. These objects must be completely initialized and in an idle state before the application layer processes are started. The CSF provides support for this scenario through the use of a set of objects managed by an application object. On application startup, the application object is responsible for starting the event processing and logging, and then bringing the set of managed objects to an idle state before starting the application layer. On application shutdown, the application object is responsible for the reverse process. Figure 12 is the state chart for the managed object state machine. Figure 13 is the state chart for the application object state machine. The application object and managed objects communicate using the Command and Observer patterns, and the state machines are enforced using the State pattern. The required interfaces and state machine are implemented in abstract class that can then be subclassed to define concrete classes within an application. 10

13 Communication Services Framework Fundamentals Application Note Uninitialized State Initialize( ) Opening State Open( ) Available State OnManagedObjectOpened( ) Idle State Close( ) Closing State OnManagedObjectClosed( ) Figure 12. Managed Object Class State Chart Uninitialized State Initialize( ) Starting State StartApplication( ) Stopped State OnEventProcessorStarted( ) Opening State OnManagedObjectsOpened( ) Running State StopApplication( ) OnManagedObjectsClosed( ) Closing State Stopping State OnEventProcessorStopped( ) Figure 13. Application Class State Chart 11

14 Application Note Communication Services Framework Fundamentals AbstractCommandTarget -eventprocessor -logger +QueueCommand( ) AbstractObserverSubject AbstractEventHandler +PostEvent( ) +HandleEvent( ) -registrations +RegisterForNotification(in observer, in id) +Unregister(in observer, in id) +NotifyObservers(in id, in eventdata) AbstractManagedObject +HandleEvent( ) +Initialize( ) +Open( ) +Close( ) -PrimInitialized( ) -PrimOpen( ) -PrimOnManagedObjectOpened( ) -PrimClose( ) -PrimOnManagedObjectClosed( ) AbstractManagedObjectState ConcreteManagedObjectState ConcreteManagedObjectState ConcreteManagedObjectState Figure 14. Abstract Managed Object Class Diagram Figure 14 is the class diagram for the abstract managed object class. Concrete managed object classes implement the Prim pure virtual functions of the abstract managed object class. Normally, they also extend the state machine of the abstract managed object class by adding additional state classes, public interfaces, and private Prim functions. The responsibilities of a concrete managed object inherited from the abstract managed object class are to perform actions within the PrimInitialize(), PrimOpen(), and PrimClose() functions that are appropriate to the class, and to notify observers when the object has completed open and close processing in the private PrimOnManagedObjectOpened() and PrimOnManagedObjectClosed() functions. Figure 15 (on next page) is a class diagram of the abstract application class. Concrete application classes implement the CreateManagedObject(), ApplicationStarting(), and ApplicationStopping()pure virtual functions of the abstract application class. When the StartApplication() function is called on the application object, logic within the abstract application class starts the event processor and logger. After the event processor and logger have started, the CreateManagedObjects() function of the concrete application object is called. In the CreateManagedObjects() function, the concrete application class instantiates the application s managed 12

15 Communication Services Framework Fundamentals Application Note AbstractCommandTarget -eventprocessor -logger +QueueCommand( ) AbstractObserverSubject AbstractEventHandler -registrations +PostEvent( ) +HandleEvent( ) +RegisterForNotification(in observer, in id) +Unregister(in observer, in id) +NotifyObservers(in id, in eventdata) AbstractManagedObject +HandleEvent( ) +Initialize( ) +Open( ) +Close( ) AbstractApplication -_state -_managedobjects +Initialize( ) +StartApplication( ) +StopApplication( ) #AddManagedObject( ) -CreateManagedObjects( ) -ApplicationStarting( ) -ApplicationStopping( ) AbstractApplicationState ConcreteApplicationState ConcreteManagedObjectState ConcreteManagedObjectState Figure 15. Abstract Application Class Diagram objects and adds them to the application using the protected AddManagedObject() function. When the CreateManagedObjects() function returns, the logic in the abstract application class initiates an Open() function call to the managed objects. Logic within the abstract application object then waits for observer notifications from all of the managed objects. When observer notifications have been received from all of the managed objects, abstract application class logic calls the concrete application object s ApplicationStarting() function. Within this function is where the application layer logic is kicked off. Application layer objects are usually designed as described in the state, command, and observer sections above and have a Start() function to initiate processing. In some cases, there are dependences between application layer objects that need initialization prior to the start of application layer processing. In these cases, the application layer objects are designed and handled as managed objects. The application shutdown process is similar to startup but in the reverse order. When the StopApplication() function is called on the application object, abstract application class logic calls the concrete class s ApplicationStopping() function. Within this function, the concrete application class stops and cleans up the application layer objects. When this function returns, the abstract application class s logic issues a Close() function call to the managed objects. As with application startup, if application layer classes need any management for shutdown, they should be designed as managed objects. 13

16 Application Note Communication Services Framework Fundamentals When observer notifications have been received from all of the managed objects, abstract application class logic stops the logger and event processor. The abstract application class logic issues an observer notification just after the ApplicationStarting() function completes and another one just before the ApplicationStopping() function is called. As an alternate design, the application layer objects could register with the application object and use the observer notifications to control starting and stopping of processes. Summary The fundamental Communication Services Framework design for commands, eventing, and object collaboration is based on well-known State, Command, and Observer design patterns. This design provides an asynchronous environment well-suited for building telephony applications that scale easily through the use of efficient multithreaded asynchronous processing. This design also avoids much of the usual multithread complexity by limiting the coupling between objects and software layers, and provides a flexible integration environment by providing for multiple command event sources and targets. References [Gamma, Helm, Johnson, and Vlissidies] Gamma, Helm, Johnson, and Vlissidies, Design Patterns: Elements of Reusable Object-Oriented Software; Addison-Wesley; Boston, MA; 1997 Acronyms BKM CSF First-class Object STL UML For More Information Best-known method Communication Services Framework An object that can be created dynamically, stored in a variable, passed as a parameter to a function, and returned as a result by a function Standard Template Library Unified Modeling Language Source code located at Introduction to the Communication Services Framework (CSF) available at Intro_Comm_Svcs_Frmwk.pdf Media Server Solution Recipe: Conferencing Applications available at Media_Svr_Conf_App.pdf 14

17 Communication Services Framework Fundamentals Application Note 15

18 To learn more, visit our site on the World Wide Web at Dialogic Corporation 9800 Cavendish Blvd., 5th floor Montreal, Quebec CANADA H4M 2V9 INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH PRODUCTS OF DIALOGIC CORPORATION OR ITS SUBSIDIARIES ( DIALOGIC ). NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY. Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Dialogic may make changes to specifications, product descriptions, and plans at any time, without notice. Dialogic is a registered trademark of Dialogic Corporation. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted by Dialogic s legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic s trademarks requires proper acknowledgement. Windows is a registered trademark of Microsoft Corporation in the United States and/or other countries. Other names of actual companies and products mentioned herein are the trademarks of their respective owners. Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement their concepts or applications, which licenses may vary from country to country. Copyright 2007 Dialogic Corporation All rights reserved. 06/