[asterisk-bugs] [JIRA] (ASTERISK-24284) ARI fails to strip whitespace properly on bridge type attribute, allowing for bridges to be created even when provided attribute types conflict

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222467#comment-222467 ] 

Matt Jordan edited comment on ASTERISK-24284 at 8/28/14 8:52 PM:
-----------------------------------------------------------------

To provide more context to what Richard said:

What you are specifying when you provide a {{type}} to the bridge are attributes that you want the mixing technology to have:

{quote}
type: string - Comma separated list of bridge type attributes (mixing, holding, dtmf_events, proxy_media).
{quote}

That doesn't mean that the bridge handed back to you is going to have everything you list. It isn't. In fact, providing all of the attributes doesn't make any sense:
* A {{mixing}} attribute - which asks that media be mixed between all participants - is contradictory with a {{holding}} attribute
* A {{dtmf_events}} attribute - which asks Asterisk to decode all media so it can interpret DTMF - is contradictory with {{proxy_media}}, which asks Asterisk to natively swap media packets between channel drivers, if it can do so

I'll admit the wiki needs some more documentation on this front, but that's something we are actively working on (as you can probably tell by the recent updates on the wiki).

A bridge mixing technology that is returned in the resulting JSON is what Asterisk decided was the *best* mixing technology based on the attributes that you provided it. If you provide it with a bunch of attributes that don't make sense together, it does the best it can. Which is to give you a basic mixing technology (most likely with the media being decoded internally) if it can; or to return back a 500 if what you gave it makes no sense whatsoever.

Note that the spaces have nothing to do with you getting a 500. If I use a valid combination of attributes:

{noformat}
curl -v -u "asterisk":"asterisk" -X POST "http://localhost:8088/ari/bridges?brigeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,dtmf_events"
{noformat}

Asterisk happily creates a bridge:

{noformat}
< HTTP/1.1 200 OK
< Server: Asterisk/SVN-trunk-r422257
< Date: Fri, 29 Aug 2014 01:44:03 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 193
< 
{
  "id": "16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d",
  "technology": "simple_bridge",
  "bridge_type": "mixing",
  "bridge_class": "stasis",
  "creator": "Stasis",
  "name": "",
  "channels": []
}
{noformat}

The reason you get a 500 is because Asterisk explicitly forbids combining the {{holding}} and {{mixing}} attributes.

The only issue here is that using 'spaces' pre-pending the attributes caused it to work. We are using {{ast_strip}} to pull off leading whitespace characters; however, that doesn't appear to be working as intended.


was (Author: mjordan):
To provide more context to what Richard said:

What you are specifying when you provide a {{type}} to the bridge are attributes that you want the mixing technology to have:

{quote}
type: string - Comma separated list of bridge type attributes (mixing, holding, dtmf_events, proxy_media).
{quote}

That doesn't mean that the bridge handed back to you is going to have everything you list. It isn't. In fact, providing all of the attributes doesn't make any sense:
* A {{mixing}} attribute - which asks that media be mixed between all participants - is contradictory with a {{holding}} attribute
* A {{dtmf_events}} attribute - which asks Asterisk to decode all media so it can interpret DTMF - is contradictory with {{proxy_media}}, which asks Asterisk to natively swap media packets between channel drivers, if it can do so

I'll admit the wiki needs some more documentation on this front, but that's something we are actively working on (as you can probably tell by the recent updates on the wiki).

A bridge mixing technology that is returned in the resulting JSON is what Asterisk decided was the *best* mixing technology based on the attributes that you provided it. If you provide it with a bunch of attributes that don't make sense together, it does the best it can. Which is to give you a basic mixing technology (most likely with the media being decoded internally).

Note that the spaces have nothing to do with you getting a 500. If I use a valid combination of attributes:

{noformat}
curl -v -u "asterisk":"asterisk" -X POST "http://localhost:8088/ari/bridges?brigeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,dtmf_events"
{noformat}

Asterisk happily creates a bridge:

{noformat}
< HTTP/1.1 200 OK
< Server: Asterisk/SVN-trunk-r422257
< Date: Fri, 29 Aug 2014 01:44:03 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 193
< 
{
  "id": "16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d",
  "technology": "simple_bridge",
  "bridge_type": "mixing",
  "bridge_class": "stasis",
  "creator": "Stasis",
  "name": "",
  "channels": []
}
{noformat}

The reason you get a 500 is because Asterisk explicitly forbids combining the {{holding}} and {{mixing}} attributes.

The only issue here is that using 'spaces' pre-pending the attributes caused it to work. We are using {{ast_strip}} to pull off leading whitespace characters; however, that doesn't appear to be working as intended.

> ARI fails to strip whitespace properly on bridge type attribute, allowing for bridges to be created even when provided attribute types conflict
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24284
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24284
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari_bridges
>    Affects Versions: 12.5.0
>            Reporter: Pavel Kukin
>
> Bridge create query
> {noformat}
> curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,holding,dtmf_events,proxy_media"
> {noformat}
> returns 500 error. When type param contains spaces, it works.
> {noformat}
>  curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media"
> {noformat}
> Returned data is:
> {noformat}
> {"id":"16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d","channels":[],"name":"","technology":"simple_bridge","bridge_class":"stasis","creator":"Stasis","bridge_type":"mixing"}
> {noformat}
> As you can see type contains only mixing param and this is incorrect behavior. But at least it works.
> When I am using the same parameters separated with commas and spaces in my ari client code it returns 500 error. Weird thing. In previous Asterisk version my client had the same code and here is example how it worked.
> Request: 
> {noformat}
> { type: 'mixing, holding, dtmf_events, proxy_media',
>   bridgeId: 'b1cc1a44-0091-49db-ad62-97d165d70c05' }
> {noformat}
> Response:
> {noformat}
> {"id":"b1cc1a44-0091-49db-ad62-97d165d70c05","channels":[],"name":"","technology":"holding_bridge","bridge_class":"base","creator":"Stasis","bridge_type":"holding"}
> {noformat}
> Returned body had only holding type, which is also wrong. Another weird thing. I think the new ARI has some errors in its param parser. 



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