> 2) ... codec modules are fed [with] frames already ... Uh. That is a bit too abstract, yet: When do I tag the frames exactly?
ast_rtp_codecs_get_framing(ast_rtp_instance_get_codecs(instance)) provides the expected packetization value in res/res_rtp_asterisk.c, yes. However, the transcoding module needs that value while creating the frame, somewhere in the call chain: ast_write -> ast_translate -> *frameout. res/res_rtp_asterisk.c:ast_rtp_write is called after the above chain. Therefore, the frame would be tagged with the current packetization value too late. By the way, I might have created a misunderstanding: While reading (ast_rtp_read, ast_read), the AMR transcoding module does not care about that value because the remote device could send/use a different value anytime - actually the module does *not* need to know the value while reading AMR, because the module able to extract the amount of frames from the payload data itself. It is just about writing. My second issue with solution #2: Because ptime is needed in *frameout, the place where the frames are created, I do not know, which frames to tag. There is one frame in the private structure of the translation itself (ast_trans_pvt). Again yet, I was not able to find a place in code where that meets the RTP packetization value. Mhm. > formats in 13+ are immutable by convention Since Asterisk 13, there is a format cache, which is used heavily, yes. I guess, this is meant by immutable. Or? However, this is not used everywhere, see <http://github.com/traud/asterisk-amr> capability_cached_format.patch (Is that a patch not for a new feature but a bug?). At the end, I saw a lot of different ast_formats pointers in my res/res_format_attr_*.c, which had to be reduced because: I) The AMR decoder and the encoder require access to the fmtp line(s). Actually, the negotiated result of both lines is required. II) The decoder has to talk to the encoder (only that way is a must) because the remote device is able to request a AMR-mode change for the encoder. Therefore, ast_format_interface->format_get_joint creates a new ast_format. Consequently, I meet a unique entity when ast_format_cap_get_format_framing() is called. That is the place where I tag "my" ast_format/ast_format_interface with the current packetization value (possibility negotiated; sip.conf:autoframing=yes). That is very much your solution #1. Any comments? -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
