[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=244979#comment-244979 ] 

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

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

> 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
>            Assignee: Jan Blom
>            Severity: Minor
>              Labels: patch, pjsip
>         Attachments: payload1.patch
>
>
> 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)