[asterisk-bugs] [JIRA] (ASTERISK-29190) chan_sip / pjsip: Ability to use ephemeral TCP/TLS port in signalling can improve interop

[Richard Mudgett (JIRA)]

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

Richard Mudgett edited comment on ASTERISK-29190 at 3/19/21 3:42 PM:
---------------------------------------------------------------------

I think it is fixed by ASTERISK-29241.


was (Author: micha):
I think it is fixed [here|https://issues.asterisk.org/jira/browse/ASTERISK-29241].

> chan_sip / pjsip: Ability to use ephemeral TCP/TLS port in signalling can improve interop
> -----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29190
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29190
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Channels/chan_sip/TCP-TLS, pjproject/pjsip
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>            Assignee: Unassigned
>            Severity: Major
>
> 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)