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

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp updated ASTERISK-29190:
--------------------------------------

    Assignee: Alexander Traud  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Is there language from the SIP RFC that you've found which states this behavior? As far as I'm aware there is nothing that states you have to use the ephemeral port, provided the port given accepts incoming connections so the remote side can connect back. Within PJSIP we require a TLS transport to exist that can accept incoming connections, and that is the port placed in it. The remote server may choose to reuse the existing connection even without the ephemeral port present but that's not required within the RFC. There are also additional RFCs for connection reuse and such, but those require both client and server support and we don't support them.

> 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
>            Assignee: 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)