11.1. General Considerations for Developing or Porting R4 on DM3 Applications
The following information describes how to develop applications on R4 for DM3, with a focus on modifying existing R4 API applications so that they can accommodate DM3 boards.
With R4 for DM3, applications supporting Span Cards can be expanded to provide support for DM3 hardware as well. DM3 is a powerful DSP architecture introduced by Dialogic to provide customers with greater channel density and performance for building CTI solutions on PCI and cPCI bus architectures.
R4 for DM3 uses a subset of functions supported in R4, hence the application developer must make some trade-offs and decisions when migrating to R4 for DM3.
DM3 voice devices may only be attached to DM3 network devices.
11.1.1. Using GlobalCall for Call ControlOne of the challenges of migrating a Dialogic digital interface application from R4 to R4 for DM3 lies in the lack of R4 for DM3 support for much of the DTI API functionality that many legacy applications use today. In particular, this is true for T-1 robbed-bit applications written prior to Dialogic introducing GlobalCall support for T-1 robbed-bit digital trunks.
The use of GlobalCall simplifies the life of the CTI application developer, since the GlobalCall level of abstraction allows for seamless support for any telephony interface, including T-1, E-1, ISDN or even analog. Once an application has been designed to use GlobalCall, minimum changes (if any) are required for the same application to run on various Dialogic hardware, including D/4x, Span Cards, DualSpan and DM3 boards as well.
It is a good architectural decision to use GlobalCall because of the greater flexibility and portability provided by GlobalCall. This is true, not just for R4 for DM3, but for any CTI application that uses Dialogic hardware.
11.1.2. DTI API versus GlobalCallThe standard R4 DTI API presents several functions--for example, SCbus routing, network interface alarms, and timeslot signaling control.
The standard GlobalCall API presents a higher level of call control abstraction than the DTI API.
There are numerous digital interface telephony protocols in use worldwide. To name some, there are robbed-bit T-1, CAS E-1, ISDN, SS7, IP, and ATM. They all have one thing in common: they all try to solve the problem of connecting two or more people/machines anywhere in the world in direct conversation. Once the connection has been established, various data and voice streaming mechanisms can be used, such as digitized human voice, IP packets, or any other digital data.
Those protocols mentioned above all use a similar high level "layer 3" protocol. The end result is that one end can initiate a call (make call), be informed of an incoming call, or drop the call. The GlobalCall API presents the developer with a similar level of abstraction at the API level, hiding the internals of the specific protocol.
That is, in order to make a call under a T-1 robbed-bit trunk, the protocol indicates that one must flip the A & B signaling bits, while to do the same under an ISDN PRI protocol, one must send a specific HDLC packet over the ISDN data channel. All of these complicated operations are hidden from the GlobalCall developer.
It is technically possible to design a GlobalCall application in such a way that the same application can run with an E-1 CAS trunk or an E-1 ISDN trunk without requiring changes.
GlobalCall is the API of choice for R4 for DM3 for a number of reasons. These are some of the most obvious:
11.1.3. ISDN Primary Rate API versus GlobalCallMany existing R4 applications today make use of the rich Dialogic ISDN Primary Rate API. This API has been evolving over time, and provides access to two levels of abstraction, known as layer 3 and layer 2.
R4 for DM3 does not provide access to the ISDN Primary Rate API; however, much of its layer 3 functionality can be accomplished today directly and at a similar level of abstraction using GlobalCall.
To port an existing R4 application to R4 for DM3, you must replace the ISDN Primary Rate functions with equivalent GlobalCall functions. Most of the ISDN Primary Rate functions have the "cc_" function name prefix and are documented in the ISDN Software Reference. If you compare the GlobalCall API Software Reference with the ISDN Software Reference, you will see the great similarity between the two APIs, and that it should require a minimal effort to port an application that uses the Primary Rate API to an application that uses the GlobalCall API.
11.1.4. Programming Models in LinuxFor Linux, all existing SRL programming models are preserved under R4 for DM3, except for the Signal Callback Model, which is not supported.
Asynchronous event notification is done via the SRL in the same exact way it is currently done with standard R4 devices.
Click here to contact Dialogic Customer Engineering
Copyright 2002, Intel Corporation