Several Frames per Payload (affected user agent: MicroSIP)

[bfoot2018]

Hi Alexander,

The discussion is started in #15 (comment). Followed your recommendation and created new separate issue.

Have upgraded MicroSIP to the latest MicroSIP-3.19.7.exe https://www.microsip.org/downloads/?file=MicroSIP-3.19.7.exe. The issue with recording AMR is gone. Pl check successfull OK pcap / wav in attached zip.

Have tried AMR-WB and got garbled audio pl check NOK files. Could you pl describe how you compute real packetization time from raw RTP? In both cases asterisk answers with a=maxptime:20 in 200 OK / SDP.

amr_recording_tests.zip

[bfoot2018]

Asterisk 13.22.0 outputs:

Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007424, ts 030720, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007425, ts 031360, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007426, ts 032000, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007427, ts 032640, len 000083)
    -- Executing [5005@public:3] Record("SIP/6002-00000012", "asterisk-recording%d:wav,0,100,q") in new stack
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007428, ts 033280, len 000083)
[Aug 28 14:36:46] WARNING[17229][C-00000015]: codec_amr.c:236 amrtolin_framein: multiple frames per packet were not tested
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007429, ts 033920, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007430, ts 034560, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007431, ts 035200, len 000083)
Got  RTP packet from    192.168.5.33:4006 (type 121, seq 007432, ts 035840, len 000083)

[traud]

describe how you compute real packetization time from raw RTP

The RTP Timestamp.
In case of AMR-WB (16 kHz) with one 20ms frame, the timestamp increases by 320.
In case of AMR (8 kHz) with one 20ms frame, the timestamp increases by 160.
Anyway, that is not the problem here. In case of AMR(-WB), the frames are prepended with a jump-table. With one frame, I was able to ignore that jump table. With more than one frame, I have to parse it and extract each frame. This is AMR(-WB) specific stuff/code. Other audio codecs simply prepend the frames; the decoder is aware of this because of the RTP payload length.

asterisk answers with a=maxptime:20

Yes, you could argue that MicroSIP is doing a protocol violation here. However, a decoder has to cope with any amount of frames. My module does not support that because I had no implementation which did several-frames-per-payload, yet. Therefore, I am happy to get aware of such an implementation. Anyway, the solution to this takes several months because coding that is not that easy – although what is missing is ‘just’ a jump-table parser.

[bfoot2018]

Thanks for your detailed explanation. Is it possible to contact you via skype/email privately? Need your consultations on AMR/AMR-WB features - have AMR-WB spec for some product and need to find out what features are supported by your patch.

[traud]

On GitHub, you can see the E-mail address of a contributor by opening his commit and add .patch to the end of the URL, for example: https://github.com/traud/asterisk-amr/commit/72fddba0ae9e799fa13232d99ea1524548e141d9.patch. However, the ‘What is missing’ section in the README plus the other open issues is all I know.