29 Jul
2009
29 Jul
'09
4:03 p.m.
Hello Harald,
On Wed, 29 Jul 2009 12:33:59 +0200, "Harald Welte" <laforge(a)gnumonks.org>
wrote:
The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
page, like the EFR capture before. I hope this helps you to decode the voice
samples.
Decoding with Toast would work fine but there is the same problem, lots
of missing packets. If I look at the capture timestamps, there seem to
miss about 0.8 seconds of data at regular intervals (the first disruption
is at packet number 681, the next at 710, 742, ...). These are also the
positions where the Wireshark RTP analysis complains about wrong sequence
numbers.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
29 Jul
29 Jul
2:43 p.m.
New subject: ip.access RTP capture using Version 1 (FR) codec
Hi Dieter,
On Wed, Jul 29, 2009 at 02:03:10PM +0200, Dieter Spaar wrote:
On Wed, 29 Jul 2009 12:33:59 +0200, "Harald
Welte" <laforge(a)gnumonks.org> wrote:
That's really weird. I almost think there must be something wrong on my
machine while capturing those packets. At least while making the call I did
not notice strange interruptions - but I may have missed that.
If you're interested, you can certainly try for yourself with your nanoBTS...
In any case, openbsc seems to be able to deal quite fine with FR and EFR calls
in TCH/F timeslots now.
Regards,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
page, like the EFR capture before. I hope this helps you to decode the voice
samples.
Decoding with Toast would work fine but there is the same problem, lots
of missing packets. If I look at the capture timestamps, there seem to
miss about 0.8 seconds of data at regular intervals (the first disruption
is at packet number 681, the next at 710, 742, ...). These are also the
positions where the Wireshark RTP analysis complains about wrong sequence
numbers.
5392
days inactive
5392
days old
1 comments
2 participants
participants (2)
-
Dieter Spaar -
Harald Welte