Duplicated ARI events

Hi Guys,
Im trying to previne problems with recorders in my asterisk, my dialplan is all using ARI reading de events and doing what i have to do.
But now im trying to read two specifie events RecordingStarted and RecordingFinished and for those cases i ever receive two simultaneous events with the same information.
I am starting the recorder on a bridge with two channels, i tried start de recorder without channels to see whats happen but the same occurre.
In the ari debug i see two events , i have just one application registred on ARI.

ARI DEBUG:

<— Sending ARI event to 127.0.0.1:47266 —>
{
“type”: “RecordingFinished”,
“timestamp”: “2022-03-16T09:27:20.443-0300”,
“recording”:

{ “name”: “temp/0500000012347491424898”, “format”: “wav”, “state”: “done”, “target_uri”: “bridge:adb4343c-e46b-465a-ad80-cc2d1b3d1f8e”, “duration”: 19 }

,
“asterisk_id”: “08:00:27:8e:4e:31”,
“application”: “dialer”
}
<— Sending ARI event to 127.0.0.1:47266 —>
{
“type”: “RecordingFinished”,
“timestamp”: “2022-03-16T09:27:20.443-0300”,
“recording”:

{ “name”: “temp/0500000012347491424898”, “format”: “wav”, “state”: “done”, “target_uri”: “bridge:adb4343c-e46b-465a-ad80-cc2d1b3d1f8e”, “duration”: 19 }

,
“asterisk_id”: “08:00:27:8e:4e:31”,
“application”: “dialer”

The problem with this is that I can’t tell the events apart and I double-flow for those events.
This is normal ? Why does it happen?

Environment:
Asterisk 18.6.0 running on CentOS 7.
I have an application with python registring a app on asterisk to read events and send de ARI commands

You’d need to show the actual complete interaction and requests, not just the events. It’s also slightly unclear - are you saying you are receiving both RecordingStarted and RecordingFinished twice? Are you also receiving bridge events twice?

Hi jcolp ! Thanks for you attention.
So basically i am receiving both RecordingStarted and RecordingFinished twice, another events i receive once.
See this test.

I create a bridge:

POST http://asteriskip:8088/ari/bridges

Post response:

{
“id”: “ad3fa240-a5bb-4589-a35c-3f72b5289e25”,
“technology”: “simple_bridge”,
“bridge_type”: “mixing”,
“bridge_class”: “stasis”,
“creator”: “Stasis”,
“name”: “”,
“channels”: ,
“creationtime”: “2022-03-17T11:42:56.265+0000”,
“video_mode”: “talker”
}

ARI Send the event to my stasis aplication registred:

<— Sending ARI event to ipappstasis:44182 —>
{
“type”: “BridgeCreated”,
“timestamp”: “2022-03-17T11:42:56.265+0000”,
“bridge”: {
“id”: “ad3fa240-a5bb-4589-a35c-3f72b5289e25”,
“technology”: “simple_bridge”,
“bridge_type”: “mixing”,
“bridge_class”: “stasis”,
“creator”: “Stasis”,
“name”: “”,
“channels”: ,
“creationtime”: “2022-03-17T11:42:56.265+0000”,
“video_mode”: “talker”
},
“asterisk_id”: “02:42:ac:12:00:02”,
“application”: “dialer”
}

This is ok.

But i want record this bridge, so i start the record

POST http://myip:8088/ari/bridges/ad3fa240-a5bb-4589-a35c-3f72b5289e25/record?name=test&format=wav

POST response:

{
“name”: “test”,
“format”: “wav”,
“state”: “queued”,
“target_uri”: “bridge:ad3fa240-a5bb-4589-a35c-3f72b5289e25”
}

ARI Send the event to my stasis aplication registred:

<— Sending ARI event to ipappstasis:44182 —>
{
“type”: “RecordingStarted”,
“timestamp”: “2022-03-17T11:45:24.386+0000”,
“recording”: {
“name”: “test”,
“format”: “wav”,
“state”: “recording”,
“target_uri”: “bridge:ad3fa240-a5bb-4589-a35c-3f72b5289e25”
},
“asterisk_id”: “02:42:ac:12:00:02”,
“application”: “dialer”
}
– x=0, open writing: /var/spool/asterisk/recording/test format: wav, 0x7fe26400cc40
<— Sending ARI event to ipappstasis:44182 —>
{
“type”: “RecordingStarted”,
“timestamp”: “2022-03-17T11:45:24.386+0000”,
“recording”: {
“name”: “test”,
“format”: “wav”,
“state”: “recording”,
“target_uri”: “bridge:ad3fa240-a5bb-4589-a35c-3f72b5289e25”
},
“asterisk_id”: “02:42:ac:12:00:02”,
“application”: “dialer”
}

With that event i have a problem, because the both have the same data. For the Recording Finished ocurre the same.

For this test i didn’t put channels on the bridge, if i add a channel the same occurs.

I hope I have clarified the situation.

And is this a recent issue? If you go back a few versions does it also happen?

I had only worked with ari dialplan with versions 18.6.0
But after your question i scaled up two asterisk with another version to make a test.
In the version 13.34 and 18.10.1 the same ocurres.

So you were using 18.6.0 previously and it was duplicating it? Do you have any other explicit subscriptions for your application?

Until then I didn’t need to listen for these events specifically, so given the imagined tests they were already duplicated.
I have only one subscription in my application.

I’m not sure with your answer. Were they duplicated in 18.6.0 as well?

What do you mean by “only one subscription in my application”?

I’m asking for specifics because we have a specific test which covers recording a bridge. It is not receiving the duplicate events. It gets 1 RecordingStarted and 1 RecordingFinished.

Yes they duplicated in 18.6.0.
I have one aplication registred in ari apps.

Connected to Asterisk 18.6.0 currently running on myserver 
myserver*CLI> ari show apps
Application Name         
=========================
dialer

You’ll need to provide an ARI application that reproduces the specific issue.

Hi jcolp,
After your answers i had tried make a test without my python application, now i just connect on asterisk websocket using a postman.
To make sure i have not a bug on my code.

myip:8088/ari/events?api_key=user:pass&app=hello-world&subscribeAll=true

Making the same post to create a bridge, and after starting a recorder i got two events too

Maybe can be a bug ?

You’re doing subscribeAll, that is likely the cause of this. If you remove it does that stop the duplicate events? It wouldn’t surprise me if it could cause multiple events to be sent due to the various automatic subscriptions and messages that go on.

1 Like

Hi jcolp !
Im testing with SubscribeAll = False and now i receive a single Event, my logic with this subscribe mode will change, but works fine.
Thanks for your support !

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.