[asterisk-bugs] [JIRA] (ASTERISK-29373) res_rtp_asterisk: Flash events are duplicated

[N A (JIRA)]

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

N A commented on ASTERISK-29373:
--------------------------------

Okay, I will watch for that.

No issues with the other patches, but there seem to be all sorts of gotchas when trying to address this one. Trying to be direct about like dropping a frame led to Asterisk crashing, so that was a no go. It seems that if you try to prevent the flash event from going through, even by breaking out or returning null where applicable, it seems to auto fall through eventually to a DTMF_END event, with the result that a DTMF 'X' event passes through. In channel.c, one can try to prevent this by stifling DTMF if it happens to be 'X', and while this does prevent a LOG_DTMF event in the CLI, I noticed that if I'm at a dial tone like with Read() and I flash, this actually passes all the way through to the Read function as an "X". So the duplicate flash event is suppressed, but obviously, this is undesired.

It seems impractical to try to go on a while goose chase and suppress this invalid DTMF everywhere, since DTMF seems to be written with the idea that if it isn't a flash event, it must be DTMF. Cutting the extraneous flash event out either doesn't work or leads to a crash. Architecturally, how appropriate would it be to introduce a AST_CONTROL_FLASH_END in addition to the existing AST_CONTROL_FLASH? (I looked for a dummy code like AST_CONTROL_USELESS, but it doesn't seem like there is such a thing). I just need to discard this and throw it away. This would simply be a dummy thing to eat up the end RTP packets. The way RTP is set up, it you ignore the end events entirely, then it's equivalent to a continuous DTMF that never ends, since it's waiting for the end. Which approach would be better, in your opinion? It seems that addressing this bug will require some kind of major change.

> res_rtp_asterisk: Flash events are duplicated
> ---------------------------------------------
>
>                 Key: ASTERISK-29373
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29373
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 18.3.0
>         Environment: Debian 10
>            Reporter: N A
>            Assignee: N A
>              Labels: patch
>         Attachments: res_rtp_asterisk.patch
>
>
> I noticed that for RFC2833 hook flash events, they were all getting duplicated. I found this is due to the way RFC2833 events work, where there is a start and end for each event. However, unlike DTMF events, for which there are beginning and end events, Asterisk has no notion of the beginning or end of a hook flash - there is only one hook flash (AST_CONTROL_FLASH). Thus, incoming RTP packets create duplicate flash events, which channel.c is not expecting. The attached patch fixes this bug by ensuring that only flash starts become AST_CONTROL_FLASH and flash end events are not duplicated, thus aligning what res_rtp_asterisk.c is doing with what channel.c expects.



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