Skip Navigation LinksHome > Products > VoIP and IMS > DC-SIP > Product Architecture

DC-SIP Architecture

The diagram below shows the basic architecture of the DC-SIP toolkit. Functional blocks showing support code etc have been omitted for clarity.

DC-SIP Stack Architecture - DC-SIP toolkit software includes portable core protocol components, and sample code for support functions that can be tailored for a particular solution

For an overview of the DC-SIP toolkit and its features, see DC-SIP Product Overview.




Components

In the above architecture, the components shown in yellow form the core portable DC-SIP components.

  • The Transaction Manager implements the core of the SIP protocol through a set of Finite State Machines (FSMs).

  • The Connection Handler handles the multiplexing of outbound messages and the parsing and de-multiplexing of inbound messages. This processor-intensive functionality can be offloaded to a separate communications processor to improve scalability.

  • The Helper Function Library provides a function call-based interface for building, parsing, and modifying SIP messages. It supports compact headers, and allows individual headers to be configured as required or with default values to simplify the User Application.

  • The SDP Parser provides functions for handling Session Description Protocol (SDP) message bodies. It can check a message for validity and can parse it to simplify access to the message fields. However, note that the DC-SIP software supports the use of any message body type, including SDP and SIP-T encapsulation.

  • The Call Control Library provides a high-level application interface to the DC-SIP toolkit, which simplifies the development of the user application. It provides functions to control SIP calls and callback hooks for handling SIP events.


Interfaces

The key interfaces to the DC-SIP toolkit can be divided into application and support interfaces.

The application interfaces are designed to provide applications with a number of flexible controls over the use of the DC-SIP toolkit.

  • The Call Control Interface provides a simple, high-level C or C++ function-based interface enabling an application to establish and control SIP calls. It is designed to require very little SIP knowledge from the application, so an application can be SIP-enabled very quickly.

  • Alternatively, the Application Interface provides an application with a lower-level message-based interface. This allows applications to send and receive SIP transactions directly (rather than using the abstraction provided by the Call Control Interface), providing more control over the precise details of the SIP messages sent.

  • The Message Build and Parse Interface provides C or C++ utility functions that build and parse standard SIP messages. An application using the Call Control Interface may also use this interface to modify or extend the messages created; an application using the Application Interface may use it to build and parse messages from scratch.

  • The MIB Interface provides a generic mechanism to enable DC-SIP to be configured. This can be easily mapped onto a SNMP sub-agent (if required), or integrated with the application and existing configuration mechanisms such as CLI, GUI or Web.

The support interfaces provide access to the facilities required to implement the SIP protocol. Sample versions of these facilities are supplied with the DC-SIP toolkit.

  • The Name Resolution and IP Sockets interfaces provide generic asynchronous interfaces that can be easily mapped to the IP functionality available on a particular platform. The sample implementation demonstrates integration with operating system DNS, TCP and UDP services.

  • The Subscriber Interface provides a generic interface to subscriber location and security information, including policy on whether to accept, reject or proxy any particular request. This interface can be implemented as synchronous (accessing a local database) or asynchronous (with information held on a remote directory service, possibly over LDAP). The sample implementation provides a simple local database.

  • The Cryptographic Interface provides an extensible authentication interface. The interface can be implemented as synchronous or asynchronous to allow the keys to be stored in a separate, secure environment. The sample implementation provides digest authentication using MD5.

  • The Inbound Transaction Router is only required in distributed environments with multiple Transaction Managers, where it routes inbound requests to the correct Transaction Manager. It is fully user-configurable to provide flexible load balancing and routing for specific scenarios.