Summary:	ASTERISK-30142: Missing port in Contact header in response to incoming requests
Reporter:	Morten Sølvberg (Soelvberg)	Labels:
Date Opened:	2022-07-15 12:50:07	Date Closed:	2022-07-19 04:16:29
Priority:	Critical	Regression?	Yes
Status:	Closed/Complete	Components:	pjproject/pjsip
Versions:	18.12.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian Bullseye	Attachments:
Description:	I have recently updated all our tenants from v. 18.0.1 to 18.12.1, and I see behaviour that I haven't encountered before. When receiving incoming INVITEs, then the Contact header reported in the 183 and 200 OK responses does not contain the TCP listening port. For one tenant I use the TCP port 5118, but when the Contact header does not contain that specific port, then the remote party sends the ACK and subsequent BYE to port 5060 - which I am not iistening on. If I enable rewrite_contact on the Endpoint that receives the INVITE, then suddenly the port appears - however not sure why.. Please note that all outbound INVITES and OPTIONS are sent with the correct port in the Contact header - regardless of whether contact_rewrite is enabled for the endpoint. I am quite certain that I haven't seen this behaviour prior to the upgrade to v. 18.12.1. In same upgrade I also updated the Debian version from Buster to Bullseye, but I can't see how this would affect Asterisk. It is not a major issue for me, if I can trust that enabling rewrite_contatct for all endpoints will cause Asterisk to include the listening port in the Contact header, but I would really like to know why. Is this a known bug/change or could it be a configuration issue? Just FYI: I do not REGISTER at the remote host. For the transport I use the below configuration: [transport-tcp] type=transport protocol=tcp bind=0.0.0.0:5118 tos=cs3 cos=3 allow_reload=true external_media_address=52.166.13.xxx external_signaling_address=52.166.13.xxx local_net=10.0.0.0/8 local_net=172.16.0.0/12 local_net=192.168.0.0/16
Comments:	By: Asterisk Team (asteriskteam) 2022-07-15 12:50:08.487-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. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Morten Sølvberg (Soelvberg) 2022-07-18 03:47:43.240-0500 Setting rewrite_contatct on the Endpoint only temporarely fix the issue. Monday morning it was back - so best guess is that it actually was the reload of Asterisk that brought it back to normal. Removing  rewrite_contatct got it to work - but presumably not for long. It also seems to work if I call from an IP that isn't configured - so it comes in on the [anonymous] endpoint - but again, ity might just be the reload... It is now critical, beacuse I don't know which handles to use. By: Joshua C. Colp (jcolp) 2022-07-18 03:54:33.301-0500 Does setting the "external_signaling_port" on the transport to the external signaling port work? As well, does setting "allow_reload" to "no" change anything? That option is purposely off by default, has warnings associated with it, and can cause issues. It is also no longer needed in order to update external_* information. By: Morten Sølvberg (Soelvberg) 2022-07-18 04:08:33.178-0500 Yes, both the external SIP and RTP works perfectly. If I set allow_reload to no, then we can't always change the configuration without restarting it. This part has not been changed for more than 2 years. By: Morten Sølvberg (Soelvberg) 2022-07-18 04:12:53.838-0500 I can manually change allow_reload if you really think that this is the issue. But please note that nothing but the version of Asterisk was changed when these problems started. It is hapening everywhere now, and I am being bombarrded by a lot of angry customers :-( Think I will ned to downgrade all customers to version 18.0.1 unless you can think of a reason. By: Joshua C. Colp (jcolp) 2022-07-18 04:14:57.659-0500 Okay, so you're saying that endpoints which MATCH the local_net and thus external information is not used receive the incorrect port. That wasn't clear in your description. What do you actually need to change that requires reloading a transport? As well you're going to need to provide debug level logging[1]. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Joshua C. Colp (jcolp) 2022-07-18 04:15:33.523-0500 You're free to downgrade. There is no guarantee on when this issue would get fixed, and so far you seem to be the only person experiencing it or who has noticed it. By: Morten Sølvberg (Soelvberg) 2022-07-18 04:24:40.481-0500 I don't need to change anything on order to reload. Just "core reload" does the trick - for a while. I am not receiving anything that matches the local_net patrameters, so I could try removing them - but the IP is always correct. it is "only" the portnumber that often is missing. Please also note that the local_net paramters I have specified are the 3 ranges of local IPs By: Joshua C. Colp (jcolp) 2022-07-18 04:28:29.609-0500 Okay, so the external SIP doesn't work perfectly then if the incorrect port is going into the signaling. As I said, if you set the external_signaling_port option - does that resolve the issue long term or have you set that but the configuration provided does not reflect that, and it still does not work. By: Morten Sølvberg (Soelvberg) 2022-07-18 04:34:32.444-0500 Sorry, misread your earlier post. I didn't know that there was a "external_signaling_port" parameter. I have only used the address ones, but it certainly sounds promising :-) Testing this out, and will let you know By: Morten Sølvberg (Soelvberg) 2022-07-18 08:12:34.645-0500 I have added the external_signaling_port to the problematic tenants, and they have now been running long enough that I dare say that it is fixed now. All remaning tenants will be updated tonight. Thank you so much for your help