On Fri, Oct 2, 2015 at 2:13 PM, Alexander Traud <[email protected]> wrote: > I am creating a translation module for AMR-WB. In one scenario on the > SIP/SDP layer, a higher ptime was negotiated than the default one. For > example, 60ms were negotiated instead of the AMR default 20ms. Now, Asterisk > should send three frames per RTP packet. I try to play one of the recorded > voices (slin8). Asterisk sends 320 samples to my translation module; the > default for 20ms packetization. My translation module has to wait 960 > samples to create the frames. > > Which structure do I have to query: How do know the ptime, there in such a > transcoding module? This was available in Asterisk 11 via > ast_format->cur_ms. How do I access this information in Asterisk 13|master? > > I am asking asterisk-dev, because all transcoding modules might be affected. > At least with AMR-WB, I have to code/build those frames within the module > because RFC 4867 mandates a special header (section 4.3.5.2 and 4.4.5.1). At > first glance, this could be an architectural issue. Therefore, I am asking > for advice how to approach this: Simply, re-adding "cur_ms" to ast_format? >
I don't think we want to add cur_ms back to ast_format, for two reasons. The first is simply that packetization is negotiated at the media level, and applies to all formats negotiated for that media session. Hence why it was removed from the formats themselves - it exists at a "higher" level. Second, formats in 13+ are immutable by convention; this gave Asterisk a big performance improvement as it didn't have to copy the format structs all over the place. Unfortunately, that also means you don't want to change them too often. Generally, once created for a channel, you don't want to put more information in them or otherwise muck with them. Modifying a format during negotiation can be done, but there's a hit you pay for doing it at that point. Currently, packetization is only stored on the RTP instance, as that represents the media session that was negotiated along with all formats in that media session. If you need to get that information into a codec module, there's a few options: 1) Implement an attribute module for the format, such as res_format_amr_wb. You can set arbitrary attributes on any given format, and it will set those attributes in various callbacks into the module. The callbacks are responsible for creating a new cloned format, setting attributes on it in some private data structure, and returning the clone. The format core is smart enough to not impact "normal" formats using this approach. You can look at the existing implementations, such as res_format_attr_opus, to get a hint on how to do that. There are, however, a few issues with this approach: a) By default, the format attribute modules expect to get their attributes out of an 'fmtp' line in an SDP. The ptime attribute won't be passed along with that. That means that you'll have to update parsers of 'ptime' in the various channel drivers to call ast_format_attribute_set with the ptime value, and handle the cloned format appropriately. b) You'll need to pull the format for the RTP instance's codecs out using ast_rtp_codecs_get_payload_format, which may be tricky. Another way of handling this approach would be to implement the call to ast_format_attribute_set in ast_rtp_codecs_set_framing, as it knows how to get at the formats stored in the RTP instance. 2) Another option would be to just store the framing on the frame itself. Frames are not immutable; they are created by the RTP instance (which has the framing for that instance available on it), and could easily be set in ast_rtp_read. Since the framing negotiated is not dependent on the format but on the media session itself, it seems more appropriate to store it on the frames generated by that media session. What's nice about this is that codec modules are fed frames already; that means there's no additional lookups you'll have to do in your codec module. Of the two approaches I like #2 best, but some others may want to chime in on this as well. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- 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
