[asterisk-bugs] [JIRA] (ASTERISK-21969) Odd events during Stasis origination

Matt Jordan (JIRA) noreply at issues.asterisk.org
Mon Jul 1 11:57:08 CDT 2013


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

Matt Jordan updated ASTERISK-21969:
-----------------------------------

    Status: Open  (was: Triage)
    
> Odd events during Stasis origination
> ------------------------------------
>
>                 Key: ASTERISK-21969
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21969
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Core/Stasis, Resources/res_stasis_http
>    Affects Versions: 12
>            Reporter: Matt Jordan
>              Labels: Asterisk12
>
> Originating a channel from Stasis to an endpoint results in the following messages:
> {noformat}
> {
>   "application": "hello",
>   "stasis_start": {
>     "args": [],
>     "channel": {
>       "accountcode": "",
>       "appl": "Stasis",
>       "caller": {
>         "name": "",
>         "number": ""
>       },
>       "connected": {
>         "name": "",
>         "number": ""
>       },
>       "creationtime": "2013-06-27T14:18:42.908-0500",
>       "data": "hello",
>       "dialplan": {
>         "context": "demos",
>         "exten": "s",
>         "priority": 1
>       },
>       "hangupsource": "",
>       "linkedid": "1372360722.16",
>       "name": "Gulp/1000-00000008",
>       "parkinglot": "",
>       "peeraccount": "",
>       "state": "Up",
>       "uniqueid": "1372360722.16",
>       "userfield": ""
>     }
>   }
> }
> {noformat}
> Okay, that's useful, we entered into the application.
> {noformat}
> {
>   "application": "hello",
>   "channel_snapshot": {
>     "channel": {
>       "accountcode": "",
>       "appl": "AppDial2",
>       "caller": {
>         "name": "",
>         "number": ""
>       },
>       "connected": {
>         "name": "",
>         "number": ""
>       },
>       "creationtime": "2013-06-27T14:18:42.908-0500",
>       "data": "(Outgoing Line)",
>       "dialplan": {
>         "context": "demos",
>         "exten": "s",
>         "priority": 1
>       },
>       "hangupsource": "",
>       "linkedid": "1372360722.16",
>       "name": "Gulp/1000-00000008",
>       "parkinglot": "",
>       "peeraccount": "",
>       "state": "Up",
>       "uniqueid": "1372360722.16",
>       "userfield": ""
>     }
>   }
> }
> {noformat}
> Well, that's weird, we now just blew away the dialplan application "Stasis" and replaced it with "AppDial2".
> This is really the effect of something the dial API does - it creates a "dummy" application for originated channels. Unfortunately, this "dummy" application has no context and no meaning for us, particularly since it occurs after the {{stasis_start}} event.
> We either shouldn't raise the {{stasis_start}} until after this event is received by ARI (which means this event would never be sent out), or we should explicitly kill "AppDial" changes.
> {noformat}
> {
>   "application": "hello",
>   "channel_state_change": {
>     "channel": {
>       "accountcode": "",
>       "appl": "AppDial2",
>       "caller": {
>         "name": "",
>         "number": ""
>       },
>       "connected": {
>         "name": "",
>         "number": ""
>       },
>       "creationtime": "2013-06-27T14:18:42.908-0500",
>       "data": "(Outgoing Line)",
>       "dialplan": {
>         "context": "demos",
>         "exten": "s",
>         "priority": 1
>       },
>       "hangupsource": "",
>       "linkedid": "1372360722.16",
>       "name": "Gulp/1000-00000008",
>       "parkinglot": "",
>       "peeraccount": "",
>       "state": "Up",
>       "uniqueid": "1372360722.16",
>       "userfield": ""
>     }
>   }
> }
> {noformat}
> This is also odd. We just raised {{channel_state_change}} message and the channel state didn't change.
> {noformat}
> {
>   "application": "hello",
>   "channel_snapshot": {
>     "channel": {
>       "accountcode": "",
>       "appl": "Stasis",
>       "caller": {
>         "name": "",
>         "number": ""
>       },
>       "connected": {
>         "name": "",
>         "number": ""
>       },
>       "creationtime": "2013-06-27T14:18:42.908-0500",
>       "data": "hello",
>       "dialplan": {
>         "context": "demos",
>         "exten": "s",
>         "priority": 1
>       },
>       "hangupsource": "",
>       "linkedid": "1372360722.16",
>       "name": "Gulp/1000-00000008",
>       "parkinglot": "",
>       "peeraccount": "",
>       "state": "Up",
>       "uniqueid": "1372360722.16",
>       "userfield": ""
>     }
>   }
> }
> {noformat}
> And now we've reverted the application back to "Stasis".
> I'd expect that we'd get at most two events - the {{stasis_start}} and a {{channel_state_change}} if we answered after entering the application - but really, I think we should only get one - the fact that the channel was handed off to Stasis, and that shouldn't occur until the channel is in the Stasis application.
> Either that or we should never go through Originate mechanisms that exist today and Stasis should do its own origination.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list