[asterisk-dev] Hook flash events

[asterisk at phreaknet.org]

On 3/27/2021 6:58 PM, asterisk at phreaknet.org wrote:
> Hello,
>
>    I have patched chan_sip to recognize application/hook-flash as a 
> hook flash event (AST_CONTROL_FLASH), and with that am now proceeding 
> to add full flash support to Asterisk. My current understanding is 
> Asterisk will propagate these events across channels if possible, but 
> is unable to do anything with them itself. I'd like to be able to 
> trigger dialplan activity on flashes, so I'm thinking making this 
> available as an AMI event might be the way to go (I haven't used AMI 
> before either, but it seems like this would be the correct way to do 
> this). Then I could see that event and spawn dialplan activity "out of 
> band" in a new channel and manipulate the channel on which the flash 
> occurred as needed.
>
> I've started by patching channel.c and file.c to print out information 
> about flash events. I have tested 3 different SIP clients in 4 
> different modes. When SIP INFO is used, all is well. When RFC2833/AVT 
> is used, there are duplicate events. I'm stopping here to figure this 
> out because if duplicate AMI events are sent, that would defeat the 
> purpose.
>
> I took a packet capture of a tSIP call for simplicity and discovered 
> that for each hook flash event, there were:
>
> 9 packets of "Payload type=RTP Event, Flash"
> 3 packets of "Payload type=RTP Event, Flash (end)"
>
> So, with hook flashes conveyed via RTP, there is a "start" and an 
> "end", or 2 events per flash. However, unlike ...DTMF_BEGIN and 
> ...DTMF_EVENT, there is only one ...CONTROL_FLASH event to work with 
> in Asterisk.
>
> Rearchitecting AST_CONTROL_FLASH seems like it would not be feasible. 
> Might there be a good way to filter out one of the two RTP events, 
> without having to keep track of "start" and "end" like the DTMF events 
> do? This is a non-issue for SIP INFO, of course, and only happens with 
> RFC2833 flash events. Some agents only support one or the other.
>
> <snip>

After some hours of debugging, I found the problem - not in channel.c at 
all but in res_rtp_asterisk.c. With RFC2833 RTP events, there is a start 
and an end defined for all events. Asterisk receives one for each packet 
but ignores the duplicates. It processes one for the start and one for 
the end - expected for DTMF, but problematic for flash events, since 
Asterisk does not have AST_CONTROL_FLASH_BEGIN and 
AST_CONTROL_FLASH_END, but simply AST_CONTROL_FLASH. The RTP code never 
accounts for this.

I managed to find some information that was consistent across multiple 
SIP clients that indicate whether it was the beginning or the end. It 
seems most sensible to simply have the RTP code ignore the flash end 
event and use the flash start event, so I will create the patch to do 
that. This seems like it would cause the least disruption while 
correcting the behavior so that RTP and channel.c are on the same page.