Curiouser and curiouser with Asterisk manager interface (pyst doesn't seem to realise that there are event-generating queries)


Can't sleep, so spending more time with the manager interface. Interestingly, it seems that pyst has a fairly low-level assumption that just doesn't match the manager interface: namely that all events should be dispatched asynchronously to registered handlers. The problem is that certain actions produce a response, then a sequence of events in order that are only referenceable because they immediately follow the response and precede a closing event.

That is, to handle these types of action-responses the code should look like this: readResponse() readStatusUntilStatusFinished(). Without binding the two together you can't, for instance, watch for the closing of the particular channel you just opened, as you have no way of knowing if a particular opening channel is the one you created, or one that someone else created.

Of course, I might be misreading the section in the wiki where it says there are two contexts in which events occur, or missing something in pyst for handling the second case... it is late after all.

[Even later] Okay, it looks like the API is such that to handle this you need to look up the generating command and see if it expects follow-on events. In looking into fixing that it seems that there's nothing in the pyst code that handles multiplexing/demultiplexing queries (i.e. it only ever has one query in-play at a time that I can see). Maybe it is time to try another interface as others have suggested.

[Even later still (6am)] I'm obviously missing something. I've created a sub-class that uses callbacks and events to multiplex the queries, but somehow the mirage of data-filling events have shimmered out of existence. Obviously need to give my brain a rest, since it's not producing anything functional at the moment.

Comments

  1. Jayson Vantuyl

    Jayson Vantuyl on 01/20/2006 3:37 p.m. #


    You might try ActionID. A long time ago, I implemented this feature and got it patched in.<br />
    <br />
    Basically, if you make a request with an ActionID header, it gives back responses generated from that request with the same ActionID and also generates any end event (some requests generate one) with the same id.<br />
    <br />
    Unfortunately, I could never get everyone to implement it and eventually gave up fixing everyone else's code. Unless someone else started caring, don't expect it to work everywhere.<br />
    <br />
    FWIW, if you read the manager documentation, it had specifications for the commands. Many support the ActionID. Many don't. I've not used pyst, so this may all not be so useful, but generally I created ActionID to help with multiplexing events like this.

  2. Mike Fletcher

    Mike Fletcher on 01/20/2006 5:38 p.m. #


    Actually, pyst uses ActionID for just about everything. The problem is that the return message (the only thing that has the ActionID specified) doesn't include identifying information about the created channel. The result is that there's nothing tying the channel to the creation request but timing and hoping that there's no other channel created.

  3. Todd Goldfinger

    Todd Goldfinger on 04/23/2006 3:59 p.m. #


    I've been trying to understand the AMI for a while now. From the wiki, it claims you can only have one action outstanding at a time. I took that to mean, you can't send another until you get a response. But this would seem to make actionid useless because you would always know that the following response matches the previous action. Also, certain actions, such as monitor, take a while before responding, and you have to send another action to stop it.<br />
    <br />
    Perhaps it means you can't send multiple actions in a single packet. Can I originate a call or execute some other command over the same AMI login while monitoring?<br />
    <br />
    This blog is about all I could find on this issue. If anyone fully understands, I'd like to hear about it. Thanks!

  4. Dr Clue

    Dr Clue on 07/13/2010 8:47 p.m. #

    I've always been fascinated with the Asterisk AMI interface. So much so that I married that
    fascination with the new HTML5 WebSockets.

    So now I have a little middleware I call "AsterClick" that I've written as open source
    code.

    The middleware communicates with the browser over a persistent WebSockets connection using XML. The middleware parses the XML into AMI commands, and whenever AMI decides to emit events , they are packaged up as XML and sent to
    the browser through the persistent WebSocket
    associated with the particular web browser
    instance that sent the original command or
    to all connected browsers if AMI dreamed up the
    event itself.

    Thus far I don't seem to have a problem sending
    commands one after the other and getting back
    the events whenever they show up.

    On the browser side I made a simple little javascript class that manages the WebSocket,
    decodes the responses and even has addEventListener()/removeEventListener() methods
    that takes AMI events as arguments.

    It's still a project in the development phase,
    but it does work and I've created both .deb and .rpm installation packages for it.

    AMI is just plain cool, and worth the time to figure out.

Comments are closed.

Pingbacks

Pingbacks are closed.