Re: [Ccrtp-devel] problems receiving RTP on Windows 2000 Server?

[Brian Davis]

I will have to check the bandwith/number of packets per second.  The sender of the packets is a Nuance MRCP server, sending TTS data.

The loss pattern seems to be that it goes okay for a second or two, but then begins to lose (approximately) 2 out of every 3 packets for the rest of the session.

I went as far as placing my own print statements within the ccrtp package and recompiling, to see where the packets are lost (with the same intention as the approach you mention in overloading onRTPPacketRecv).  In takeInDataPacket, I printed the received packet and it's sequence number each time a packet was received.  From that output, I could see that the packets were lost before they were even received by ccRTP (even though I could tell from Ethereal that they made it to the machine).

I found this old thread that seems like it could be related: http://lists.gnu.org/archive/html/ccrtp-devel/2002-03/msg00006.html

Does anyone know about
 that?  Perhaps this is a windows2K-specific problem related to select()?  I haven't found any discussion on this topic on the ccgnu forums or anywhere else on the web.

Thank you,
Brian

Federico Montesino Pouzols <address@hidden> wrote:
>  
> Hi,
>
> On Thu, June 22, 2006 5:35 pm, Brian Davis wrote:
> > Has anyone else experienced problems receiving RTP on a Windows 2000
> > server?
> >
> > I am using ccrtp-1.4.1 and commoncpp2-1.4.1.  My test client is a simple
> > MRCP client, using ccrtp to receive text-to-speech audio data.  The
> > received audio is distorted because much of the audio data is never
> > received.  Using Ethereal, I can see that the UDP packets arrive at the
> > server, but only approximately 1 out of every 3 packets is read/received
> > by
>  ccRTP.
> >
> > Is this a known problem, and if so, is there a solution or a work-around?
> >
>
> What's the bandwidth an number of packets per second?
>
> Do you see any clear loss pattern (are there loss bursts, etc.)?
>
> One possibility to look into the issue would be overloading
> onRTPPacketRecv with which you can see packets as they arrive before
> being inserted into the incoming queue. The only processing done
> before onRTPPacketRecv is the basic header validity check.
>
> > Regards,
> > Brian

---

How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.