I’m trying to use TALK_DETECT on a dialer (using ARI) where there’s just one outgoing originated channel and then a script would decide what to do based on AMD, but it doesn’t work (ChannelTalkingStarted and ChannelTalkingFinished events are not firing). I confirmed there’s audio on the channel.
Doing some research I’ve found a forum post that states “ TALK_DETECT works on the stream of media from the remote party ”, so I confirmed it works when there are two channels connected on a bridge.
So my question is: Is it possible somehow to make TALK_DETECT work on a single outgoing originated channel and detect when the remote party answers? The dialer is not supposed to connect the outgoing channel to an agent until AMD is completed.
TALK_DETECT works on a channel, so only needs one channel. It monitors the associated audiohook in the read direction, which I believe means that if you run it on the B side of an originate, it will monitor the audio from the A side device, which seems to be what you want.
Can you please clarify? My ARI application originates a channel to an outside phone number, and it sets TALK_DETECT on that channel once the ChannelStateChange event is received with the channel state UP. At that point there’s only one channel to set TALK_DETECT on. Correct?
The channel state only goes to up once answered, unless you’re using a Local channel and manually answering in dialplan. I think you’d need to describe the actual scenario further - such as when up actually occurs and such.
Yes, TALK_DETECT is being set once the channel is answered because my understanding is that it doesn’t work if done before (of course I might be wrong).
Here’s the scenario (everything done with ARI, no dialplan):
Application uses /channels to originate a call to an external number on a trunk.
The remote party picks up the phone and the ARI application receives ChannelStateChange event with channel state UP. At that point the application uses ARI to set the TALK_DETECT variable on that channel.
The remote party then starts talking but ChannelTalkingStarted and ChannelTalkingFinished events are not firing.
If try a different scenario where I bridge the remote party’s channel with another endpoint channel (so they can talk to each other) before setting TALK_DETECT (and leaving the rest the same), then in that case ChannelTalkingStarted and ChannelTalkingFinished events are received.
Hope that clarifies the scenario. Please let me know if you need more information.
It works on audio flowing, whether that occurs before or after answer the TALK_DETECT functionality doesn’t care. Are you sure you are actually receiving audio after answer? The “rtp set debug on” CLI command will show received media. Are you behind NAT?
Yes, I’m behind NAT, but I confirmed audio is being received by recording the channel. Also, when the channel is bridged both parties can hear each other.
Just confirmed I get 409 Conflict from ARI if I try to set TALK_DETECT on the channel while ringing so it looks like Asterisk does care about the channel state (at least from ARI). However, it’s fine if done after the channel is up: (/channels/1589231317.22/variable?variable=TALK_DETECT(set)&value=2500,256)
I’ve confirmed there is no RTP flowing if there isn’t somebody listening on the other side (either another bridged channel or channel recording), which makes sense. I’ve tried with a snoop channel but there’s no audio flowing that way. Not sure if there’s another way to get RTP flowing for talk detection to work.
Thank you for helping me understand the underneath mechanics of the talk detection feature.
What happens if you play back an audio file to the channel? Does media then flow?
Even if nothing is listening to the channel it should still receive audio. The only time it wouldn’t is if the other side either required audio to be received before sending it (which would be odd) or if the NAT requires packets to be sent out before it will allow packets to come in. It could also occur if your setup isn’t properly configured for NAT and the wrong IP address is in the SIP SDP, which then the remote side may only latch onto your actual IP address once it receives media.
If I play audio on the channel then media flows and talk detection works.
I guess it could be a NAT problem, although I haven’t had any problems with it so far. Like in the case talk detection works when recording is started on the channel, does the recording function sends any RTP at all to the remote party or just listens?
Asterisk can be configured to send silence when recording in asterisk.conf. Before going further I’d double check all the assumptions of things.
Double check pjsip.conf to ensure the correct external IP address is set
Double check that value in a call using “pjsip set logger on”
Double check the port forwarding for NAT
Based on your feedback decided to try the single channel scenario with a regular softphone endpoint (not a trunk) and talk detection works just fine, so the issue is definitely NAT or something else because it only happens when dialing out though my provider (flowroute).
Checked the NAT configuration, the external IP, and the SIP messages seem to have the correct IP addresses (my cloud based VM’s public IP and the flowroute’s POP IP). Maybe Flowroute is doing some internal optimization or something that prevents the RTP flow in that specific scenario.