[asterisk-bugs] [JIRA] (ASTERISK-27985) PJSIP: Does not respond to INVITES when any taskprocessor queue length is > high water level

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244251#comment-244251 ] 

Richard Mudgett commented on ASTERISK-27985:
--------------------------------------------

To be clear: PJSIP is not frozen nor is it locked up while the system is in a taskprocessor alert condition because a queue reached the high water mark.  *Existing* calls will continue to respond to SIP messages.  It will not accept incoming *new* work such as new calls at this time.  When all taskprocessor queues go below the low water mark then the taskprocessor alert condition is cleared and PJSIP resumes normal operation.  The taskprocessor alert condition cannot affect audio as it only discards incoming SIP messages that are not associated with existing dialogs or transactions.  This is *not* the cause of the audio issue you are trying to replicate.

I have seen the subm:manager_topic hit the high water mark in load testing where it had a much higher queue length than what you show.  It clears quickly (within a second) when the load is removed.  The subm:cel_aggregation_topic also clears quickly when you stop flooding it.  However, these two specific topics could take upwards of a minute if the queue length is around a million.  Queues give elasticity to the system to handle activity bursts.  If the activity doesn't let up the system will fall over.

FYI: ASTERISK-26806 Recently went out in a release which greatly speeds up PJSIP when there are a lot of endpoints in the system.

> PJSIP: Does not respond to INVITES when any taskprocessor queue length is > high water level
> --------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27985
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27985
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CEL/cel_odbc
>    Affects Versions: 15.4.1, 13.22.0
>         Environment: FreePBX 14, SNG7
>            Reporter: xrobau
>              Labels: pjsip
>         Attachments: pjsip-ignored.txt
>
>
> We've had sporadic reports of AGIs causing audio glitches on heavy systems (which we believe is related to ASTERISK-26257 but is NOT limited to confbridge, MOH and Playback/Background is also affected).
> {code}
> exten => 998,1,Answer
>  same => n,Dial(Local/999 at from-internal-custom/n,300,gm(default))
>  same => n,Playback(beep)
>  same => n,Goto(1)
> exten => 999,1,Set(COUNT=0)
>  same => n(loop),GotoIf($[ ${COUNT} > 1000 ]?toomany)
>  same => n,Gosub(testtrigger)
>  same => n,Set(COUNT=$[ ${COUNT} + 1 ])
>  same => n,Goto(loop)
>  same => n(toomany),Hangup
>  same => n(testtrigger),Dial(SIP/8675309 at 127.0.0.1:5160,1,g)
>  same => n,Return
> {code}
> The above dialplan simulates a call entering the 'from-pstn' context of FreePBX, which then does - after the standard dialplan - a Hangup. 
> This causes Asterisk to create about 20-30 calls per second (but does not trigger the audio issue, unfortunately).  It does however trigger a new issue where PJSIP channel INVITES are ignored until the cel_aggregation_topic queue is empty:
> {code}
> Processor                                      Processed   In Queue  Max Depth  Low water High water
> ... skipped lines ...
> subm:cdr_engine-00000003                         5780891          0       2347       4500       5000
> subm:cel_aggregation_topic-00000006              4968215     786689    2961396       2700       3000
> subm:endpoint_topic_all-cached-00000008              794          0         13        450        500
> subm:endpoint_topic_all-cached-0000005a              778          0         13        450        500
> subm:manager_topic-00000007                      5962603          0        344       2700       3000
> {code}
> While the queue is being processed, pjsip calls are ignored.  chan_sip calls are answered and processed correctly, increasing the queue size.



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