Subject: RTP and CTI

From: [email-masked] (SVR Anand)
Date: Mon, 5 Jun 2000 18:16:42 +0530 (GMT+05:30)

Hi,

I am at the cross roads to decide on where to locate the RTP implementation
in the context of VoIP. I hope I am sending my mail to the appropriate 
mailing list. Hoping that I can discuss the design issues here... 

I am using a Pentium desktop running Unix OS. I am supposed to build a CTI 
card with a DSP on it running voice processing software. There are two 
options for me to choose when it comes to the implementation of RTP.

1) To implement RTP, jitter algorithm on the CTI card itself
2) To implement RTP, jitter algorithm on the host, and pass on the
   voice samples to the CTI card for further processing

Given the two options, what is the most suitable location for RTP ? 

I would be thankful if you can give me a clear perspective on this.

Regards
Anand

---

From: Colin Perkins <[email-masked]>
Date: Mon, 05 Jun 2000 15:48:19 +0100

>Given the two options, what is the most suitable location for RTP ? 

The implementations I'm aware of use the second approach. I'd be interested
in hearing of other solutions.

Colin

---

From: [email-masked] (SVR Anand)
Date: Mon, 5 Jun 2000 21:27:18 +0530 (GMT+05:30)

Colin,

Can you let me know why the second approach might have been preferred, and
may I know the implementations you are refering to ? 

I am asking this because there is one argument in favour of approach 1. 
Please correct me if it is valid at all. The argument is,

If the machine has two or more high speed network interfaces serving
good amount of network traffic, to avoid the per-packet overheads 
associated with RTP, and the related processing every 20msec of audio, it is
better to make the DSP handle this functionality. How far is this correct ?

I should admit that though approach 2) gives a "nice" feeling, I am very much
interested in knowing whether approach 1) can potentially result in a bad 
design.

Thanks

Regards
Anand

---

From: Jon Steer <[email-masked]>
Date: Mon, 05 Jun 2000 12:34:50 -0400

>in hearing of other solutions.

Actually, a number of chips, (AudioCodes comes to mind) implement
#1.

regards,
jon

Jon Steer -- CTO
http://www.tsemantics.com/
T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064
phone:(603)889-1185 x203  video: (603)889-1125  fax: (603)-883-9365

---

From: Colin Perkins <[email-masked]>
Date: Thu, 08 Jun 2000 15:24:13 +0100

>may I know the implementations you are refering to ? 

I would choose to implement RTP packetisation/de-packetization, RTCP and
the de-jitter operation in software, since these are not processor bound
operations but are somewhat subtle in their operation (especially writing
a good de-jitter algorithm). Those aspects I would choose to implement in
the card are audio coding and loss concealment, since these would benefit
from the presence of a DSP.

>better to make the DSP handle this functionality. How far is this correct ?

Certainly if you have a high speed network with QoS this is a valid
approach. If you want something which runs over a non-guaranteed QoS
network, then I would suspect that it is easier to implement the dejitter
operation in software.

>interested in knowing whether approach 1) can potentially result in a bad 

It depends on your application to a large degree. The implementations I
know are PC-based, handling a small number of streams. If your system has
to process a very large number of streams, the trade-off is somewhat
different. 

Colin

---

From: [email-masked] (SVR Anand)
Date: Thu, 8 Jun 2000 23:28:42 +0530 (GMT+05:30)

Colin,

Thanks a lot for your response. The machine I am using is a Pentium III PC. 
I also feel that it is better to implement RTP packetization/de-packetization,
RTCP, as well as de-jitter algorithm on the host. Some more thoughts.

It is difficult to imagine that the delay due to RTP packet processing + 
jitter algorithm can really result in a additional packet worth of delay 
(20millisec) in the playout times. 

If we note that the new playout delay calculation is going to occur only at 
the beginning of a new talk spurt, host need not unduly worry since the 
only per-packet overhead is going to be measurement of jitter which is not 
computationally intensive at all.

Arriving at the correct de-jitter algorithm, as you have very rightly pointed
out, can be very tricky, and lot of fine tuning may be required. At times
there is a bit of subjectivity involved. Burying it in the DSP is a bit 
scary !

Regards
Anand

---

From: Colin Perkins <[email-masked]>
Date: Fri, 09 Jun 2000 12:04:05 +0100

>(20millisec) in the playout times. 

Depends on the network - if you're running over the public Internet, the
jitter can indeed be that bad. If you control the network, you probably
don't need to worry about it.

>computationally intensive at all.

Right...

Colin