[asterisk-dev] SIP/SDP: ptime in translation module?

[Alexander Traud]

> 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?