[asterisk-bugs] [JIRA] (ASTERISK-29692) Asterisk stops responding to SIP OPTIONS requests from other SIP servers or asterisk servers via LAN or WAN with PJSIP module

[Julio Guarniz (JIRA)]

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

Julio Guarniz commented on ASTERISK-29692:
------------------------------------------

Thank you very much for your answer Benjamin,

I understand that I would need to have debugging enabled permanently to be able to attach them, tell me, this could impact the performance of the server in its operation? I ask this since it is a server with a regular load and I do not want to affect the operation of the users . if it does not affect it, you could keep it enabled waiting for the problem to happen again.

As I mentioned above, it is very difficult to know when it will happen, additionally, there are many servers that send the SIP options and have no response when the problem happens, I understand that you would only need as shown the DEBUG and VERBOSE log of one of them, and also from the server that receives them and is not able to answer them, is it correct?

Regarding the patch with debugging output, this could impact the operation of the server service ?, since I understand that when recompiling asterisk with debugging options it impacts the performance of said server. As I mentioned, this server is in constant production and operation, if not, I could apply it following the recommendations that you provide me and provide you with information based on it.

Regarding the time you mention, it is understandable, however, since it is a very difficult problem to locate that directly impacts the operation, we are considering the support or support of a specialist who can review this problem very thoroughly, it would be of great help if Could you provide me with more information for direct support from Digium or Sangoma, or in any case provide me with the necessary information to contemplate the conditions, times and costs about it.

Thank you very much, I await your comments with the information about the direct support and the additional queries that I made.

> Asterisk stops responding to SIP OPTIONS requests from other SIP servers or asterisk servers via LAN or WAN with PJSIP module
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29692
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29692
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 16.21.0
>         Environment: CentOS Linux release 7.9.2009 (Core)
> 16 vCPU with + 64GB RAM
>            Reporter: Julio Guarniz
>            Assignee: Julio Guarniz
>         Attachments: core-asterisk-running-2021-10-15T09-24-08-0500-brief.txt, core-asterisk-running-2021-10-15T09-24-08-0500-full.txt, core-asterisk-running-2021-10-15T09-24-08-0500-info.txt, core-asterisk-running-2021-10-15T09-24-08-0500-locks.txt, core-asterisk-running-2021-10-15T09-24-08-0500-thread1.txt, options not response.PNG, pjsip.conf
>
>
> Good morning, I have this problem that has been happening more frequently recently.
> An Asterisk server after working normally, suddenly stops responding "sip options" messages from other Asterisk's SIP servers, so the other sip servers declare this asterisk server as down at the SIP level.
> I am using Asterisk 16.21.0 with the PJSIP channel, however the asterisk service continues to run and continues to send sip options to the other servers, therefore the trunks on this server's side are always active, but this asterisk for the other servers is UNREACHABLE.
> I have checked the system logs and I have no errors or warnings that could indicate that the problem is related to a particular action or configuration.
> I have also enabled the CORE SET DEBUG to see the events that occur when this happens and I only get these messages.
> #########################################
> [Oct 5 12:40:02] DEBUG[7979]: res_pjsip/pjsip_distributor.c:503 distributor: Searching for serializer associated with dialog dlg0x7f379823d348 for Response msg 481/ACK/cseq=15893 (rdata0x7f37852a0f38)
> [Oct 5 12:40:02] DEBUG[7979]: res_pjsip/pjsip_distributor.c:520 distributor: No dialog serializer for Response msg 481/ACK/cseq=15893 (rdata0x7f37852a0f38). Using request transaction as basis.
> [Oct 5 12:40:02] DEBUG[7979]: res_pjsip/pjsip_distributor.c:128 find_request_serializer: Found transaction tsx0x7f3798e68298 for Response msg 481/ACK/cseq=15893 (rdata0x7f37852a0f38).
> [Oct 5 12:40:02] DEBUG[7979]: res_pjsip/pjsip_distributor.c:138 find_request_serializer: Found serializer pjsip/distributor-000026e9 on transaction tsx0x7f3798e68298
> ############################################
> It should be noted that the problem is solved, every time I restart asterisk and everything returns to normal, happening again in some cases after 2 or 3 days or in some cases up to 1 week later, so it is very difficult to replicate it and know the exact moment when it will happen.
> Today I had this problem again, but previously, after a similar event previously, I had already recompiled asterisk using the DONT OPTIMIZE option, which is recommended to obtain a backtrace and be able to have a better vision of what may be happening.
> I attach the files that I obtained after the problem happened and asterisk was still active, I obtained this by executing the following:
> /var/lib/asterisk/scripts/ast_coredumper --running
> Likewise, I am attaching captures of the traces obtained by sngrep on the affected asterisk server (192.168.0.5), where it is seen that it receives requests from SIP OPTIONS, but is not able to respond to them, so the other servers declare it UNREACHABLE or UNAVAILABLE
> I really appreciate that you can help me to locate the problem and that the attachments are of help to solve this.
> Greetings and thanks.



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