[asterisk-bugs] [JIRA] (ASTERISK-29190) SIP: TCP/TLS client: IP source port is not SIP Contact port.

Asterisk Team (JIRA) noreply at issues.asterisk.org
Tue Dec 1 04:25:16 CST 2020


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

Asterisk Team commented on ASTERISK-29190:
------------------------------------------

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 client: IP source port is not SIP Contact port.
> ------------------------------------------------------------
>
>                 Key: ASTERISK-29190
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29190
>             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
>
> Asterisk is a SIP Back-to-Back User Agent ([B2BUA|https://en.wikipedia.org/wiki/Back-to-back_user_agent]). Therefore, Asterisk does not simply proxy but transform requests. When it comes to the transport TCP (and TLS), Asterisk can be both, a TCP client and a TCP server. When Asterisk talks to a remote SIP service provider, Asterisk registers on the SIP layer and plays the role of a TCP client on the IP layer.
> Such a client connection has a destination port and source port. Because that connection is kept alive, the source port cannot be re-used. In other words, for each remote registration, a unique TCP source port is required locally. Asterisk solves this by setting the source port to zero. That asks the operating system for a so-called [ephemeral port|https://en.wikipedia.org/wiki/Ephemeral_port].
> In the old SIP channel driver chan_sip, this is done in {{sip_prepare_socket(.)}} ← {{__sip_xmit(.)}}:{code} /* Reset tcp source port to zero to let system pick a random one */
> ast_sockaddr_set_port(&ca->local_address, 0);{code}
> Not sure, where this is done in the current SIP channel driver chan_pjsip.
> However, in SIP, the headers {{Via}} and {{Contact}} include the source port. And Asterisk does not write that ephemeral but a static port into those two SIP headers
> For a TCP based transport, those SIP headers can be ignored because the response is sent on the same connection as the request ([source| http://mailarchive.ietf.org/arch/msg/sip/pUyEVLppGsSKOfk479ft-Llv8Kg/]). In other words, the existing connection is re-used, and the port in those SIP headers does not matter.
> However, services exist which do not follow this rule. Actually, Asterisk as a server does not follow this. In chan_sip, {{nat=force_rport}} must be set. In chan_pjsip, {{rewrite_contact=yes}}, see ASTERISK-29189.
> Consequently, for such services, the port on the SIP layer (especially the one in the SIP header {{Contact}}) has to match the port on the IP layer, the ephemeral port created by the operating system.
> Because I do not have a service with that problem -- all my services ignore the port in the SIP header {{Contact}} -- I do not continue from here.
> However, I looked into chan_sip: With that, the source port is only known to the file descriptor of the TCP client connection ({{sip_pvt→sip_socket→fd}}). Asterisk never asks the operating system for the port. Consequently, the solution is not that easy. One approach might be {{ast_ouraddrfor(.)}} ← {{ast_sip_ouraddrfor(.)}}. There, an expensive TCP connection is started, just to get the source address = ‘us’. Instead of closing that TCP client connection, its file descriptor could be retained for later. Because that descriptor would not change, its source port is available when the SIP headers are built, not after building.



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



More information about the asterisk-bugs mailing list