[sip-comm-dev] Speex RTP timestamp errors


#1

Dear friends,

we (CircleTech, s.r.o.) are developing a Symbian & Windows Mobile VoIP client, and we test it against numerous PC-based clients. One of them is SIPCommunicator. I must have many words of praise for you! Yours is a truly outstanding piece of software.

Nevertheless, we ran into problems trying to communicate with SIPCommunicator and it seems that it is a bug in the SIPCommunicator.

While calling via SIP+RTP and using speex narrowband codec, SIP-Communicator sends erroneous timestamps for RTP packets it produces.

By speex-to-RTP standard (RFC 5574, section 3.1), the increments for timestamps should be equal to the sizes of frames in codec sampling units. The exact citation is

"Timestamp: A 32-bit word that corresponds to the sampling instant for the first frame in the RTP packet."

since a single speex frame is 20 ms, and Speex narrowband samples 8000 samples per second, this corresponds to 160 sanokes per frame. So the expected timestamps should be: 0, 160, 320, 480, 640 etc. Or, if multiple speex frames are carried in a single RTP packet, something like 0, 320, 640.

Instead, the timestamps of Speex frames sent by SIPCommunicator seem to start somewhere at 0xFFFFF???, then decrease by one. Attached is a cut-out screenshot from Wireshark, showing the incorrect timestamps sent by SIP-Communicator and correct timestamps sent by our VoIP client in the other direction. RTP Sequence Ids are correct.

That makes two-way communication hard, as jitter buffering usually relies on frame timestamps. As such, we can't process the audio stream from SIP-Communicator, although SIP-Communicator can process and play the stream coming from us.

Unfortunately, I could not find the relevant place in source code, so I can't submit a patch immediately.

The version of SIPCommunicator is 1.0 alpha 3 build 2591 for Windows.

Best regards

Marian Kechlibar


#2

Hey Marian,

На 07.05.10 15:57, Marian Kechlibar написа:

Dear friends,

we (CircleTech, s.r.o.) are developing a Symbian & Windows Mobile
VoIP client, and we test it against numerous PC-based clients. One of
them is SIPCommunicator. I must have many words of praise for you!
Yours is a truly outstanding piece of software.

Thank you very much for youre kind words!

Nevertheless, we ran into problems trying to communicate with
SIPCommunicator and it seems that it is a bug in the
SIPCommunicator.

Good catch! Could you please open an issue for it and we'll try to have
a look as soon as possible?

Thanks,
Emil

While calling via SIP+RTP and using speex narrowband codec,
SIP-Communicator sends erroneous timestamps for RTP packets it
produces.

By speex-to-RTP standard (RFC 5574, section 3.1), the increments for
timestamps should be equal to the sizes of frames in codec sampling
units. The exact citation is

"Timestamp: A 32-bit word that corresponds to the sampling instant
for the first frame in the RTP packet."

since a single speex frame is 20 ms, and Speex narrowband samples
8000 samples per second, this corresponds to 160 sanokes per frame.
So the expected timestamps should be: 0, 160, 320, 480, 640 etc. Or,
if multiple speex frames are carried in a single RTP packet,
something like 0, 320, 640.

Instead, the timestamps of Speex frames sent by SIPCommunicator seem
to start somewhere at 0xFFFFF???, then decrease by one. Attached is a
cut-out screenshot from Wireshark, showing the incorrect timestamps
sent by SIP-Communicator and correct timestamps sent by our VoIP
client in the other direction. RTP Sequence Ids are correct.

That makes two-way communication hard, as jitter buffering usually
relies on frame timestamps. As such, we can't process the audio
stream from SIP-Communicator, although SIP-Communicator can process
and play the stream coming from us.

Unfortunately, I could not find the relevant place in source code, so
I can't submit a patch immediately.

The version of SIPCommunicator is 1.0 alpha 3 build 2591 for
Windows.

Best regards

Marian Kechlibar

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

···

For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello Emil,

I just created the issue, as #821. It asked me for priority, so I
selected P2, because it looked as the middle-of-the-road option :slight_smile:
(hopefully this does not cause any problems).

Best regards

Marian

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi,

first of all thank you for reporting this and creating the issue,
which by the way is very descriptive and helpful.
I've just committed a fix for the problem so you can check r7102, if
you run from source or wait and run build 2627.

Thank you once again
damencho

···

On Mon, May 10, 2010 at 11:06 AM, Marian Kechlibar <marian.kechlibar@circletech.net> wrote:

Hello Emil,

I just created the issue, as #821. It asked me for priority, so I
selected P2, because it looked as the middle-of-the-road option :slight_smile:
(hopefully this does not cause any problems).

Best regards

Marian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net