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

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-29189:
---------------------------------------

    Attachment: rport_udp_only_as_client.patch
                rport_udp_only_as_server.patch

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.

> 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: Channels/chan_sip/General, pjproject/pjsip
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>              Labels: patch
>         Attachments: rport_udp_only_as_client.patch, rport_udp_only_as_server.patch
>
>
> 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)