[asterisk-bugs] [JIRA] (ASTERISK-29373) res_rtp_asterisk: Flash events are duplicated
N A (JIRA)
noreply at issues.asterisk.org
Mon Mar 29 15:39:15 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254373#comment-254373 ]
N A commented on ASTERISK-29373:
--------------------------------
Actually, I tried that already, and when I do that, Asterisk crashed. Not sure why (I didn't do a backtrace or anything), but it doesn't seem to like that.
I have already spent 10-15 hours playing around and figuring out different ways to pre-empt the DTMF behavior and make it work in a logical way. The problem is in res_rtp_asterisk, but I could not get it to work in a satisfactory way just by trying to work with what is available. I tried over 50 combinations of things and they all had one downside or another.
I ended up going ahead and adding an AST_CONTROL_FLASH_END to eat up the end event, and assign AST_CONTROL_FLASH to the start event and AST_CONTROL_FLASH_END to the end one (I don't think it really matters; this was an arbitrary choice). I had to modify several other files as well - I've been basically been searching the entire repo for existing similar things and mirroring them - mostly the hold and DTMF syntax.
I found that when I use this second event, it works *perfectly*. No duplicate flash events, no erroneous DTMF. So, if this is not problematic in some way, this seems like the easiest way to go. I can't see how the FLASH_END event would be useful in the future, but I guess if someone wanted that event in the future then it would be there.
I have already patched the necessary files, including chan_iax2, with it programmed NOT to send the FLASH_END event (unlike the FLASH) event. I have patched 8 more files in addition to the 3 I patched earlier, and will probably need to patch a few more in order to get the AMI event working right. That's what I'm working on now.
For some reason, manager show events does not show any of the DTMF events. I am not sure if this is yet some other bug or not. I set up an entirely new machine and Asterisk 18.3.0 for developing this feature today and its manager is also missing them - most of the events are there, but not the DTMF ones. So I'm wondering if my Flash event will show up even if I do it correctly now:
Connected to Asterisk 18.3.0 currently running on mn3 (pid = 24716)
mn3*CLI> manager show events
Events:
-------------------- -------------------- --------------------
AGIExecEnd AGIExecStart AOC-D
AOC-E AOC-S AgentCalled
AgentComplete AgentConnect AgentDump
AgentLogin AgentLogoff AgentRingNoAnswer
Agents AgentsComplete Alarm
AlarmClear AorDetail AorList
AsyncAGIEnd AsyncAGIExec AsyncAGIStart
AttendedTransfer AuthDetail AuthList
AuthMethodNotAllowed BlindTransfer BridgeCreate
BridgeDestroy BridgeEnter BridgeLeave
BridgeVideoSourceUpd CEL Cdr
ChallengeResponseFai ChallengeSent ChanSpyStart
ChanSpyStop ChannelTalkingStart ChannelTalkingStop
ConfbridgeEnd ConfbridgeJoin ConfbridgeLeave
ConfbridgeList ConfbridgeMute ConfbridgeRecord
ConfbridgeStart ConfbridgeStopRecord ConfbridgeTalking
ConfbridgeUnmute ContactList ContactStatus
ContactStatusDetail CoreShowChannel CoreShowChannelsComp
DAHDIChannel DNDState DeviceStateChange
DialBegin DialEnd DialState
EndpointDetail EndpointList ExtensionStatus
FAXSession FAXSessionsComplete FAXSessionsEntry
FAXStats FAXStatus FailedACL
FullyBooted Hangup HangupHandlerPop
HangupHandlerPush HangupHandlerRun HangupRequest
Hold IdentifyDetail InvalidAccountID
InvalidPassword InvalidTransport Load
LoadAverageLimit LocalBridge LocalOptimizationBeg
LocalOptimizationEnd MCID MWIGet
MWIGetComplete MeetmeEnd MeetmeJoin
MeetmeLeave MeetmeMute MeetmeTalkRequest
MeetmeTalking MemoryLimit MiniVoiceMail
MixMonitorMute MixMonitorStart MixMonitorStop
MonitorStart MonitorStop MusicOnHoldStart
MusicOnHoldStop NewAccountCode NewCallerid
NewConnectedLine NewExten Newchannel
Newstate OriginateResponse ParkedCall
ParkedCallGiveUp ParkedCallSwap ParkedCallTimeOut
PeerStatus Pickup PresenceStateChange
PresenceStatus QueueCallerAbandon QueueCallerJoin
QueueCallerLeave QueueMemberAdded QueueMemberPause
QueueMemberPenalty QueueMemberRemoved QueueMemberRinginuse
QueueMemberStatus RTCPReceived RTCPSent
ReceiveFAX Registry Reload
RequestBadFormat RequestNotAllowed RequestNotSupported
SIPQualifyPeerDone SendFAX SessionLimit
SessionTimeout Shutdown SoftHangupRequest
SpanAlarm SpanAlarmClear Status
StatusComplete SuccessfulAuth TransportDetail
UnParkedCall UnexpectedAddress Unhold
Unload
> 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)
More information about the asterisk-bugs
mailing list