Using ARI I placed an outbound call. I then run the call through a number of dialogs. At a certain point I tried to record the caller and got an error that the call can’t be recorded because it’s in a bridge.
I did my research, found that outbound callers are placed in a holding bridge so they can be connected to the originating caller. In the CLI I fond the bridge Id, and I can kick the caller from the bridge.
But, I don’t have anyway of removing the channel from the bridge through ARI. I have no reference to the bridge and no way to get a reference to the bridge.
Any help would be appreciated.
You’re going to need to be more specific about how you are using ARI (what operations you are executing) and when. As well you’ll need to define what recording means to you. If you are referring to MixMonitor like recording, then the record operation isn’t directly used for that.
I created a new channel using: POST /channels/create
When I receive the StasisStart message I used: POST /channels/{channelId}/dial
When I received the ChannelStateChange message I verifed that the Channel state is UP
During the course of the phone call I issue a number of: POST /channels/{channelId}/play
And recieve a number of ChannelDtmfReceived messages
At a certain point I issued: POST /channels/{channelId}/record
And I received a RecordingFailed message with a liverecording.cause that says “Cannot record channel while in bridge”
When I have a caller who dials in, and I take them through the same call flow, I have no problem.
What I have discovered is that outbound calls are automatically placed in a holding_bridge, as evidenced by watching the asterisk console and from information in the Asterisk documentation.
When I use core show channel I can see that the channel is in a bridge that I didn’t place it in.
If I kick the bridge I can remove the caller before getting to the recording part of my call flow and everything works fine.
The question is, how do I get the channel out of that bridge?
As far as I know I can’t get the ID of the bridge from ARI. If I could I would simply remove him from the bridge.
Is there a channel variable I can check to get the bridge ID?
The bridge in question is invisible, used as a method to ensure that channels being dialed are properly handled. As a workaround is there any reason you don’t use the normal non-create/dial mechanism for dialing? It works a different way and would not have the same problem. I think what you’ve uncovered is a specific use case that was not envisioned for the create/dial method.
I have a while without use ARI so Im not very practical with it , but have you try list: GET /bridges
Also for method POST /channels/{channelId}/record documenation says
The bridge itself has a record feature if that’s what you want.
POST /bridges/{bridgeId}/record
The bridge the channel is in won’t appear there and can’t be interacted with, it’s invisible. It’s not meant to be used but is an implementation detail of create and dial support itself.
What is the normal mechanism for non-create/dial?
It doesn’t appear in the list of bridges. The only way I can see it is by showing the channel info in the Asterisk console. Once you have the ID from that you can work with it, but there’s no other way to get it.
Doing a POST to the channels route[1] will cause a channel to get originated and upon answer it can be sent to the provided Stasis application.
Thanks @jcolp . That works great.
Although… I am suffering a different problem with it.
Both the channel variable EXTEN and the dialplan.extension are == ‘s’ instead of the extension I set when I call OriginateWithId
As you can imagine I use the extension (or, the dialed phone number) to determine the call path to take to take the caller through.
I could pass a channel variable, or a stasisStart argument to handle this, but I things to be a little cleaner.
What extension are you referring to with originate? If you’re talking about the extension field, that’s for sending it into the dialplan. Otherwise most people use the arguments to control things.
Yeah, I was talking about the extension field. I expected the new channel’s extension to contain that value, instead it contains “s”
I wound up using stasisStart arguments to handle it.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.