On 3/27/2021 6:58 PM, aster...@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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
