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

[Alexander Traud (JIRA)]

Alexander Traud created ASTERISK-29189:
------------------------------------------

             Summary: 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: 18.1.0, 16.15.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)