[asterisk-bugs] [JIRA] (ASTERISK-23437) ARI: Add the ability to add properties to a bridge on creation

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp reassigned ASTERISK-23437:
--------------------------------------

    Assignee: Joshua Colp

> ARI: Add the ability to add properties to a bridge on creation
> --------------------------------------------------------------
>
>                 Key: ASTERISK-23437
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23437
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_ari
>            Reporter: Matt Jordan
>            Assignee: Joshua Colp
>
> Right now, when a user creates a bridge in ARI, there's only two things they have to provide: name, and type.
> When a user creates a mixing bridge, the bridge is created with the following capabilities:
> {noformat}
> 		capabilities = AST_BRIDGE_CAPABILITY_1TO1MIX |
> 			AST_BRIDGE_CAPABILITY_MULTIMIX |
> 			AST_BRIDGE_CAPABILITY_NATIVE;
> {noformat}
> In reality, native bridging is a bit problematic. When channels are natively bridged, the DTMF (as well as the media) never flows through Asterisk. It goes directly between the two channels.
> Media usually isn't a problem for ARI - most operations that require media will either switch the bridge type so that the media does go through the core, or will otherwise cause the media to shift back to Asterisk's core in some fashion. The DTMF issue - however - is a real problem.
> ARI should probably *not* use NATIVE bridging by default. If we do go down that path, however, that means we need to allow users to natively bridge channels when they are created using {{POST /bridges}}.
> This would be an optional query parameter - capabilities. A user could pass capabilities to a bridge and - if the type supports it - it would add those capabilities to its type.
> Default would be 1to1 and Multi (we probably don't want to ever expose those), and just allow someone to pass in native. Keeping it as a string allows new capabilities to be exposed as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)