TLS: How to advertise actual source port in register contact?

Hi Gang

Asterisk 16.28 (I know, it’s ancient).

When registering Asterisk as a client, to an SIP Provider (I work for) i specify:

[transport-tls6]
type=transport
protocol=tls
bind=[::]:5061
cert_file=/etc/letsencrypt/live/[domain]/fullchain.pem
priv_key_file=/etc/letsencrypt/live/[domain]/privkey.pem
ca_list_path = /etc/ssl/certs/
method=tlsv1_2

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/letsencrypt/live/[domain]/fullchain.pem
priv_key_file=/etc/letsencrypt/live/[domain]/privkey.pem
ca_list_path = /etc/ssl/certs/
method=tlsv1_2

[ISP-XX]
type=registration
outbound_auth=ISP-XX
contact_user=51P-h4k3R
server_uri=sip:registraruri
client_uri=sip:WFWG311@registraruri
retry_interval=60
expiration=300
line=yes
endpoint=ISP-XX
auth_rejection_permanent=no
forbidden_retry_interval=300
fatal_retry_interval=600
max_retries=65536

[ISP-XX]
type=aor
contact=sip:registraruri
qualify_frequency=0
authenticate_qualify=yes

[ISP-XX]
type=endpoint
context=from-ISP-XX
outbound_auth=ISP-XX
aors=ISP-XX
contact_user=51P-h4k3R
allow=!all,opus,g722,alaw,gsm,h264,vp9,vp8
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
device_state_busy_at=4
tone_zone=ch
language=de
trust_id_inbound=yes
trust_id_outbound=yes
send_pai=yes
send_diversion=yes
rtp_keepalive=5
media_encryption_optimistic=yes
media_encryption=sdes
dtls_auto_generate_cert=yes
t38_udptl=yes
user_eq_phone=yes
force_rport=no
direct_media=yes
ice_support=yes
use_ptime=yes
rtp_ipv6=yes
t38_udptl_ipv6=yes
geoloc_outgoing_call_profile = locprofile
timers_sess_expires=900
timers_min_se=90

ISP publishes NAPTR + SRV Records priorizing TLS on Port 5061

Issue observed:

Registration to Registrar via TLS Port 5061 happens from source port: 43807 but Asterisk advertises Port 5061 in it’s Register Contact, triggering this connection being handled as a NAT situation by the registrar.

Is there a way to have asterisk advertise the actually used TCP/TLS port in the Register Contact Header?

-Benoît-

That’s right. I doubt that many, if any, SIP UAS can re-use a connection in the reverse direction, and TCP would break if they could set up a concurrent connection with the same port numbers.

What do the Via headers say?

Most UAS I know (Kamailio and an commercial SBC I work with) use the existing TCP connection from the registration to communicate to the UAC and if that connection is lost, immediately ‘deregister’ the UAC as this facilitates passing throug NAT.

Most (acutally all) UAC I observe, when using TCP or TLS, put the actual source port in the REGISTER contact header.

Solving NAT issues is (besides solving UDP fragmentation issues) the reason most of our customer keep wanting to use TCP or TLS over UDP.

Yes, I am aware, they still have to solve how to get RTP through nat :slight_smile:

There is no functionality or configuration for doing so.