Re: [Ekiga-list] G729 codec
- From: PawelCarqowski <paulino90 tenbit pl>
- To: Ekiga mailing list <ekiga-list gnome org>
- Subject: Re: [Ekiga-list] G729 codec
- Date: Sun, 4 Nov 2007 16:51:16 +0100
Jure,
comments in text
Jure Petrovic writes:
>
>
> I thought here might be the problem because I noticed differences in RTP
> payload sizes between received and sent packets when using Ethereal.
>
> However, I never had problems about not being heard by the other party.
> Does the other party hear anything at all? For example squeaky noise or
> just silence?
this is squiky noise.
>
> I would also like to know if you have a balanced connection when using
> this codec.. i.e. upload_rate = download_rate
>
> Note that the sizes, you are showing in the table seem to me as
> unencoded frames. g729_codec.c takes unencoded frame PCM-16 (160 bytes)
> and makes a encoded frame G729 (10 bytes). So your outgoing RTP packet
> should have payload size 10 or 20 bytes.
these values are differences in "timestamp" field of adjacent RTP packets.
>
> Regards,
> Jure
Here are the results:
1 - sjphone.correct.call.tcp
2 - myg729.ver0.1.tcp
3 - myg729.ver0.2.tcp
Trace outbound inbound outbound inbound outbound inbound
RTP TS RTP TS RTP Payload RTP Payload RTP rate RTP rate
difference difference size size (kbps) (kbps)
================================================================================================
1 160 480 20 60 8,083 8,083
2 160 480 20 60 7,969 8,621
3 80 480 10 60 7,963 8,159
My voip provider probably uses silence suppression, because, inbound
RTP packets do not flow constantly. Sometimes they appear, and then
dissappear. They always disappear at RTP packet that has "comfort
noise" payload type. I have silence suppression off in my ekiga, so
flow from ekiga goes without the breaks. So for computing inbound RTP
rate I took only some part of my trace. For trace 2 (myg729 ver0.1),
it is range of 19 inbound RTP packets. For trace 3 (myg729 ver0.2), it
is range of 17 inbound RTP packets. For trace 1 (sjphone trace), it is
range of 48 inbound RTP packets. For oubound rate computing I took the
whole trace (so this is more acurate).
have you got any ideas?
Regards,
Pawel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]