Delay in VoIP call for WinCE5.0 device

Hi All,

We are developing a MainstoneII based VoIP handheld device, on WinCE
5.0 with PXA 270 processor. On making VoIP call we are getting delay
of 3 seconds. What can be possible reasons for this, whether any
driver like ethernet cotroller can cause a delay. We are using SMSC
9118 ethernet controller.Plz help me in this.
Thanks in advance

Jipin

Silver
Mon May 19 09:16:40 PDT 2008

Whta do you mean by 'delay'?
Is that the time taken to setup the call? If so then that sound very good to
me.

If you mean the latency between the 2 endpoint then that is very poor for
RTP audio traffic then you definitely have a problem somewhere.

Can you describe your setup on more detail, as well as our build environment
(you are using a retail build right?)

e.g. Are you going point to point or thru a SIP server etc...

Geoff
--

jipinjose
Tue May 20 06:28:06 PDT 2008

On May 19, 9:16=A0pm, "Silver" <moc.liamtoh@gnirrevliseht> wrote:
> Whta do you mean by 'delay'?
> Is that the time taken to setup the call? If so then that sound very good =
to
> me.
>
> If you mean the latency between the 2 endpoint then that is very poor for
> RTP audio traffic then you definitely have a problem somewhere.
>
> Can you describe your setup on more detail, as well as our build environme=
nt
> (you are using a retail build right?)
>
> e.g. Are you going point to point or thru a SIP server etc...
>
> Geoff
> --

Hi Geoff,

Thanks for the reply .I will describe my query in detail.

1)By delay what excatly i meant is the latency between the 2
endpoint,but the voice is still clear.

2)We are not using any SIP server.

3)We are using a Release build, i think it is same as retail build you
mean.

The system configuration is 128MB flash and 128MB RAM.Is the network
driver for SMSC9118 have any effect on the delay?.The device have both
H323 and SIP protocls.In H323 if the device is kept idle for sometime
and a call is made to the other device then the delay increases
further to approximately 5 seconds.What can be reason? is it the
problem with the device drivers or with the protocol stacks.

Jipin

Silver
Tue May 20 09:18:35 PDT 2008

I seriously doubt that your Ethernet driver is causing the delay but that is
easy to test using 'ping'. Simply ping one device from the other and look at
the ping time.

I have run this on very similar configurations to you and experienced
sub-second latency, around 500mS maximum. I was using PCM u-Law codecs.
The signalling protocol does not matter as RTP handles the voice
transmission whereas SIP/H323 setup the call and terminate it but do not
carry voice data.

Are you perhaps using VMINI - that is using KITL on the same Ethernet part
as NDIS?

Geoff
--

jipinjose
Wed May 21 05:55:11 PDT 2008

On May 20, 9:18=A0pm, "Silver" <moc.liamtoh@gnirrevliseht> wrote:
> I seriously doubt that your Ethernet driver is causing the delay but that =
is
> easy to test using 'ping'. Simply ping one device from the other and look =
at
> the ping time.
>
> I have run this on very similar configurations to you and experienced
> sub-second latency, around 500mS maximum. I was using PCM u-Law codecs.
> The signalling protocol does not matter as RTP handles the voice
> transmission whereas SIP/H323 setup the call and terminate it but do not
> carry voice data.
>
> Are you perhaps using VMINI - that is using KITL on the same Ethernet part=

> as NDIS?
>
> Geoff
> --

Thank you Geoff,

We have tested using ping as you said, between a PC and a device. We
have observed the ping time as 1 millisecond only.So can i confirm
that the ethernet driver is not making any delay. We are not using
VMINI.We have disabled the KITL and using SMSC 9118 ethernet miniport
driver.Is there any other way to test the ethernet performance?.

Jipin

Silver
Wed May 21 09:35:34 PDT 2008

Did you use ping with large packets? Try pinging with a few kilobytes .
(ping -l 3000 <target>)

