[Home]

Summary:ASTERISK-28980: PJSIP outbound registration issue
Reporter:newborn (newborn838)Labels:
Date Opened:2020-07-06 11:27:01Date Closed:2020-08-11 12:00:02
Priority:MajorRegression?
Status:Closed/CompleteComponents:pjproject/pjsip
Versions:13.34.0 Frequency of
Occurrence
Related
Issues:
Environment:CentOS 7 with latest updatesAttachments:
Description:Client establishes a SIP TLS connection to server.
Client IP 192.168.82.32
Server IP 10.2.60.23
We have a some kind of buggy channel between servers.
From some time, the server stops to receive packets from client and drops the session without sending anything to client.
client continues to push data with no response from server (look tcpdump output from 19:08:18.661449).

When it happens i do the following:
Clean out pjsip.conf (loaded empty one)
then invoked 'module reload'
then restored the pjsip.conf
then invoked 'module reload' again.

No changes. The client continues sending data with TCP Push flag header instead of new SYN or Reset/SYN. Router on the server side just rejects this because it does not belong to any session.
How to destroy a SIP TLS/TCP session on the client without restarting the whole asterisk process?
Here is a tcpdump fragment from client side.

19:07:29.584075 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 35044:36094, ack 27749, win 1059, options [nop,nop,TS val 878646 ecr 2427808571], length 1050
19:07:29.596449 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [P.], seq 27749:28415, ack 36094, win 960, options [nop,nop,TS val 2427808584 ecr 878646], length 666
19:07:29.636438 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [.], ack 28415, win 1077, options [nop,nop,TS val 878699 ecr 2427808584], length 0
19:07:46.645838 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 36094:36168, ack 28415, win 1077, options [nop,nop,TS val 895708 ecr 2427808584], length 74
19:07:46.696469 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [.], ack 36168, win 960, options [nop,nop,TS val 2427825684 ecr 895708], length 0
19:07:50.590621 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [P.], seq 28415:28489, ack 36168, win 960, options [nop,nop,TS val 2427829578 ecr 895708], length 74
19:07:50.590642 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [.], ack 28489, win 1077, options [nop,nop,TS val 899653 ecr 2427829578], length 0
19:08:18.597168 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 36168:36882, ack 28489, win 1077, options [nop,nop,TS val 927659 ecr 2427829578], length 714
19:08:18.608568 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [.], ack 36882, win 977, options [nop,nop,TS val 2427857595 ecr 927659], length 0
19:08:18.609224 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [P.], seq 28489:29203, ack 36882, win 977, options [nop,nop,TS val 2427857596 ecr 927659], length 714
19:08:18.609232 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [.], ack 29203, win 1096, options [nop,nop,TS val 927671 ecr 2427857596], length 0
19:08:18.609625 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 36882:37932, ack 29203, win 1096, options [nop,nop,TS val 927672 ecr 2427857596], length 1050
19:08:18.621904 IP 10.2.60.23.5061 > 192.168.82.32.39918: Flags [P.], seq 29203:29869, ack 37932, win 993, options [nop,nop,TS val 2427857609 ecr 927672], length 666
19:08:18.661449 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [.], ack 29869, win 1114, options [nop,nop,TS val 927724 ecr 2427857609], length 0
19:09:09.633732 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 978696 ecr 2427857609], length 714
19:09:09.853443 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 978916 ecr 2427857609], length 714
19:09:10.073443 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 979136 ecr 2427857609], length 714
19:09:10.517326 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 979579 ecr 2427857609], length 714
19:09:11.397447 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 980460 ecr 2427857609], length 714
19:09:13.161446 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 982224 ecr 2427857609], length 714
19:09:16.689454 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 985752 ecr 2427857609], length 714
19:09:23.737454 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 992800 ecr 2427857609], length 714
19:09:37.849446 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 1006912 ecr 2427857609], length 714
19:10:06.073475 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 1035136 ecr 2427857609], length 714
19:11:02.521459 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 1091584 ecr 2427857609], length 714
19:12:55.417465 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 1204480 ecr 2427857609], length 714
19:14:55.481451 IP 192.168.82.32.39918 > 10.2.60.23.5061: Flags [P.], seq 37932:38646, ack 29869, win 1114, options [nop,nop,TS val 1324544 ecr 2427857609], length 714
Comments:By: Asterisk Team (asteriskteam) 2020-07-06 11:27:02.453-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Joshua C. Colp (jcolp) 2020-07-06 11:51:43.558-0500

There is no ability to destroy a SIP TCP/TLS session. The underlying operating system's TCP/IP should eventually see that the connection is no longer up, at which point it would drop. What version of PJSIP is in use? Do you have a packet capture to share? If you enable debug in logger.conf and set debug to a high level such as 15 does it provide any additional information?
By: Asterisk Team (asteriskteam) 2020-07-20 12:00:00.992-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: newborn (newborn838) 2020-07-27 07:28:40.919-0500

I mean if I unload the PJSIP configuration and load again, I see PUSH of previous TCP session instead of SYN. Is it correct or it is kind of cache in the operation system?
By: Asterisk Team (asteriskteam) 2020-07-27 07:28:41.340-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Joshua C. Colp (jcolp) 2020-07-27 07:32:46.712-0500

I'm not sure what you mean by "unload the PJSIP configuration and load again" but within PJSIP itself it will keep connections up and reuse them.
By: newborn (newborn838) 2020-07-27 14:19:51.667-0500

"unload the PJSIP configuration" - clean the pjsip.conf contents and do 'module reload'
then fill up pjsip.conf again and run 'module reload' again.

in that case, Asterisk does not initiate new TCP session.
only if I restart the whole asterisk process, it is.
so keeping the old tcp session is asterisk feature or operation system IP stack feature?
how to force reset the session?
By: Joshua C. Colp (jcolp) 2020-07-27 14:27:24.209-0500

I'm not sure if doing such a thing for transports is really supported. They don't expect to go away. PJSIP's TCP and TLS support keep connections open so they can be reused. As I mentioned I'm unaware of a way to terminate them or force reset. Do you have any of the information I previously mentioned?
By: Asterisk Team (asteriskteam) 2020-08-11 12:00:01.292-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines