I'm trying to build application which records multiple calls at the same time. I did register multiple recording extensions and everything seems to be working fine except when I storing RTP media stream with more than one active call - sound becomes choppy and not readable. If I store single call - sound is good (used simple Record app code to receive RTP stream)

For each recording extension I allocate separate RPT/RTCP ports and receiving media stream thread. Can you please advice how to solve this?

sorry for wrong subj. It was suppose to be "choppy sound when recording multiple streams"

It sounds like a flaw in your RTP stack. It may be that it does not handle jitter correcetly.

Martin

from code perspective it looks rather simple. The sound looks like it's becomes recorded at higher speed (talking too fast) and only in case when multiple threads are received at the same time.

Code:
mutex2.WaitOne();
receiveBytes = rtpReceiver.Receive(ref acmIpEndPoint);
mutex2.ReleaseMutex();

for (int i = 0; i < receiveBytes.Length; i++)
{
if (i >= 12)
{
recordedFileSize++;
mutex.WaitOne();
bw.Write(receiveBytes[i]);
mutex.ReleaseMutex();
}
}

bw.Close();

Is approach I use correct?
- each recording ext has to have two dedicated ports RPT/RTCP
- there should be pool of recording extensions to work with
- each recording ext has to have it's own threads for RTP/RTCP

What I'm missing in my implementation?

Hi Yuriy,

I believe it is possible to use Wireshark to capture the RTP data streams and to play them. This will give you an independent test of the quality of the audio being sent from the Communication Manager.

Martin

from your description you may be dropping packets somewhere. Also algorithmically you are not handling silence packets (if it is configured and used with the codec you are using).

Martin is right you can capture RTP with Wireshark and play it back to verify what is leaving Communication Manager is complete.

I've tried to capture packets with WaterSharks and it played back nicely without dropped packets. I'm questioning really application at this point and trying to figure out how packets could be dropped.

Based on the code below - there is separate threads for capturing and I don't know how to prevent packets from being dropped on application level. Can you explain how multiple RTP and RTCP threads should be synchronized in order to receive packets correctly without dropping?

Perhaps the root issue is lower in your stack than your application code.

There are too many releases, network stacks, programing languages, operating systems, etc for our engineers to be fluent in all of them. We can help you with troubleshooting techniques and information about the APIs but we are not versed enough in all the variables in the application side of the coin to help unravel where this problem has its origins.

There are sequence numbers associated with the RTP packets so they can be ordered properly. If you can access them in your code, you could check to make sure you are getting all the packets.. that would be a nice divide and conquer point.

There should only be one thread with an instance of bw, so I don't understand the need for the mutex around that logic, but I also don't perceive the issue is with the code snippet you have shown us.

I will lower my stack and let you know. Another question to the same subj: could this be releated to G711U standard I use for encoding?

mediaInfo.CodecList.Add("G711U")?

Should the receiving media be decoded, before played back?

reffering to article:
http://www.codeproject.com/Articles/14237/Using-the-G711-standard

no this is not a codec issue.... most likely it is a loosing packets issue

You indicate that if you record a single stream, there are no problems with playback. Yet if you record multiple streams there are problems.... so how could it be a decoding problem?

Looks like issue has been solved. It was really Receive() call implementation issue in .NET. It's not designed for this. I've switched to use BeginReceive/EndReceive and issue with loosing packets when receive is gone.

Yea! thanks for the update that it is resolved. I am sure others will appreciate knowing what you learned here.