Bridge AMI Action and Masquerade only issue on local channel

Asterisk Asterisk APIs
1

Hi There,

I am kind of new to Asterisk and now we are updating from Asterisk v1.8 to v20 and our software which interacts with AMI Actions needs to be updated/fixed as well as a result of that. After a couple of migration fixes there’s a mayor blocking issue now concerning Bridging two channels with the Bridge AMI action (Asterisk 20 ManagerAction_Bridge - Asterisk Project - Asterisk Project Wiki).

Since the AMI v2 Specification, starting with Asterisk version 12, masquerades are gone, see AMI v2 Specification - Asterisk Project - Asterisk Project Wiki. As a result of that it seems that we are now no longer able to Bridge two channels where one of the channels is a Local channel. We receive the following error about this:

[Mar 6 13:16:07] DEBUG[4742] manager.c: Running action ‘Bridge’
[Mar 6 13:16:07] DEBUG[4742] features.c: Performing Bridge action on Local/+123@incoming-00000028;2 and SIP/TEST-00000025
[Mar 6 13:16:07] DEBUG[4742] stasis.c: Creating topic. name: bridge:all/bridge:02d85e1a-8447-47d3-9643-6dac6c371667, detail:
[Mar 6 13:16:07] DEBUG[4742] stasis.c: Topic ‘bridge:all/bridge:02d85e1a-8447-47d3-9643-6dac6c371667’: 0x7f0f7403caf0 created
[Mar 6 13:16:07] DEBUG[4742] bridge_native_rtp.c: Bridge ‘02d85e1a-8447-47d3-9643-6dac6c371667’ can not use native RTP bridge as two channels are required
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Bridge technology softmix has less preference than simple_bridge (10 <= 50). Skipping.
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Chose bridge technology simple_bridge
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Bridge 02d85e1a-8447-47d3-9643-6dac6c371667: calling simple_bridge technology constructor
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Bridge 02d85e1a-8447-47d3-9643-6dac6c371667: calling simple_bridge technology start
[Mar 6 13:16:07] DEBUG[4742] stasis_bridges.c: Update: 0x7f0f74026ca8 Old: New: 02d85e1a-8447-47d3-9643-6dac6c371667
[Mar 6 13:16:07] DEBUG[4742] bridge.c: Can’t move channel Local/+123@incoming-00000028;2 from bridge 652ecfca-2ff6-4332-b9f6-093d57a03333 into bridge 02d85e1a-8447-47d3-9643-6dac6c371667, masquerade only.

When I look at the source main\bridge.c (previously main\bridging.c) it looks like a new flag check triggers this. See commit 3d63833bd6c869b7efa383e8dea14be1a6eff998 for the change.

I’m looking for the next steps to take to overcome this issue. Is there an alternative way to achieve this maybe? Or maybe someone can explain what could be going wrong here?

Thanx in advance,

Idsert

2

Masquerades still exist. The problem (although you haven’t demonstrated there is a problem, other than scary debug messages), is that the operation you are using doesn’t allow them, but the previous bridge (confbridge), insists that they are used.

You didn’t mention that you were forcing a channel out of a confbridge.

Stabbing somewhat in the dark, I wonder if it is possible to do this in two steps: channel redirect the channel out of the old bridge; then bridge the, resulting, un-bridged channel.

(It looks like I need to get my head round the new bridge and masquerade architecture.)

3

On the Bridge AMI action we get the AMI response with no succes containing the following message:

Unable to add Channel1 to bridge: Local/+123@incoming-000010bf;2

I assumed that this was caused by the error from the debug messages.

I’ll check your suggestion :slight_smile:

4

The debug messages suggests the real problem is that it is unable to remove it from its existing bridge.

5

I did find you have to answer the channel before you can add it to a bridge.

6

The error message is only generated from part of the code that moves a channel from one bridge to another, so the channel had, previously been, successfully, placed in a bridge.

7

Thanx for the help. I have followed your suggestion and it seems to work now.

I have added a redirect before the bridge and the in the resulting dialplan (context where I redirect to) did an Answer() followed by a ConfBridge().

After this succesfull redirect to another Bridge (correct?), they seem to be able to be bridged/merged now. Scenario now works.

Greetz,

Idsert

8

If I understand the scenario, the Answer is redundant.

9

I’m kind of a rookie and without it seems to work also indeed. Thanks

10

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