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.