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

[Matthew Jordan]

On Fri, Oct 2, 2015 at 2:13 PM, Alexander Traud
<pabstraud at compuserve.com> 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