[asterisk-bugs] [JIRA] (ASTERISK-29189) SIP: TCP/TLS server: Uses SIP Contact not IP:port (on default).

[Asterisk Team (JIRA)]

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

Asterisk Team commented on ASTERISK-29189:
------------------------------------------

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/].

> SIP: TCP/TLS server: Uses SIP Contact not IP:port (on default).
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-29189
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29189
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: . I did not set the category correctly.
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>
> 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.



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