[asterisk-bugs] [JIRA] (ASTERISK-29241) pjsip / register: wrong port used in Contact and Via if multiple transports are defined.
Joshua C. Colp (JIRA)
noreply at issues.asterisk.org
Wed Jun 16 05:29:33 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255394#comment-255394 ]
Joshua C. Colp commented on ASTERISK-29241:
-------------------------------------------
"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)."
That statement is incorrect. A SIP trunk MAY reuse this connection, but that is not part of the standard SIP RFC and is a policy decision or deployment decision based on their implementation. It is a choice they've made. It is also part of SIP outbound and the SIP connection reuse RFC, which we don't support in Asterisk itself.
"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)."
This is also incorrect by default. If rewrite_contact is enabled then we will reuse the existing connection, but it is not by default.
Google is a special case because of their unique usage of SIP (which required special behavior for them in the first place). The patch you are referring to was disabling connection reuse of outgoing connections to the same target IP address and port, as each connection was essentially bound to the authenticated user and you could not use multiple over the same connection. PJSIP by default reused the same connection causing it to not work.
The patch as merged is correct in what it was fixing, it just didn't introduce the behavior you desire. If a patch is put up for review which does so, then it will be reviewed. As I stated on my review, if an option was put in place to put the ephemeral port in the SIP signaling and it defaulted to off then such a change could be accepted.
If Florian wants to work on such a thing then he can.
> 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