[asterisk-bugs] [JIRA] (ASTERISK-25579) Outgoing Packetization Time (Speex, AMR, Opus, …)

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-25579:
---------------------------------------

    Attachment: ptime.patch

The attached patch works for chan_sip. In an {{ast_translator}} and its frameout, you call {{ast_format_frame_blocks}} to create a larger {{ast_frame}} than usual.

The attached patch does not qualify for inclusion in Asterisk, because formats could be shared between threads. Because formats are accessed (compared) in Asterisk 13 very often, the struct {{ast_format}} does not offer any locking. Therefore, changing a {{ast_format}} instead of cloning it is not thread safe. Furthermore, many formats are cached and a single struct is used throughout Asterisk (if that format does not have a format-attribute module). Therefore, formats are called immutable.

This could be worked-around. However according to a discussion on the mailing list [asterisk-dev|http://lists.digium.com/mailman/listinfo/asterisk-dev], the negotiated packetization time should [not be stored |http://lists.digium.com/pipermail/asterisk-dev/2015-October/075120.html] in {{ast_format}} but somewhere else.

I was not able to create such a patch, because the incoming and outgoing channels use different {{ast_translator}}, {{ast_trans_pvt}}, and {{ast_frame}} structs. {{ast_translate(.)}} is called before the RTP layer is met.

Because I do not have any further idea, I have given-up on this issue until I find a concrete solution how/when to store the packetization time.

> Outgoing Packetization Time (Speex, AMR, Opus, …)
> -------------------------------------------------
>
>                 Key: ASTERISK-25579
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25579
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/codec_speex, Codecs/General
>    Affects Versions: 11.20.0, 13.6.0
>            Reporter: Alexander Traud
>            Severity: Minor
>         Attachments: ptime.patch
>
>
> Since Asterisk 13, an ast_translator {{codecs/codec_*}} does not know the amount of frames to be put into one RTP payload packet in its routine frameout. However, this is required when the packetization time (in SIP/SDP: ptime) is not the default one.
> For example, when a ptime of 60ms is negotiated for Speex, Asterisk should send 60ms in one RTP packet. Currently, Asterisk sends three times 20ms.
> This affects all (only) those formats which cannot be smoothed:
> * Asterisk 11, see res/res_rtp_asterisk.c:ast_rtp_write
> * Asterisk 13, see main/codec_builtin.c; all codecs without ".smooth = 1"
> With those formats, ast_format_can_be_smoothed(.) returns 0, because the format uses
> (A) variable bit-rate (vbr) or
> (B) several modes with different bit-rates.
> In those cases, {{ast_format_get_minimum_bytes(.)}} is of no help to create the amount of frames per payload. These formats are Speex, G.719, [G.723.1|http://asterisk.hosting.lv/], [Siren|http://www.digium.com/products/asterisk/downloads], [SILK|https://github.com/traud/asterisk-silk], and CELT. Furthermore, this affects external modules like [iLBC 20|https://github.com/traud/asterisk-ilbc], [AMR(-WB)|https://github.com/traud/asterisk-amr], [Codec 2|https://github.com/traud/asterisk-codec2], and [Opus|https://github.com/seanbright/asterisk-opus].
> This is just about outgoing packets (Asterisk to another party). Incoming packets must be decodable by a transcoding module even without this information, because the incoming ptime could change at any time.
> {{ast_rtp_codecs_get_framing(.)}} provides this information. Furthermore, the channel driver negotiates this value, therefore the channel knows this as well. However, this information is required in {{ast_translator.frameout(ast_trans_pvt)}}.
> In Asterisk 11, this information is available. However, its Speex module does not us this to create the correct frame length, either.



--
This message was sent by Atlassian JIRA
(v6.2#6252)