Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis
applications were registered. This was done such that the WebSocket would be
ready when an application is registered. However, by creating the WebSocket
first, the client had the ability to make requests for the Stasis application
it thought had been created with the initial handshake request. The inevitable
conclusion of this scenario was the cart being put before the horse.
ASTERISK-24988 resolved half of the problem by ensuring that the applications
were created and registered with Stasis prior to completing the handshake
with the client. While this meant that Stasis was ready when the client
received the green-light from Asterisk, it also meant that the WebSocket was
not yet ready for Stasis to dispatch messages.
This patch introduces a message queuing mechanism for delaying messages from
Stasis applications while the WebSocket is being constructed. When the ARI
event processor receives the message from the WebSocket that it is being
created, the event processor instantiates an event session which contains a
message queue. It then tries to create and register the requested applications
with Stasis. Messages that are dispatched from Stasis between this point and
the point at which the event processor is notified the WebSocket is ready, are
stashed in the queue. Once the WebSocket has been built, the queue's messages
are dispatched in the order in which they were originally received and the
queue is concurrently cleared.
ASTERISK-25181 #close
Reported By: Matt Jordan
Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17
Prior to this patch, when a WebSocket connection is made, ARI would not
be informed of the connection until after the WebSocket layer had
accepted the connection. This created a brief race condition where the
ARI client would be notified that it was connected, a channel would be
sent into the Stasis dialplan application, but ARI would not yet have
registered the Stasis application presented in the HTTP request that
established the WebSocket.
This patch resolves this issue by doing the following:
* When a WebSocket attempt is made, a callback is made into the ARI
application layer, which verifies and registers the apps presented in
the HTTP request. Because we do not yet have a WebSocket, we cannot
have an event session for the corresponding applications. Some
defensive checks were thus added to make the application objects
tolerant to a NULL event session.
* When a WebSocket connection is made, the registered application is
updated with the newly created event session that wraps the WebSocket
connection.
ASTERISK-24988 #close
Reported by: Joshua Colp
Change-Id: Ia5dc60dc2b6bee76cd5aff0f69dd53b36e83f636
This adds back in support for specifying channel variables during an
originate without compromising the ability to specify query parameters
in the JSON body. This was accomplished by generating the body-parsing
code in a separate function instead of being integrated with the URI
query parameter parsing code such that it could be called by paths with
body parameters. This is transparent to the user of the API and
prevents manual duplication of code or data structures.
(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3122/
Reported by: Matt Jordan
........
Merged revisions 406003 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While working on building client libraries from the Swagger API, I
noticed a problem with the nicknames.
channel.deleteChannel()
channel.answerChannel()
channel.muteChannel()
Etc. We put the object name in the nickname (since we were generating C
code), but it makes OO generators redundant.
This patch makes the nicknames more OO friendly. This resulted in a lot
of name changing within the res_ari_*.so modules, but not much else.
There were a couple of other fixed I made in the process.
* When reversible operations (POST /hold, POST /unhold) were made more
RESTful (POST /hold, DELETE /unhold), the path for the second operation
was left in the API declaration. This worked, but really the two
operations should have been on the same API.
* The POST /unmute operation had still not been REST-ified.
Review: https://reviewboard.asterisk.org/r/2940/
........
Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Swagger allows parameters to be specified as 'allowMultiple', meaning
that the parameter may be specified as a comma separated list of
values.
I had written some of the API docs using that, but promptly forgot
about implementing it. This patch finally fills in that gap.
The codegen template was updated to represent 'allowMultiple' fields
as array/size fields in the _args structs. It also parses the comma
separated list using ast_app_separate_args(), so quoted strings in the
argument will be handled properly.
Review: https://reviewboard.asterisk.org/r/2698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This renames all files and API calls from several variants of
Stasis-HTTP to ARI including:
* Stasis-HTTP -> ARI
* STASIS_HTTP -> ARI
* stasis_http -> ari (ast_ari for global symbols, file names as well)
* stasis http -> ARI
Review: https://reviewboard.asterisk.org/r/2706/
(closes issue ASTERISK-22136)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Ashley Sanders
Matt Jordan
Jonathan Rose
Kinsey Moore
David M. Lee