[asterisk-bugs] [JIRA] (ASTERISK-28051) RTP engine should only accept audio frames with allowed payloads

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244775#comment-244775 ] 

Asterisk Team commented on ASTERISK-28051:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> RTP engine should only accept audio frames with allowed payloads 
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-28051
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28051
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 15.6.0
>         Environment: CentOS 7.4 with Asterisk 15.6.0, PJSIP channel only
>            Reporter: Jan Blom
>              Labels: pjsip
>
> We run a stripped-down asterisk (both 15.5.0 and 15.6.0) with pjsip channel and only a few codecs since we want to avoid transcoding and other possible overhead.
> Some incoming calls from one provider is setup with only PCMA in SDP from both sides. This usually works as expected. However, a few calls start with a single RTP packet with G.722 payload before we receive the G.711 stream.
> This confuses Asterisk to think the received audio stream is G.722. “core show channel” reports “ReadFormat: g722” even after a second or two of receiving proper G.711 packets. 
> Since we don’t have a translation path between our voice prompts and G.722, asterisk complains and call will eventually end with a failure. We don’t have the G.722 codec loaded.
> Since we in the pjsip configuration only allow a few select codecs that we can handle, I would expect audio frames with a different payload  type to be ignored. At least as a configuration option.
> Looking at the source, it seems that ast_rtp_codecs_get_payload() (main/rtp_engine.c) should return NULL if the received payload type is not found in the current rtp instance. I have attached a patch that solves the issue for us. 
> There are probably other consequences with my simple patch, that I have overlooked. But it proves the point. 



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