[Home]

Summary:ASTERISK-29189: SIP: TCP/TLS server: Uses SIP Contact not IP:port (on default).
Reporter:Alexander Traud (traud)Labels:patch
Date Opened:2020-12-01 04:07:46.000-0600Date Closed:2020-12-18 12:00:04.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General pjproject/pjsip
Versions:16.15.0 18.1.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) rport_udp_only_as_client.patch
( 1) rport_udp_only_as_server.patch
Description:Dr. Jonathan D. Rosenberg [wrote|https://mailarchive.ietf.org/arch/msg/sip/pUyEVLppGsSKOfk479ft-Llv8Kg/]: “with TCP, ‘standard’ connection usage applies -- the response is sent on the same connection as the request.” In other words, this has to be the default behavior.

However, in chan_pjsip, this behavior is just a side-effect, of a non-default configuration parameter: “\[rewrite_contact=yes\] [helps|https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Configuration_res_pjsip#Asterisk18Configuration_res_pjsip-endpoint_rewrite_contact] reuse reliable transport connections such as TCP and TLS.”

Furthermore, in Asterisk, rPort is not limited to UDP. For example, when {{nat=force_rport}} is set in chan_sip, Asterisk appends (as server and as client) {{;rport}} not only via UDP but also via TCP and TLS transports. Officially, this is a violation of RFC 3581. However, none of [my tested|https://www.traud.de/voip/] SIP User Agents are picky about that. They ignore any unexpected rPort.

Technically, this re-opens ASTERISK-26438, which was fixed by applying {{A_rport_present_nonat.patch}}. That fix worked back then because Google Android requests rPort in TCP as well. For clients without rPort in TCP but with a public IP, the fix {{A_aosp_via_tcp.patch}} is needed. The attached patch uses that approach and extends it to force {{;rport}} only if the transport is UDP (or the client requested rPort).

This issue was reported to me by [~peterdoo]. An AVM FRITZ!Box uses a public IP in the SIP header Contact because it created the Internet connection. With FRITZ!OS 07.19, AVM added SIP over TLS. With that, AVM states port 5061 in the SIP header Contact. However, that is unreachable because no TLS server is listening at that port. Tests revealed, the FRITZ!Box is not the only [platform affected…|https://www.traud.de/voip/rport.htm] To summarize:

Affected SIP User Agents:
# use not UDP but TCP or TLS as transport,
# present a port in the SIP header Contact, which is not the actual source port but another port like 5061,
# provide a public IP in the SIP header Contact,
 This happens when the SIP User Agent is connected via IPv6, or the SIP User Agent created the Internet connection himself, for example, a PPPoE client.
# and that IP:port combination is not reachable.
 This happens when the SIP User Agent is behind a firewall, or has no TCP/TLS server running on that port.

I know, those are a lot of preconditions. However, that does not change the severity of this issue. It just bears of an explanation why this issue was not raised earlier. Asterisk is misusing rPort.

The fix for ASTERISK-26438 hid the underlying issue even further because near to all of the affected platforms request rPort via TCP. Actually, only AVM and Auerswald are in my device collection which bear no workaround for the client side. Yes, the originating problem is that the client does not state the actual port in his SIP header Contact. And, yes, AVM fixed this issue already leaving only Auerswald as remaining platform. Nevertheless, Asterisk should not even look into the SIP header Contact if there is still a TCP existing connection.

*Workaround*
chan_pjsip: rewrite_contact=yes
chan_sip: nat=force_rport,comedia
That workaround is not good because it adds rPort even when the SIP User Agent has not requested it and/or when using TCP/TLS as transport. Although all my testing devices support this, I classified this issue with major severity.
Comments:By: Asterisk Team (asteriskteam) 2020-12-01 04:07:50.263-0600

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: Alexander Traud (traud) 2020-12-01 04:15:36.974-0600

Although the two attached patches work even with Asterisk 18.1, I am not going to submit them.

Reason 1: They are chan_sip and the chan_pjsip part is missing. Adding just those, would create an asymmetry between the two SIP channel drivers.

Reason 2: I do not support chan_pjsip (too complex architecture to investigate in a reasonable timeframe, I am leaving platform, …) therefore I do not resolve that asymmetry.

Reason 3: I do not think such a major change does any good in the state at which chan_sip is right now. Although this is a severe interoperability issue. If you think this is important, take the patch for your installation, and push the issue one step further by submitting those patches into the change process.

By: Joshua C. Colp (jcolp) 2020-12-01 08:01:59.262-0600

The rewrite_contact option in PJSIP is for subsequent in-dialog requests. There is a separate option, force_rport, which controls rport. That being said PJSIP has explicit code[1] when determining where to send a response for reliable transports to use the existing connection.

[1] https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip/sip_util.c#L1610

By: Alexander Traud (traud) 2020-12-01 12:05:31.672-0600

Not sure I understand the comment. When {{rewrite_contact=no}}, incoming calls do not reach my FRITZ!Box (when the FRITZ!Box is using SIP over TLS and provides a public IP, which is the default because it is an Internet router with a PPPoE client).

By: Joshua C. Colp (jcolp) 2020-12-01 12:13:27.944-0600

I'm not sure of the specific scenario you are referring to now but if you are referring to Asterisk sending an INVITE to an endpoint, then I believe you have mixed language and functionality to do with SIP responses with that of SIP requests. In this case the given behavior for PJSIP is expected. For SIP requests we will send to the given Contact address, unless rewrite_contact is enabled in which case we will reuse the connection. For SIP responses they always reuse the connection for TCP and TLS. I can't comment on chan_sip.

By: Alexander Traud (traud) 2020-12-01 12:18:16.441-0600

bq. In this case the given behavior for PJSIP is expected.

And that is wrong. It has to go for the existing TCP connection.

By: Joshua C. Colp (jcolp) 2020-12-01 12:21:47.494-0600

Can you point to the specific RFC, spot, and language that states that? The IETF post does NOT state that. It states that SIP responses to a request use the existing connection.

By: Asterisk Team (asteriskteam) 2020-12-18 12:00:03.812-0600

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