[asterisk-bugs] [JIRA] (ASTERISK-29241) pjsip / register: wrong port used in Contact and Via if multiple transports are defined.
Michael Maier (JIRA)
noreply at issues.asterisk.org
Wed Jun 16 05:13:33 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255393#comment-255393 ]
Michael Maier commented on ASTERISK-29241:
------------------------------------------
Some Background for you to get hopefully a better understanding of how Asterisk / pjsip actually already works when it comes to TCP/TLS.
*1) Asterisk as client, which registers to SIP trunk provider*
a) pjsip opens a TCP connection to the SIP trunk provider: localIP:someSrcPort - destIP:destPort (destPort usually 5060/5061) / via usual TCP-Handshake
b) If TLS is in use, pjsip starts the TLS handshake
c) This new connection is now a static connection. All messages, regardless of direction, are sent through this connection, regardless, too, regarding inbound or outbound calls. Means: The SIP trunk uses exactly this connection for Inbound calls, too (connection reuse). In Short: absolutely all messages go through this connection - no other connections are involved - this would be foolish, because it would consume a lot of useless time and resources for starting new TCP/TLS-connections (each time TCP handshakes and TSL handshakes).
d) The described behavior is security by design, because Asterisk doesn't need any TCP listener at all for the connection to the SIP Trunk. Therefore it's impossible for any other attacker from outside to open a new connection to the Asterisk server to try to place a call.
*2) Asterisk as a server where SIP phones registers to*
a) SIP phone like Zoiper, sipdroid, Linphone, Gigaset, ... start registration to internal Asterisk listener (TCP/5060 or 5061)
b) If TLS is in use, SIP phone starts the TLS handshake
c) This new connection is now a static connection. All messages, regardless of direction, are sent through this connection, regardless, too, regarding inbound or outbound calls. Means: Asterisk itself uses exactly this connection for inbound calls, too. In Short: absolutely all messages go through this single connection - no other connections are involved - this would be foolish, because it would consume a lot of useless time and resources for starting new TCP/TLS-connections (each time TCP handshakes and TSL handshakes).
d) The described behavior is security by design, because Asterisk doesn't need any SYN right to connect to the phones at all. Therefore it's impossible to connect via TCP from Asterisk server to the voice devices. The opening of TCP connections from Asterisk server to (phone) networks are prohibited by firewall rules.
All of this I wrote here works just perfectly out of the box with Asterisk / pjsip. You may verify it yourself on base of netstat, tcpdump, pjsip log.
To be honest - I don't really understand, what you exactly want to say by stating "There is also RFC5626 which does specify connection reuse, but that is not supported.". I could find a [patch|https://trac.pjsip.org/repos/ticket/2149] of you for pjsip from 9/2018 as result of a problem with Google voice. I'm on the other side [referring to this behavior documented here|https://www.giacomovacca.com/2020/12/sip-connection-reuse-vs-persistent.html] - exactly this way behaves Asterisk / pjsip - regarding persistent connection and connection reuse. Asterisk sends during register in the Via header the parameter alias, which tells the server, that connection reuse is desired. All following requests from Asterisk to the SIP provider contain the alias parameter, too. Things are working brilliantly (Google is by far not a reference for me - it's even the opposite). BTW: I'm building the source based on the Asterisk src.rpm file from Sangoma. Maybe they don't activate your patch? In config.log, define HAVE_PJSIP_TRANSPORT_DISABLE_CONNECTION_REUSE is set to 1. Should be active than? If not - it's perfect, too - I don't want to be restricted because of Google problems. The world is much bigger than Google.
Now back to the original question here: Does the actual patch match the requirements? Scenario is transports containing both, client and listener functionality (client is default in pjsip and can't be deactivated - listener can be deactivated by pjsip means). The actual patch writes the listener ports to the SIP protocol - though they are never used in the described scenario - not even the initial connection uses this port.
The original patch from Florian wrote the effectively used local port to the SIP protocol in Via and Contact. For me I can say: the actual variant has been working in the short test case with two sip trunk providers (even in the NAT case), too. But I can't speak for Florian.
If some RFCs requests the listener port to be in the VIA / Contact header even if it's not used at all - as long as all participants ignore this wrong port and it is working - I don't have any problem. I can't globally say, if each trunk server behaves that way in each situation (I doubt to be honest).
If it comes to the next step using transports for registration to SIP trunk via TCP/TLS and completely deactivated transport listener: what do you want to write to VIA / Contact header? There is no listener at all. The only thing you can write to the headers is the effective local port in use which was used to build the connection from Asterik to SIP trunk. That's exactly what Florian's patch did.
But I admit, that there could be / are scenarios, too, where a listener additionally is really needed and used. In this case, you should for sure add the listener port. Maybe adding a switch to let the admin decide which port to place in SIP headers if in trouble? Or checking, if the transport provides a listener - if yes, take the listener port - if no, take the client port. This seems to be reasonable to me.
> pjsip / register: wrong port used in Contact and Via if multiple transports are defined.
> ----------------------------------------------------------------------------------------
>
> Key: ASTERISK-29241
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29241
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_pjsip_outbound_registration
> Affects Versions: 18.0.1
> Environment: CentOS 7 x86_64
> Reporter: Michael Maier
>
> Define some transports:
> CLI> pjsip show transports
> {code}
> Transport: <TransportId........> <Type> <cos> <tos> <BindAddress....................>
> ==========================================================================================
> Transport: 0.0.0.0-tls tls 3 184 0.0.0.0:5061
> Transport: 0.0.0.0-tls2 tls 3 184 0.0.0.0:5062
> Transport: 0.0.0.0-tls3 tls 3 184 0.0.0.0:5063
> Transport: 0.0.0.0-udp udp 3 184 0.0.0.0:5060
> {code}
> The 3 TLS transports are added to different trunk configuration. 2 examples:
> {code}
> CLI> pjsip show registration telekomPJSIP-001
> <Registration/ServerURI..............................> <Auth..........> <Status.......>
> ==========================================================================================
> telekomPJSIP-001/sip:tel.t-online.de telekomPJSIP-001 Registered
> ParameterName : ParameterValue
> ============================================================
> auth_rejection_permanent : true
> client_uri : sip:+49... at tel.t-online.de
> contact_header_params :
> contact_user : +49...
> endpoint : telekomPJSIP-001
> expiration : 660
> fatal_retry_interval : 0
> forbidden_retry_interval : 10
> line : true
> max_retries : 10000
> outbound_auth : telekomPJSIP-001
> outbound_proxy :
> retry_interval : 60
> server_uri : sip:tel.t-online.de
> support_mediasec : true
> support_outbound : no
> support_path : false
> transport : 0.0.0.0-tls
> CLI> pjsip show registration telekomPJSIP-002
> <Registration/ServerURI..............................> <Auth..........> <Status.......>
> ==========================================================================================
> telekomPJSIP-002/sip:tel.t-online.de telekomPJSIP-002 Registered
> ParameterName : ParameterValue
> =============================================================
> auth_rejection_permanent : true
> client_uri : ...
> contact_header_params :
> contact_user : ...
> endpoint : telekomPJSIP-002
> expiration : 660
> fatal_retry_interval : 0
> forbidden_retry_interval : 10
> line : true
> max_retries : 10000
> outbound_auth : telekomPJSIP-002
> outbound_proxy :
> retry_interval : 60
> server_uri : sip:tel.t-online.de
> support_mediasec : true
> support_outbound : no
> support_path : false
> transport : 0.0.0.0-tls2
> CLI> pjsip show endpoint telekomPJSIP-001
> Endpoint: telekomPJSIP-001 Not in use 0 of inf
> OutAuth: telekomPJSIP-001/+49...
> Aor: telekomPJSIP-001 0
> Contact: telekomPJSIP-001/sip:+49... at tel.t-o 88c72b9045 Avail 13.944
> Transport: 0.0.0.0-tls tls 3 184 0.0.0.0:5061
> Identify: telekomPJSIP-001/telekomPJSIP-001
> Match: 127.0.0.10/32
> CLI> pjsip show endpoint telekomPJSIP-002
> Endpoint: telekomPJSIP-002 Not in use 0 of inf
> OutAuth: telekomPJSIP-002/+49...
> Aor: telekomPJSIP-002 0
> Contact: telekomPJSIP-002/sip:+49... at tel.t- 7f03d717f5 Avail 13.425
> Transport: 0.0.0.0-tls2 tls 3 184 0.0.0.0:5062
> Identify: telekomPJSIP-002/telekomPJSIP-002
> Match: 127.0.0.10/32
> [root at myfw ~]# netstat -n | grep 506
> tcp 0 0 3.2.1.5:53527 217.0.20.195:5061 ESTABLISHED
> tcp 0 0 3.2.1.5:49161 217.0.20.195:5061 ESTABLISHED
> tcp 0 0 3.2.1.5:56727 217.0.20.195:5061 ESTABLISHED
> I verified via tcpdump, that each Register now uses its own connection.
> Next, I checked the Register packets - to telekomPJSIP-001, e.g:
> Via: SIP/2.0/TLS 3.2.1.5:5062;rport;branch=...
> ^^^^
> Contact: <sip:+49... at 3.2.1.5:5062;transport=TLS;line=...>
> ^^^^
> {code}
> => this should be 5061 (because of transport 0.0.0.0-tls which refers to 5061) - not 5062 ...
> => It turns out, that *all* Registers of all trunks are using port 5062 now. Why that? 5061 and 5063 is ignored completely.
> Error can be seen in log and is printed by pjsip_message_filter.c:
> {code}
> static pj_status_t filter_on_tx_message(pjsip_tx_data *tdata)
> ...
> ast_debug(5, "Re-wrote Contact URI host/port to %.*s:%d (this may be re-written again later)\n",
> (int)pj_strlen(&uri->host), pj_strbuf(&uri->host), uri->port);
> {code}
> I didn't test with 18.1.x - but I guess that it could behave the same way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list