2013-04-22 14:58:53 +00:00
{
"_copyright" : "Copyright (C) 2012 - 2013, Digium, Inc." ,
"_author" : "David M. Lee, II <dlee@digium.com>" ,
"_svn_revision" : "$Revision$" ,
2016-11-18 09:46:48 -06:00
"apiVersion" : "2.0.0" ,
2013-04-22 14:58:53 +00:00
"swaggerVersion" : "1.1" ,
2014-09-20 23:41:55 +00:00
"basePath" : "http://localhost:8088/ari" ,
2013-04-22 14:58:53 +00:00
"resourcePath" : "/api-docs/channels.{format}" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2018-01-18 10:01:26 -05:00
"requiresModules" : [
"res_stasis_answer" ,
"res_stasis_playback" ,
"res_stasis_recording" ,
"res_stasis_snoop"
] ,
2013-04-22 14:58:53 +00:00
"apis" : [
{
"path" : "/channels" ,
"description" : "Active channels" ,
"operations" : [
{
"httpMethod" : "GET" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-10-16 14:02:06 +00:00
"summary" : "List all active channels in Asterisk." ,
2013-11-07 21:10:31 +00:00
"nickname" : "list" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "List[Channel]"
} ,
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Create a new channel (originate)." ,
2013-10-19 14:45:14 +00:00
"notes" : "The new channel is created immediately and a snapshot of it returned. If a Stasis application is provided it will be automatically subscribed to the originated channel for further events and updates." ,
2013-04-22 14:58:53 +00:00
"nickname" : "originate" ,
2013-10-21 18:59:51 +00:00
"responseClass" : "Channel" ,
2013-04-22 14:58:53 +00:00
"parameters" : [
{
"name" : "endpoint" ,
2013-06-28 16:23:24 +00:00
"description" : "Endpoint to call." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
2013-06-28 16:23:24 +00:00
"required" : true ,
2013-04-22 14:58:53 +00:00
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "extension" ,
2015-01-27 17:21:03 +00:00
"description" : "The extension to dial after the endpoint answers. Mutually exclusive with 'app'." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "context" ,
2015-01-27 17:21:03 +00:00
"description" : "The context to dial after the endpoint answers. If omitted, uses 'default'. Mutually exclusive with 'app'." ,
2013-06-07 18:39:42 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
2013-06-28 16:23:24 +00:00
"name" : "priority" ,
2015-01-27 17:21:03 +00:00
"description" : "The priority to dial after the endpoint answers. If omitted, uses 1. Mutually exclusive with 'app'." ,
2013-06-07 18:39:42 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
2013-06-28 16:23:24 +00:00
"dataType" : "long"
2013-06-07 18:39:42 +00:00
} ,
2015-01-07 18:54:06 +00:00
{
"name" : "label" ,
2015-01-27 17:21:03 +00:00
"description" : "The label to dial after the endpoint answers. Will supersede 'priority' if provided. Mutually exclusive with 'app'." ,
2015-01-07 18:54:06 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
2013-06-07 18:39:42 +00:00
{
2013-06-28 16:23:24 +00:00
"name" : "app" ,
2015-01-27 17:21:03 +00:00
"description" : "The application that is subscribed to the originated channel. When the channel is answered, it will be passed to this Stasis application. Mutually exclusive with 'context', 'extension', 'priority', and 'label'." ,
2013-06-07 18:39:42 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
2013-06-28 16:23:24 +00:00
"dataType" : "string"
2013-06-07 18:39:42 +00:00
} ,
{
2013-06-28 16:23:24 +00:00
"name" : "appArgs" ,
2015-01-27 17:21:03 +00:00
"description" : "The application arguments to pass to the Stasis application provided by 'app'. Mutually exclusive with 'context', 'extension', 'priority', and 'label'." ,
2013-06-07 18:39:42 +00:00
"paramType" : "query" ,
2013-06-28 16:23:24 +00:00
"required" : false ,
2013-06-07 18:39:42 +00:00
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
2013-06-28 16:23:24 +00:00
"name" : "callerId" ,
"description" : "CallerID to use when dialing the endpoint or extension." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2013-06-28 16:23:24 +00:00
} ,
{
"name" : "timeout" ,
"description" : "Timeout (in seconds) before giving up dialing, or -1 for no timeout." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 30
2014-01-21 14:27:21 +00:00
} ,
{
"name" : "variables" ,
2014-07-03 16:14:39 +00:00
"description" : "The \"variables\" key in the body object holds variable key/value pairs to set on the channel on creation. Other keys in the body object are interpreted as query parameters. Ex. { \"endpoint\": \"SIP/Alice\", \"variables\": { \"CALLERID(name)\": \"Alice\" } }" ,
2014-01-21 14:27:21 +00:00
"paramType" : "body" ,
"required" : false ,
"dataType" : "containers" ,
"allowMultiple" : false
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
} ,
{
"name" : "channelId" ,
"description" : "The unique id to assign the channel on creation." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "otherChannelId" ,
"description" : "The unique id to assign the second channel when using local channels." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2014-12-09 15:45:19 +00:00
} ,
{
"name" : "originator" ,
"description" : "The unique id of the channel which is originating this one." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2016-05-27 13:49:42 -06:00
} ,
{
"name" : "formats" ,
"description" : "The format name capability list to use if originator is not specified. Ex. \"ulaw,slin16\". Format names can be found with \"core show codecs\"." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2013-04-22 14:58:53 +00:00
}
2013-07-10 17:13:21 +00:00
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Invalid parameters for originating a channel."
2016-10-17 14:18:57 -05:00
} ,
{
"code" : 409 ,
"reason" : "Channel with given unique ID already exists."
2013-07-10 17:13:21 +00:00
}
2013-04-22 14:58:53 +00:00
]
}
]
} ,
2016-03-30 17:01:28 -05:00
{
"path" : "/channels/create" ,
"description" : "Create a channel and place it in a Stasis app, but do not dial the channel yet." ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"14.0.0"
] ,
2016-03-30 17:01:28 -05:00
"summary" : "Create channel." ,
"nickname" : "create" ,
"responseClass" : "Channel" ,
"parameters" : [
{
"name" : "endpoint" ,
"description" : "Endpoint for channel communication" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "app" ,
"description" : "Stasis Application to place channel into" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "appArgs" ,
"description" : "The application arguments to pass to the Stasis application provided by 'app'. Mutually exclusive with 'context', 'extension', 'priority', and 'label'." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "channelId" ,
"description" : "The unique id to assign the channel on creation." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "otherChannelId" ,
"description" : "The unique id to assign the second channel when using local channels." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "originator" ,
"description" : "Unique ID of the calling channel" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2016-05-27 13:49:42 -06:00
} ,
{
"name" : "formats" ,
"description" : "The format name capability list to use if originator is not specified. Ex. \"ulaw,slin16\". Format names can be found with \"core show codecs\"." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2020-05-12 20:15:41 -03:00
} ,
{
"name" : "variables" ,
"description" : "The \"variables\" key in the body object holds variable key/value pairs to set on the channel on creation. Other keys in the body object are interpreted as query parameters. Ex. { \"endpoint\": \"SIP/Alice\", \"variables\": { \"CALLERID(name)\": \"Alice\" } }" ,
"paramType" : "body" ,
"required" : false ,
"dataType" : "containers" ,
"allowMultiple" : false
2016-03-30 17:01:28 -05:00
}
2016-10-19 12:05:28 -05:00
] ,
"errorResponses" : [
{
"code" : 409 ,
"reason" : "Channel with given unique ID already exists."
}
2016-03-30 17:01:28 -05:00
]
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"path" : "/channels/{channelId}" ,
"description" : "Active channel" ,
"operations" : [
{
"httpMethod" : "GET" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Channel details." ,
2013-11-07 21:10:31 +00:00
"nickname" : "get" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "Channel" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
}
]
} ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.2.0"
] ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"summary" : "Create a new channel (originate with id)." ,
"notes" : "The new channel is created immediately and a snapshot of it returned. If a Stasis application is provided it will be automatically subscribed to the originated channel for further events and updates." ,
"nickname" : "originateWithId" ,
"responseClass" : "Channel" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "The unique id to assign the channel on creation." ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "endpoint" ,
"description" : "Endpoint to call." ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "extension" ,
2015-01-27 17:21:03 +00:00
"description" : "The extension to dial after the endpoint answers. Mutually exclusive with 'app'." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "context" ,
2015-01-27 17:21:03 +00:00
"description" : "The context to dial after the endpoint answers. If omitted, uses 'default'. Mutually exclusive with 'app'." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "priority" ,
2015-01-27 17:21:03 +00:00
"description" : "The priority to dial after the endpoint answers. If omitted, uses 1. Mutually exclusive with 'app'." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "long"
} ,
2015-01-07 18:54:06 +00:00
{
"name" : "label" ,
2015-01-27 17:21:03 +00:00
"description" : "The label to dial after the endpoint answers. Will supersede 'priority' if provided. Mutually exclusive with 'app'." ,
2015-01-07 18:54:06 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
{
"name" : "app" ,
2015-01-27 17:21:03 +00:00
"description" : "The application that is subscribed to the originated channel. When the channel is answered, it will be passed to this Stasis application. Mutually exclusive with 'context', 'extension', 'priority', and 'label'." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "appArgs" ,
2015-01-27 17:21:03 +00:00
"description" : "The application arguments to pass to the Stasis application provided by 'app'. Mutually exclusive with 'context', 'extension', 'priority', and 'label'." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "callerId" ,
"description" : "CallerID to use when dialing the endpoint or extension." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "timeout" ,
"description" : "Timeout (in seconds) before giving up dialing, or -1 for no timeout." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 30
} ,
{
"name" : "variables" ,
2014-07-03 16:14:39 +00:00
"description" : "The \"variables\" key in the body object holds variable key/value pairs to set on the channel on creation. Other keys in the body object are interpreted as query parameters. Ex. { \"endpoint\": \"SIP/Alice\", \"variables\": { \"CALLERID(name)\": \"Alice\" } }" ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "body" ,
"required" : false ,
"dataType" : "containers" ,
"allowMultiple" : false
} ,
{
"name" : "otherChannelId" ,
"description" : "The unique id to assign the second channel when using local channels." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2014-12-09 15:45:19 +00:00
} ,
{
"name" : "originator" ,
"description" : "The unique id of the channel which is originating this one." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2016-05-27 13:49:42 -06:00
} ,
{
"name" : "formats" ,
"description" : "The format name capability list to use if originator is not specified. Ex. \"ulaw,slin16\". Format names can be found with \"core show codecs\"." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Invalid parameters for originating a channel."
2016-10-17 14:18:57 -05:00
} ,
{
"code" : 409 ,
"reason" : "Channel with given unique ID already exists."
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Delete (i.e. hangup) a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "hangup" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
2013-11-01 14:38:21 +00:00
} ,
2019-04-16 01:26:46 +02:00
{
"name" : "reason_code" ,
2023-11-09 16:26:46 -05:00
"description" : "The reason code for hanging up the channel for detail use. Mutually exclusive with 'reason'. See detail hangup codes at here. https://docs.asterisk.org/Configuration/Miscellaneous/Hangup-Cause-Mappings/" ,
2019-04-16 01:26:46 +02:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
2013-11-01 14:38:21 +00:00
{
"name" : "reason" ,
2019-04-16 01:26:46 +02:00
"description" : "Reason for hanging up the channel for simple use. Mutually exclusive with 'reason_code'." ,
2013-11-01 14:38:21 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"normal" ,
"busy" ,
2015-02-09 03:12:16 +00:00
"congestion" ,
2016-08-31 12:33:28 +02:00
"no_answer" ,
2018-12-06 18:23:50 +01:00
"timeout" ,
"rejected" ,
"unallocated" ,
"normal_unspecified" ,
"number_incomplete" ,
"codec_mismatch" ,
"interworking" ,
"failure" ,
2016-08-31 12:33:28 +02:00
"answered_elsewhere"
2013-11-01 14:38:21 +00:00
]
}
2013-04-22 14:58:53 +00:00
}
] ,
"errorResponses" : [
2013-11-01 14:38:21 +00:00
{
"code" : 400 ,
"reason" : "Invalid reason for hangup provided"
} ,
2013-04-22 14:58:53 +00:00
{
"code" : 404 ,
"reason" : "Channel not found"
}
]
}
]
} ,
{
"path" : "/channels/{channelId}/continue" ,
"description" : "Exit application; continue execution in the dialplan" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Exit application; continue execution in the dialplan." ,
"nickname" : "continueInDialplan" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
2013-06-26 19:29:57 +00:00
} ,
{
"name" : "context" ,
"description" : "The context to continue to." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "extension" ,
"description" : "The extension to continue to." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "priority" ,
"description" : "The priority to continue to." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int"
2015-01-07 18:54:06 +00:00
} ,
{
"name" : "label" ,
"description" : "The label to continue to - will supersede 'priority' if both are provided." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2013-04-22 14:58:53 +00:00
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
}
]
} ,
2019-03-07 07:52:20 -06:00
{
"path" : "/channels/{channelId}/move" ,
"description" : "Move the channel from one Stasis application to another." ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"13.26.0" ,
"16.3.0"
] ,
2019-03-07 07:52:20 -06:00
"summary" : "Move the channel from one Stasis application to another." ,
"nickname" : "move" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "app" ,
"description" : "The channel will be passed to this Stasis application." ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "appArgs" ,
"description" : "The application arguments to pass to the Stasis application provided by 'app'." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : "404" ,
"reason" : "Channel not found"
} ,
{
"code" : "409" ,
"reason" : "Channel not in a Stasis application"
}
]
}
]
} ,
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
{
"path" : "/channels/{channelId}/redirect" ,
"description" : "Inform the channel that it should redirect itself to a different location. Note that this will almost certainly cause the channel to exit the application." ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"13.3.0"
] ,
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
"summary" : "Redirect the channel to a different location." ,
"nickname" : "redirect" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "endpoint" ,
"description" : "The endpoint to redirect the channel to" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Endpoint parameter not provided"
} ,
{
"code" : 404 ,
"reason" : "Channel or endpoint not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
} ,
{
"code" : 422 ,
"reason" : "Endpoint is not the same type as the channel"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-02-12 20:34:37 +00:00
}
]
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"path" : "/channels/{channelId}/answer" ,
"description" : "Answer a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Answer a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "answer" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
}
]
} ,
2013-11-01 14:38:21 +00:00
{
"path" : "/channels/{channelId}/ring" ,
"description" : "Send a ringing indication to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-01 14:38:21 +00:00
"summary" : "Indicate ringing to a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "ring" ,
2013-11-01 14:38:21 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-11-01 14:38:21 +00:00
}
]
2013-11-13 23:11:32 +00:00
} ,
{
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-13 23:11:32 +00:00
"summary" : "Stop ringing indication on a channel if locally generated." ,
"nickname" : "ringStop" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-11-13 23:11:32 +00:00
}
]
2013-11-01 14:38:21 +00:00
}
]
} ,
2025-07-30 14:24:07 +02:00
{
"path" : "/channels/{channelId}/progress" ,
"description" : "Indicate progress on a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
"since" : [
"22.6.0" ,
"21.11.0" ,
"20.16.0"
] ,
"summary" : "Indicate progress on a channel." ,
"nickname" : "progress" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
}
]
}
]
} ,
2013-11-01 14:38:21 +00:00
{
"path" : "/channels/{channelId}/dtmf" ,
"description" : "Send DTMF to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-01 14:38:21 +00:00
"summary" : "Send provided DTMF to a given channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "sendDTMF" ,
2013-11-01 14:38:21 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "dtmf" ,
"description" : "DTMF To send." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "before" ,
"description" : "Amount of time to wait before DTMF digits (specified in milliseconds) start." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 0
} ,
{
"name" : "between" ,
"description" : "Amount of time in between DTMF digits (specified in milliseconds)." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 100
} ,
{
"name" : "duration" ,
"description" : "Length of each DTMF digit (specified in milliseconds)." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 100
} ,
{
"name" : "after" ,
"description" : "Amount of time to wait after DTMF digits (specified in milliseconds) end." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 0
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "DTMF is required"
} ,
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-11-01 14:38:21 +00:00
}
]
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"path" : "/channels/{channelId}/mute" ,
"description" : "Mute a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Mute a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "mute" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "direction" ,
"description" : "Direction in which to mute audio" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "both" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"both" ,
"in" ,
"out"
]
}
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
2013-11-07 21:10:31 +00:00
} ,
2013-04-22 14:58:53 +00:00
{
2013-11-07 21:10:31 +00:00
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Unmute a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "unmute" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "direction" ,
"description" : "Direction in which to unmute audio" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "both" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"both" ,
"in" ,
"out"
]
}
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
}
]
} ,
{
"path" : "/channels/{channelId}/hold" ,
"description" : "Put a channel on hold" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Hold a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "hold" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
2013-11-07 21:10:31 +00:00
} ,
2013-04-22 14:58:53 +00:00
{
2013-10-15 15:30:39 +00:00
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Remove a channel from hold." ,
2013-11-07 21:10:31 +00:00
"nickname" : "unhold" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
}
]
} ,
2013-07-19 19:40:27 +00:00
{
2013-10-15 15:30:39 +00:00
"path" : "/channels/{channelId}/moh" ,
2013-07-19 19:40:27 +00:00
"description" : "Play music on hold to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-07-19 19:40:27 +00:00
"summary" : "Play music on hold to a channel." ,
2013-11-21 15:56:34 +00:00
"notes" : "Using media operations such as /play on a channel playing MOH in this manner will suspend MOH without resuming automatically. If continuing music on hold is desired, the stasis application must reinitiate music on hold." ,
2013-11-07 21:10:31 +00:00
"nickname" : "startMoh" ,
2013-07-19 19:40:27 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "mohClass" ,
"description" : "Music on hold class to use" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-07-19 19:40:27 +00:00
}
]
2013-11-07 21:10:31 +00:00
} ,
2013-07-19 19:40:27 +00:00
{
2013-10-15 15:30:39 +00:00
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-07-19 19:40:27 +00:00
"summary" : "Stop playing music on hold to a channel." ,
2013-11-07 21:10:31 +00:00
"nickname" : "stopMoh" ,
2013-07-19 19:40:27 +00:00
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-07-19 19:40:27 +00:00
}
]
}
]
} ,
2013-11-21 15:56:34 +00:00
{
"path" : "/channels/{channelId}/silence" ,
"description" : "Play silence to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-21 15:56:34 +00:00
"summary" : "Play silence to a channel." ,
"notes" : "Using media operations such as /play on a channel playing silence in this manner will suspend silence without resuming automatically." ,
"nickname" : "startSilence" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-11-21 15:56:34 +00:00
}
]
} ,
{
"httpMethod" : "DELETE" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-21 15:56:34 +00:00
"summary" : "Stop playing silence to a channel." ,
"nickname" : "stopSilence" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-11-21 15:56:34 +00:00
}
]
}
]
} ,
2013-04-22 14:58:53 +00:00
{
"path" : "/channels/{channelId}/play" ,
"description" : "Play media to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Start playback of media." ,
2014-04-17 21:57:36 +00:00
"notes" : "The media URI may be any of a number of URI's. Currently sound:, recording:, number:, digits:, characters:, and tone: URI's are supported. This operation creates a playback resource that can be used to control the playback of media (pause, rewind, fast forward, etc.)" ,
2013-11-07 21:10:31 +00:00
"nickname" : "play" ,
2013-04-22 14:58:53 +00:00
"responseClass" : "Playback" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "media" ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"description" : "Media URIs to play." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : true ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"allowMultiple" : true ,
2013-04-22 14:58:53 +00:00
"dataType" : "string"
2013-05-23 20:11:35 +00:00
} ,
{
"name" : "lang" ,
2013-05-23 20:21:16 +00:00
"description" : "For sounds, selects language for sound." ,
2013-05-23 20:11:35 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2013-05-23 20:21:16 +00:00
} ,
{
"name" : "offsetms" ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"description" : "Number of milliseconds to skip before playing. Only applies to the first URI if multiple media URIs are specified." ,
2013-05-23 20:21:16 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int"
} ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
{
"name" : "skipms" ,
"description" : "Number of milliseconds to skip for forward/reverse operations." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 3000
} ,
{
"name" : "playbackId" ,
"description" : "Playback ID." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
}
]
}
]
} ,
{
"path" : "/channels/{channelId}/play/{playbackId}" ,
"description" : "Play media to a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.2.0"
] ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"summary" : "Start playback of media and specify the playbackId." ,
2015-01-27 17:21:03 +00:00
"notes" : "The media URI may be any of a number of URI's. Currently sound:, recording:, number:, digits:, characters:, and tone: URI's are supported. This operation creates a playback resource that can be used to control the playback of media (pause, rewind, fast forward, etc.)" ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"nickname" : "playWithId" ,
"responseClass" : "Playback" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "playbackId" ,
"description" : "Playback ID." ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "media" ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"description" : "Media URIs to play." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : true ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"allowMultiple" : true ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"dataType" : "string"
} ,
{
"name" : "lang" ,
"description" : "For sounds, selects language for sound." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "offsetms" ,
ARI: Add the ability to play multiple media URIs in a single operation
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
2016-04-18 18:17:08 -05:00
"description" : "Number of milliseconds to skip before playing. Only applies to the first URI if multiple media URIs are specified." ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int"
} ,
2013-05-23 20:21:16 +00:00
{
"name" : "skipms" ,
"description" : "Number of milliseconds to skip for forward/reverse operations." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 3000
2013-04-22 14:58:53 +00:00
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
2016-06-01 13:48:00 -05:00
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
2013-04-22 14:58:53 +00:00
}
]
}
]
} ,
{
"path" : "/channels/{channelId}/record" ,
"description" : "Record audio from a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-04-22 14:58:53 +00:00
"summary" : "Start a recording." ,
"notes" : "Record audio from a channel. Note that this will not capture audio sent to the channel. The bridge itself has a record feature if that's what you want." ,
2013-11-07 21:10:31 +00:00
"nickname" : "record" ,
2013-07-19 19:35:21 +00:00
"responseClass" : "LiveRecording" ,
2013-04-22 14:58:53 +00:00
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "name" ,
"description" : "Recording's filename" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "format" ,
"description" : "Format to encode audio in" ,
"paramType" : "query" ,
"required" : true ,
2013-08-02 14:36:32 +00:00
"allowMultiple" : false ,
2013-04-22 14:58:53 +00:00
"dataType" : "string"
} ,
{
"name" : "maxDurationSeconds" ,
"description" : "Maximum duration of the recording, in seconds. 0 for no limit" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
2013-07-03 17:58:45 +00:00
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
2013-04-22 14:58:53 +00:00
} ,
{
"name" : "maxSilenceSeconds" ,
"description" : "Maximum duration of silence, in seconds. 0 for no limit" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
2013-07-03 17:58:45 +00:00
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
2013-04-22 14:58:53 +00:00
} ,
{
2013-07-03 17:58:45 +00:00
"name" : "ifExists" ,
"description" : "Action to take if a recording with the same name already exists." ,
2013-04-22 14:58:53 +00:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
2013-07-03 17:58:45 +00:00
"dataType" : "string" ,
"defaultValue" : "fail" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"fail" ,
"overwrite" ,
"append"
]
}
2013-04-22 14:58:53 +00:00
} ,
{
"name" : "beep" ,
"description" : "Play beep when recording begins" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "boolean" ,
"defaultValue" : false
} ,
{
"name" : "terminateOn" ,
"description" : "DTMF input to terminate recording" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"any" ,
"*" ,
"#"
]
}
}
] ,
"errorResponses" : [
2013-07-03 17:58:45 +00:00
{
"code" : 400 ,
"reason" : "Invalid parameters"
} ,
2013-04-22 14:58:53 +00:00
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
2025-04-28 10:39:50 -06:00
"reason" : "Channel is not in a Stasis application; the channel is currently bridged with other channels; A recording with the same name already exists on the system and can not be overwritten because it is in progress or ifExists=fail"
2013-10-25 22:01:43 +00:00
} ,
{
"code" : 422 ,
"reason" : "The format specified is unknown on this system"
2013-04-22 14:58:53 +00:00
}
]
}
]
2013-07-08 14:46:20 +00:00
} ,
{
"path" : "/channels/{channelId}/variable" ,
"description" : "Variables on a channel" ,
"operations" : [
{
"httpMethod" : "GET" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-07-08 14:46:20 +00:00
"summary" : "Get the value of a channel variable or function." ,
"nickname" : "getChannelVar" ,
2013-07-10 13:50:48 +00:00
"responseClass" : "Variable" ,
2013-07-08 14:46:20 +00:00
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "variable" ,
"description" : "The channel variable or function to get" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
2013-08-21 16:23:59 +00:00
{
"code" : 400 ,
"reason" : "Missing variable parameter."
} ,
2013-07-08 14:46:20 +00:00
{
"code" : 404 ,
2015-02-21 20:48:17 +00:00
"reason" : "Channel or variable not found"
2013-07-08 14:46:20 +00:00
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
}
]
} ,
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-07-08 14:46:20 +00:00
"summary" : "Set the value of a channel variable or function." ,
"nickname" : "setChannelVar" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "variable" ,
"description" : "The channel variable or function to set" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "value" ,
"description" : "The value to set the variable to" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
2013-08-21 16:23:59 +00:00
{
"code" : 400 ,
"reason" : "Missing variable parameter."
} ,
2013-07-08 14:46:20 +00:00
{
"code" : 404 ,
"reason" : "Channel not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
}
]
}
]
2013-11-23 12:40:46 +00:00
} ,
{
"path" : "/channels/{channelId}/snoop" ,
"description" : "Snoop (spy/whisper) on a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.0.0"
] ,
2013-11-23 12:40:46 +00:00
"summary" : "Start snooping." ,
"notes" : "Snoop (spy/whisper) on a specific channel." ,
"nickname" : "snoopChannel" ,
"responseClass" : "Channel" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "spy" ,
"description" : "Direction of audio to spy on" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"both" ,
"out" ,
"in"
]
}
} ,
{
"name" : "whisper" ,
"description" : "Direction of audio to whisper into" ,
"paramType" : "query" ,
"required" : false ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"both" ,
"out" ,
"in"
]
}
} ,
{
"name" : "app" ,
"description" : "Application the snooping channel is placed into" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "appArgs" ,
"description" : "The application arguments to pass to the Stasis application" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "snoopId" ,
"description" : "Unique ID to assign to snooping channel" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Invalid parameters"
} ,
{
"code" : 404 ,
"reason" : "Channel not found"
}
]
}
]
} ,
{
"path" : "/channels/{channelId}/snoop/{snoopId}" ,
"description" : "Snoop (spy/whisper) on a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"12.2.0"
] ,
uniqueid: channel linkedid, ami, ari object creation with id's
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07 15:47:55 +00:00
"summary" : "Start snooping." ,
"notes" : "Snoop (spy/whisper) on a specific channel." ,
"nickname" : "snoopChannelWithId" ,
"responseClass" : "Channel" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "snoopId" ,
"description" : "Unique ID to assign to snooping channel" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "spy" ,
"description" : "Direction of audio to spy on" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"both" ,
"out" ,
"in"
]
}
} ,
{
"name" : "whisper" ,
"description" : "Direction of audio to whisper into" ,
"paramType" : "query" ,
"required" : false ,
2013-11-23 12:40:46 +00:00
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "none" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"none" ,
"both" ,
"out" ,
"in"
]
}
} ,
{
"name" : "app" ,
"description" : "Application the snooping channel is placed into" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "appArgs" ,
"description" : "The application arguments to pass to the Stasis application" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Invalid parameters"
} ,
{
"code" : 404 ,
"reason" : "Channel not found"
}
]
}
]
2016-03-30 17:18:39 -05:00
} ,
{
"path" : "/channels/{channelId}/dial" ,
"description" : "Dial a channel" ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"14.0.0"
] ,
2016-03-30 17:18:39 -05:00
"summary" : "Dial a created channel." ,
"nickname" : "dial" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "caller" ,
"description" : "Channel ID of caller" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "timeout" ,
"description" : "Dial timeout" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "int" ,
"defaultValue" : 0 ,
"allowableValues" : {
"valueType" : "RANGE" ,
"min" : 0
}
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel cannot be found."
} ,
{
"code" : 409 ,
"reason" : "Channel cannot be dialed."
}
]
}
]
2019-03-02 12:37:21 +01:00
} ,
{
"path" : "/channels/{channelId}/rtp_statistics" ,
"description" : "Get RTP statistics information for RTP on a channel" ,
"operations" : [
{
"httpMethod" : "GET" ,
2025-01-27 08:30:40 -07:00
"since" : [
"13.27.0" ,
"16.4.0"
] ,
2019-03-02 12:37:21 +01:00
"summary" : "RTP stats on a channel." ,
"nickname" : "rtpstatistics" ,
"responseClass" : "RTPstat" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 404 ,
"reason" : "Channel cannot be found."
}
]
}
]
2019-08-05 05:59:59 -06:00
} ,
{
"path" : "/channels/externalMedia" ,
"description" : "Create a channel to an External Media source/sink." ,
"operations" : [
{
"httpMethod" : "POST" ,
2025-01-27 08:30:40 -07:00
"since" : [
"16.6.0" ,
"17.1.0"
] ,
2019-08-05 05:59:59 -06:00
"summary" : "Start an External Media session." ,
2025-04-28 10:39:50 -06:00
"notes" : "Create a channel to an External Media source/sink. The combination of transport and encapsulation will select one of chan_rtp(udp/rtp), chan_audiosocket(tcp/audiosocket) or chan_websocket(websocket/none) channel drivers." ,
2019-08-05 05:59:59 -06:00
"nickname" : "externalMedia" ,
2019-10-18 05:36:12 -06:00
"responseClass" : "Channel" ,
2019-08-05 05:59:59 -06:00
"parameters" : [
{
"name" : "channelId" ,
"description" : "The unique id to assign the channel on creation." ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "app" ,
"description" : "Stasis Application to place channel into" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "variables" ,
"description" : "The \"variables\" key in the body object holds variable key/value pairs to set on the channel on creation. Other keys in the body object are interpreted as query parameters. Ex. { \"endpoint\": \"SIP/Alice\", \"variables\": { \"CALLERID(name)\": \"Alice\" } }" ,
"paramType" : "body" ,
"required" : false ,
"dataType" : "containers" ,
"allowMultiple" : false
} ,
{
"name" : "external_host" ,
2025-04-28 10:39:50 -06:00
"description" : "Hostname/ip:port or websocket_client connection ID of external host. May be empty for a websocket server connection." ,
2019-08-05 05:59:59 -06:00
"paramType" : "query" ,
2025-04-28 10:39:50 -06:00
"required" : false ,
2019-08-05 05:59:59 -06:00
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "encapsulation" ,
2025-04-28 10:39:50 -06:00
"description" : "Payload encapsulation protocol. Must be 'none' for the websocket transport." ,
2019-08-05 05:59:59 -06:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "rtp" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
2019-07-17 20:47:50 -04:00
"rtp" ,
2025-04-28 10:39:50 -06:00
"audiosocket" ,
"none"
2019-08-05 05:59:59 -06:00
]
}
} ,
{
"name" : "transport" ,
"description" : "Transport protocol" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "udp" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
2019-07-17 20:47:50 -04:00
"udp" ,
2025-04-28 10:39:50 -06:00
"tcp" ,
"websocket"
2019-08-05 05:59:59 -06:00
]
}
} ,
{
"name" : "connection_type" ,
2025-04-28 10:39:50 -06:00
"description" : "Connection type (client/server). 'server' is only valid for the websocket transport." ,
2019-08-05 05:59:59 -06:00
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "client" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
2025-04-28 10:39:50 -06:00
"client" ,
"server"
2019-08-05 05:59:59 -06:00
]
}
} ,
{
"name" : "format" ,
"description" : "Format to encode audio in" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "direction" ,
"description" : "External media direction" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string" ,
"defaultValue" : "both" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"both"
]
}
2019-07-17 20:47:50 -04:00
} ,
{
"name" : "data" ,
"description" : "An arbitrary data field" ,
"paramType" : "query" ,
"required" : false ,
"allowMultiple" : false ,
"dataType" : "string"
2019-08-05 05:59:59 -06:00
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Invalid parameters"
} ,
{
"code" : 409 ,
"reason" : "Channel is not in a Stasis application; Channel is already bridged"
}
]
}
]
2024-06-15 16:01:58 +08:00
} ,
{
"path" : "/channels/{channelId}/transfer_progress" ,
"description" : "Inform the channel that the transfer is in progress." ,
"operations" : [
{
"httpMethod" : "POST" ,
"since" : [
"22.3.0" ,
"21.8.0" ,
"20.13.0"
] ,
"summary" : "Inform the channel about the progress of the attended/blind transfer." ,
"nickname" : "transfer_progress" ,
"responseClass" : "void" ,
"parameters" : [
{
"name" : "channelId" ,
"description" : "Channel's id" ,
"paramType" : "path" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
} ,
{
"name" : "states" ,
"description" : "The state of the progress" ,
"paramType" : "query" ,
"required" : true ,
"allowMultiple" : false ,
"dataType" : "string"
}
] ,
"errorResponses" : [
{
"code" : 400 ,
"reason" : "Endpoint parameter not provided"
} ,
{
"code" : 404 ,
"reason" : "Channel or endpoint not found"
} ,
{
"code" : 409 ,
"reason" : "Channel not in a Stasis application"
} ,
{
"code" : 412 ,
"reason" : "Channel in invalid state"
}
]
}
]
2013-04-22 14:58:53 +00:00
}
] ,
"models" : {
"Dialed" : {
"id" : "Dialed" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "Dialed channel information." ,
2013-04-22 14:58:53 +00:00
"properties" : { }
} ,
"DialplanCEP" : {
"id" : "DialplanCEP" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "Dialplan location (context/extension/priority)" ,
2013-04-22 14:58:53 +00:00
"properties" : {
"context" : {
"required" : true ,
"type" : "string" ,
"description" : "Context in the dialplan"
} ,
"exten" : {
"required" : true ,
"type" : "string" ,
"description" : "Extension in the dialplan"
} ,
"priority" : {
"required" : true ,
"type" : "long" ,
"description" : "Priority in the dialplan"
2019-03-22 00:09:14 +01:00
} ,
"app_name" : {
"required" : true ,
"type" : "string" ,
"description" : "Name of current dialplan application"
} ,
"app_data" : {
"required" : true ,
"type" : "string" ,
"description" : "Parameter of current dialplan application"
2013-04-22 14:58:53 +00:00
}
}
} ,
"CallerID" : {
"id" : "CallerID" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "Caller identification" ,
2013-04-22 14:58:53 +00:00
"properties" : {
"name" : {
"required" : true ,
"type" : "string"
} ,
"number" : {
"required" : true ,
"type" : "string"
}
}
} ,
2019-03-02 12:37:21 +01:00
"RTPstat" : {
"id" : "RTPstat" ,
"description" : "A statistics of a RTP." ,
"properties" : {
"txcount" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of packets transmitted."
} ,
"rxcount" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of packets received."
} ,
"txjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Jitter on transmitted packets."
} ,
"rxjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Jitter on received packets."
} ,
"remote_maxjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Maximum jitter on remote side."
} ,
"remote_minjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Minimum jitter on remote side."
} ,
"remote_normdevjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Average jitter on remote side."
} ,
"remote_stdevjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Standard deviation jitter on remote side."
} ,
"local_maxjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Maximum jitter on local side."
} ,
"local_minjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Minimum jitter on local side."
} ,
"local_normdevjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Average jitter on local side."
} ,
"local_stdevjitter" : {
"required" : false ,
"type" : "double" ,
"description" : "Standard deviation jitter on local side."
} ,
"txploss" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of transmitted packets lost."
} ,
"rxploss" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of received packets lost."
} ,
"remote_maxrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Maximum number of packets lost on remote side."
} ,
"remote_minrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Minimum number of packets lost on remote side."
} ,
"remote_normdevrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Average number of packets lost on remote side."
} ,
"remote_stdevrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Standard deviation packets lost on remote side."
} ,
"local_maxrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Maximum number of packets lost on local side."
} ,
"local_minrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Minimum number of packets lost on local side."
} ,
"local_normdevrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Average number of packets lost on local side."
} ,
"local_stdevrxploss" : {
"required" : false ,
"type" : "double" ,
"description" : "Standard deviation packets lost on local side."
} ,
"rtt" : {
"required" : false ,
"type" : "double" ,
"description" : "Total round trip time."
} ,
"maxrtt" : {
"required" : false ,
"type" : "double" ,
"description" : "Maximum round trip time."
} ,
"minrtt" : {
"required" : false ,
"type" : "double" ,
"description" : "Minimum round trip time."
} ,
"normdevrtt" : {
"required" : false ,
"type" : "double" ,
"description" : "Average round trip time."
} ,
"stdevrtt" : {
"required" : false ,
"type" : "double" ,
"description" : "Standard deviation round trip time."
} ,
"local_ssrc" : {
"required" : true ,
"type" : "int" ,
"description" : "Our SSRC."
} ,
"remote_ssrc" : {
"required" : true ,
"type" : "int" ,
"description" : "Their SSRC."
} ,
"txoctetcount" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of octets transmitted."
} ,
"rxoctetcount" : {
"required" : true ,
"type" : "int" ,
"description" : "Number of octets received."
} ,
"channel_uniqueid" : {
"required" : true ,
"type" : "string" ,
"description" : "The Asterisk channel's unique ID that owns this instance."
}
}
} ,
2013-04-22 14:58:53 +00:00
"Channel" : {
"id" : "Channel" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "A specific communication connection between Asterisk and an Endpoint." ,
2013-04-22 14:58:53 +00:00
"properties" : {
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"id" : {
2013-04-22 14:58:53 +00:00
"required" : true ,
"type" : "string" ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"description" : "Unique identifier of the channel.\n\nThis is the same as the Uniqueid field in AMI."
2013-04-22 14:58:53 +00:00
} ,
2022-04-26 00:40:49 +02:00
"protocol_id" : {
"required" : true ,
"type" : "string" ,
2022-11-28 13:05:21 -07:00
"description" : "Protocol id from underlying channel driver (i.e. Call-ID for chan_pjsip; will be empty if not applicable or not implemented by driver)."
2022-04-26 00:40:49 +02:00
} ,
2013-04-22 14:58:53 +00:00
"name" : {
"required" : true ,
"type" : "string" ,
"description" : "Name of the channel (i.e. SIP/foo-0000a7e3)"
} ,
"state" : {
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"type" : "string" ,
"allowableValues" : {
"valueType" : "LIST" ,
"values" : [
"Down" ,
"Rsrved" ,
"OffHook" ,
"Dialing" ,
"Ring" ,
"Ringing" ,
"Up" ,
"Busy" ,
"Dialing Offhook" ,
"Pre-ring" ,
"Unknown"
]
}
2013-04-22 14:58:53 +00:00
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"caller" : {
2013-04-22 14:58:53 +00:00
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"type" : "CallerID"
2013-04-22 14:58:53 +00:00
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"connected" : {
2013-04-22 14:58:53 +00:00
"required" : true ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"type" : "CallerID"
2013-04-22 14:58:53 +00:00
} ,
Update events to use Swagger 1.3 subtyping, and related aftermath
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-03 16:32:41 +00:00
"accountcode" : {
2013-04-22 14:58:53 +00:00
"required" : true ,
"type" : "string"
} ,
"dialplan" : {
"required" : true ,
"type" : "DialplanCEP" ,
"description" : "Current location in the dialplan"
} ,
"creationtime" : {
"required" : true ,
"type" : "Date" ,
"description" : "Timestamp when channel was created"
2014-12-09 20:20:27 +00:00
} ,
"language" : {
"required" : true ,
"type" : "string" ,
"description" : "The default spoken language"
2016-11-11 11:45:37 -05:00
} ,
"channelvars" : {
"required" : false ,
"type" : "object" ,
"description" : "Channel variables"
2023-10-14 15:48:10 +08:00
} ,
"caller_rdnis" : {
"type" : "string" ,
"description" : "The Caller ID RDNIS"
channel: Add multi-tenant identifier.
This patch introduces a new identifier for channels: tenantid. It's
a stringfield on the channel that can be used for general purposes. It
will be inherited by other channels the same way that linkedid is.
You can set tenantid in a few ways. The first is to set it in the
dialplan with the Set and CHANNEL functions:
exten => example,1,Set(CHANNEL(tenantid)=My tenant ID)
It can also be accessed via CHANNEL:
exten => example,2,NoOp(CHANNEL(tenantid))
Another method is to use the new tenantid option for pjsip endpoints in
pjsip.conf:
[my_endpoint]
type=endpoint
tenantid=My tenant ID
This is considered the best approach since you will be able to see the
tenant ID as early as the Newchannel event.
It can also be set using set_var in pjsip.conf on the endpoint like
setting other channel variable:
set_var=CHANNEL(tenantid)=My tenant ID
Note that set_var will not show tenant ID on the Newchannel event,
however.
Tenant ID has also been added to CDR. It's read-only and can be accessed
via CDR(tenantid). You can also get the tenant ID of the last channel
communicated with via CDR(peertenantid).
Tenant ID will also show up in CEL records if it has been set, and the
version number has been bumped accordingly.
Fixes: #740
UserNote: tenantid has been added to channels. It can be read in
dialplan via CHANNEL(tenantid), and it can be set using
Set(CHANNEL(tenantid)=My tenant ID). In pjsip.conf, it is recommended to
use the new tenantid option for pjsip endpoints (e.g., tenantid=My
tenant ID) so that it will show up in Newchannel events. You can set it
like any other channel variable using set_var in pjsip.conf as well, but
note that this will NOT show up in Newchannel events. Tenant ID is also
available in CDR and can be accessed with CDR(tenantid). The peer tenant
ID can also be accessed with CDR(peertenantid). CEL includes tenant ID
as well if it has been set.
UpgradeNote: A new versioned struct (ast_channel_initializers) has been
added that gets passed to __ast_channel_alloc_ap. The new function
ast_channel_alloc_with_initializers should be used when creating
channels that require the use of this struct. Currently the only value
in the struct is for tenantid, but now more fields can be added to the
struct as necessary rather than the __ast_channel_alloc_ap function. A
new option (tenantid) has been added to endpoints in pjsip.conf as well.
CEL has had its version bumped to include tenant ID.
2024-05-21 11:11:26 -05:00
} ,
"tenantid" : {
"required" : false ,
"type" : "string" ,
"description" : "The Tenant ID for the channel"
2013-04-22 14:58:53 +00:00
}
}
}
}
}
