What is IP-PSTN?

    IP-PSTN is a gateway between a telephone and any SIP User Agent Client. It allows a person to call any (allowed) telephone number from any SIP-compliant client application.

Fig1. IP-PSTN Gateway

Used hardware.

    IP-PSTN uses Dialogic D/41ESC telephony card, which provides:

• 4 external ports (to phone lines),
• 4 analog/digital channels, each with specialised DSP,
• SC-BUS for connecting other cards/devices,
• possibility to connect 2 channels to one port, making it full-duplex,
• A-law and mu-law sound codecs,
• echo cancellation,
• silence suppression,
• low latency.

All these features make it possible to create IP-PSTN gateway.

Used software.

IP-PSTN works on Windows NT 4.0 installed on PC, because Dialogic SDK works only with this system. This choice had also influence on the choice of other packages/libraries used. Below is the list of used libraries and packages:

• Dialogic DNA 3.1
• Dialogic Gatenet 3.0 package
• sipd from Columbia University
• RTPlib from elemedia (Lucent)
• GSM codec from TU Berlin

Short description of each item.

Dialogic DNA 3.1

Dialogic SDK, called DNA is a powerful set of functions allowing a programmer to create very complicated CT applications, like call centers, voicemail boxes and also IP telephony gateways. Most functions may be called either synchronously or asynchronously thus allowing the creation of multithreaded applications. Basic functions include:

• dx_open(), dx_close() - open/close board/channels,
• dx_sethook() - set the line on/off-hook,
• dx_play(), dx_record() - "play" with voice samples, i.e. greetings, messages etc.,
• dx_dial() - dial the number,
• dx_getdig() - get the DTMF tones entered by the party.

Gatenet 3.0 Package

This package is a special set of functions developed to allow the creation of IP Telephony Gateways. It's a firmware for the card and a software library with special functions.

The firmware provides:

• automatic routing of channels 1-3 and 2-4 for full duplex capability,
• possibility of manually setting the buffer size to as little as 120 bytes (512 by default), thus lowering latency,
• Play/Record Direct Streaming technique (PRDS) ,
• hardware echo cancellation,
• silence suppression.

The most important features are lowering the latency and providing echo cancellation.

sipd from Columbia

This is a sip proxy daemon written in "structured C". Its sources derive from rtsp daemon, HTTP & RFC822 parser. That's why the code is very stable and reliable. It's also very easily understandable and transparent because of lots of accurate and precise comments. It's also been used because Dialogic libraries were written in C and it was the only working SIP code for the Win32 platform.

RTPlib from elemedia (Lucent)

RTPlib from Lucent has been chosen because it's a very easy to use and complete RTP library. It’s available for Win32, Linux & Solaris and is written in C. The API is very easy and is very thoroughly described in the documentation (html file). There are also examples that make use of this library really easy and quick.

GSM codec from TU Berlin

This codec is a library (with source) with functions allowing compression & decompression from linear PCM to 13.2 kbps GSM. It's also written in C and available on most system platforms.

    Fig. 2. Hardware and software structure of the gateway.

Implementation details.

IP-PSTN is written as a multithreaded Win32 console application and consists of several threads. These threads include:

• Main thread and ProcessEvent()
 
Used for initialisation, event collection and handling, moving between application states.
• InThread
 
This thread receives both RTP and RTCP packets. If this is a RTCP packet, it's checked against being a BYE packet. If it is a BYE packet, the call is terminated.
If this is a RTP packet, included sound sample is decoded (if needed) to mu-law PCM format and sent to the Dialogic board. Currently mu-law PCM (0) and GSM(3) payloads are supported. Other codecs, such as DVI, A-law PCM and others will be implemented in the near future.
• OutThread
 
This thread waits for the notification (event) from the Dialogic board that the sound sample is ready, takes the sample, encodes it (if needed) and sends it inside the RTP packet.
• RTPScheduleThread
 
This thread is required by the elemedia RTP library. It is used to schedule & execute RTP events. These events are stored in the queue each having its own execution time. When this time comes, internal library function RTPExecute() is called with context kept in the queue element.
Scheduling is used for sending RTCP packets holding reports at a certain time.
• UDPListenThread
 
This thread listens to packets coming from the net on a certain UDP port, which is usually 5060 (default SIP listen port). The body is almost directly taken from the sipd code, since the idea of operation is the same: receive the packet, create a SIP message out of it and pass it to new, dynamically created either RequestProcessThread or ResponseProcessThread
• RequestProcessThread
This thread is created dynamically in UDPListenThread whenever new packet with request is received. Its function is to parse the request and perform certain operations according to the contents.

Sound processing path.

Since the gateway operation is about translating voice most of the time this process shall be described here in detail. Figure 3 shows subsequent blocks of sound processing path. This path contains two working in parallel stream processing flows: from IP to PSTN and in opposite direction.

Fig.3. Sound processing path.

Flow from IP to PSTN

All operations described here are handled by In thread. They include:

 
• waiting for the packet to arrive (by select()),
• calling RTPReceive() library function for receiving RTP packet on UDP port,
• calling gsmdecode(), which coverts received voice sample from GSM to mu-law PCM,
• copying received sample to firmware buffer and notifying Gatenet library that sample is ready by setting play event.

After this, sample is taken from the firmware buffer, converted to analog voice and played on the telephone line. These operations take place in the hardware (right big block in the figure).

Flow from PSTN to IP.

These operations are handled by Out thread. They include:

 
• waiting for the record event (set by Gatenet when sample is ready),
• encoding sample from mu-law PCM to GSM,
• sending RTP packet,
• setting current firmware buffer as invalid.

Decoding from/to GSM is optional here and may be negotiated, since mu-law PCM is usually a basic codec for RTP transmission (its payload number is 0).

References

pulver.com & Jeff Pulver : source of all IP Telephony-related information.

www.cs.columbia.edu/~hgs/sip : source of all sip-related information, home of sipd & sipc. List of sip-related documents, papers, conferences, implementations and much more.

RCF 2543 : SIP.

"Understanding Latency in IP Telephony", Alan Percsy, Senior Sales Engineer, Brooktrout

 

For any questions, comments and sugesstions contact:

Marcin Michalak, mmich@iris.ics.agh.edu.pl