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

[Jan Blom (JIRA)]

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

Jan Blom updated ASTERISK-28051:
--------------------------------

    Attachment: payload1.patch

> 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: 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)