You can test Ethernet performance using a client-server, see the examples in
the MSDN then add some extra traffic and statistics to it.
http://msdn.microsoft.com/en-us/library/aa916375.aspx


Or (more easily?) - add the CETK to you design then run the Ethernet tests.
The CETK is documented in the PB help and MSDN
One-Card Network Card Miniport Driver Test.:
http://msdn.microsoft.com/en-us/library/ms894413.aspx

Are both endpoints CE devices? Try talking to a PC based SIP phone, try
soemthing likethis:
http://www.phonerlite.de/index_en.htm

You can then run wireshark on your PC and investigate what is happening on
the Ethernet:
http://www.wireshark.org/


Geoff
--

dferencz
Wed May 21 10:19:53 PDT 2008

On May 21, 8:55=A0am, jipinj...@gmail.com wrote:
> On May 20, 9:18=A0pm, "Silver" <moc.liamtoh@gnirrevliseht> wrote:
>
> > I seriously doubt that your Ethernet driver is causing the delay but tha=
t is
> > easy to test using 'ping'. Simply ping one device from the other and loo=
k at
> > the ping time.
>
> > I have run this on very similar configurations to you and experienced
> > sub-second latency, around 500mS maximum. I was using PCM u-Law codecs.
> > The signalling protocol does not matter as RTP handles the voice
> > transmission whereas SIP/H323 setup the call and terminate it but do not=

> > carry voice data.
>
> > Are you perhaps using VMINI - that is using KITL on the same Ethernet pa=
rt
> > as NDIS?
>
> > Geoff
> > --
>
> =A0 Thank you Geoff,
>
> We have tested using ping as you said, between a PC and a device. We
> have observed the ping time as 1 millisecond only.So can i confirm
> that the ethernet driver is not making any delay. We are not using
> VMINI.We have disabled the KITL and using SMSC 9118 ethernet miniport
> driver.Is there any other way to test the ethernet performance?.
>
> Jipin

Jipin,

You should also investigate the performance of your wave audio driver
(capture), as latency could be due to the driver collecting a large
number of samples before forwarding it to the VoIP codec. Refer to
the "Voice Performance" topic in the CE 5.0 documentation.

-- Don

Silver
Wed May 21 11:35:15 PDT 2008

That is a very good point.
8KHz samples, mono, 16 bit would be 16KB/second being written to the wave
driver. It is probable that it is double buffered, and may not start until
the second buffer is full. See if you can set the audio buffer to 1-2 KB.

jipinjose
Thu May 22 20:37:33 PDT 2008

On May 21, 11:35=A0pm, "Silver" <moc.liamtoh@gnirrevliseht> wrote:
> That is a very good point.
> 8KHz samples, mono, 16 bit would be 16KB/second being written to the wave
> driver. It is probable that it is double buffered, and may not start until=

> the second buffer is full. See if you can set the audio buffer to 1-2 KB.

Thanks again .We ping it with much bigger size like 16kb and 32 kb
also. The result were like this

Device to PC

3000 bytes 3ms
6000 bytes 4ms
16k average 9ms maximum is 12ms
32 k average 18 maximum 21 .

PC to device

3000 bytes 2ms
6000 bytes 3ms
16k 7ms
32k 13ms

=46rom this result can i infer that there is some problem with the
miniport driver since there is a wide variation in time in both cases.
Regarding that CETK can KITL and miniport co-exist.We have disabled
KITL to give way to miniport driver.We are going deep into audio
driver as you said.


Jipin

Silver
Fri May 23 09:57:10 PDT 2008

From those results I would infer that the miniport driver is fine. It is
rather normal for the times to drift around by a few mS.

jipinjose
Wed May 28 06:20:56 PDT 2008

On May 23, 9:57=A0pm, "Silver" <moc.liamtoh@gnirrevliseht> wrote:
> From those results I would infer that the miniport driver is fine. It is
> rather normal for the times to drift around by a few mS.


thank you Geoff . for your valuable support. We have confirmed SMSC
is not making any problem.
We turned to audio driver now.

Jipin