[asterisk-bugs] [JIRA] (ASTERISK-26771) ARI: HTTP requests take 200ms to be taken into account

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-26771:
------------------------------------

    Summary: ARI: HTTP requests take 200ms to be taken into account  (was: ARI: http requests take a huge time to be taken into account)

> ARI: HTTP requests take 200ms to be taken into account
> ------------------------------------------------------
>
>                 Key: ASTERISK-26771
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26771
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_stasis
>    Affects Versions: 14.2.1, GIT
>         Environment: Debian 8.5 
> 3.16.0-4-686-pae 
> gcc (Debian 4.9.2-10) 4.9.2 
>            Reporter: Daniele Pallastrelli
>              Labels: ARI, realtime, stasis
>         Attachments: trace.png
>
>
> h4. Frequency
> Systematic issue.
> h4. Symptoms
> ARI http requests take a huge time to be taken into account (and respond with the appropriate SIP messages)
> h4. Steps required to reproduce the issue
> * Setup an extension with a stasis application (withouth the answer app). E.g.,
> {code}
> exten => 6100,1,NoOp()
>  same =>      n,Stasis(bug)
>  same =>      n,Hangup()
> {code}
> * Place a call from a phone (sip or pjsip user. It doesn't matter) to the stasis extension (6100 in the example)
> * Perform a ARI http request for a answer (or any other request on the channel):
> {code}
> curl -v -u asterisk:asterisk -X POST "http://192.168.210.132:8088/ari/channels/atom_asterisk-1486386024.1/answer"
> {code}
> h4. Expected Behaviour
> The SIP message "200 OK" should be sent soon after the http POST request (let's say after a few milliseconds).
> h4. Behaviour actually encountered
> The SIP message "200 OK" takes an unacceptable time to be sent after the http POST request (>100ms the WCET is 200ms)
> (see the wireshark trace attached)
> h4. Hints
> When a channel enter a stasis application, a new thread is spawned and the function stasis_app_exec executed (file res_stasis.c). The function enter in a while loop that performs a ast_waitfor(channel, MAX_WAIT_MS) call that waits for events with a timeout of MAX_WAIT_MS (200ms).
> Before a "channel/answer" request, the control flow is blocked on the ast_waitfor for 200ms, then handles the requests inside control_dispatch_all, then waits again on the ast_waitfor and so on... I see that the while loop repeats exactly every 200ms. So, when a "channel/answer" request arrives, ast_waitfor doesn't wake up immediately (!) but waits for the 200ms timeout. When ast_waitfor exits for timeout, finally the channel performs the answer (WCET for the answer: 200ms).
> After answering the channel, I see that the while cycle enter every 20ms, because ast_waitfor now exits after only 20ms (and not 200ms as before). So, next requests are more responsive (WCET for following requests: 20ms).
> So, it seems to me that the ast_waitfor function doesn't work as expected (it doesn't wake up on http requests, but always wait the timeout expiration)



--
This message was sent by Atlassian JIRA
(v6.2#6252)