| Summary: | ASTERISK-25181: ARI: Channels added to Stasis application during WebSocket creation don't receive a StasisStart event | ||||
| Reporter: | Matt Jordan (mjordan) | Labels: | |||
| Date Opened: | 2015-06-22 09:31:04 | Date Closed: | 2015-07-31 12:00:22 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_ari Resources/res_stasis | ||
| Versions: | 13.4.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) asterisk_full.txt ( 1) asterisk_messages.txt ( 2) testsuite_messages.txt | |||
| Description: | While fixing ASTERISK-24988 did fix the race condition where a channel is bounced out of the Stasis application due to the WebSocket being connected but the application not being registered, it has introduced another problem where a StasisStart event is not emitted for a channel.
Consider the following scenario: # A WebSocket connection is started. Before the upgrade response is sent back, we register the Stasis application with {{res_stasis}}, such that any channel that joins after the upgrade notice is accepted. # A channel hits the dialplan application and is put into Stasis, as the application is registered # *HOWEVER* - because the WebSocket TCP connection isn't made, the StasisStart event cannot be sent. This causes the channel to enter Stasis with no notification to the (eventually) connected application. Logs showing this are attached. Note that this was also caught by the same TalkDetect test in the TestSuite. | ||||
| Comments: | |||||