Call endpoints that were converted from UDP to TLS

[svenfried]

Dear community,

I have an Asterisk installation that has direct internet connectivity (no NAT). I have a bunch of external devices (mostly FritzBoxes) behind remote NAT. They register with my Asterisk installation using the UDP transport. Everything works great with this configuration.

Then I decided to convert one of the endpoints to TLS, so that they register with my Asterisk using TLS. Incoming calls from the remote endpoint continues to work. BUT: Outgoing calls to the endpoint converted to TLS don’t work any more. In pjsip show contacts, it shows up like this:

CLI> pjsip show contacts

  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

  Contact:  4711/sip:4711@<remote_nat_gw_public_ip>:49746;transp 3ba68171a7 NonQual         nan

Of course, the phone is not reachable on the given port, because there is no port forwarding from the remote NAT gateway to the remote phone behind that NAT gateway.

What I need is to say to PJSIP is:

“Keep the incoming SIP-TLS connection (established from the remote endpont behind NAT) open and send INVITEs over that already established incoming connection.”

But although searching a lot, I haven’t found a way to describe that in PJSIP’s terms.

What I have already tried:

• Setting qualify_frequency for the endpoint’s AOR like it was set before, but as I read, that’s only for connectionless transports (UDP), so I removed it again.
• Setting keep_alive_interval=25 in PJSIP’s global section
• Setting tcp_keepalive_enable=yes and tcp_keepalive_idle_time=15 in my TLS transport

I’m not sure whether any of this can help solving my problem, but at least I’ve tried it.

I then converted a second endpoint (softphone; Linphone on Android) which is also behind a remote NAT gateway and had the same problem.

If anybody of you has an idea how to solve my problem, I’d appreciate any help!

Many thanks!
Sven

[jcolp]

@svenfried

Setting qualify_frequency for the endpoint’s AOR like it was set before, but as I read, that’s only for connectionless transports (UDP), so I removed it again.

This is incorrect. It will send OPTIONS requests over any connection and keep it alive. If that’s not working, then that may not be the problem and you’d need to provide actual logs of the issue.

[svenfried]

@jcolp , first I would like to thank you for your reply. I’m an Asterisk user since 2006, and when running into problems and googling for the solution, your answers to existing threads have often helped me over the years. After nearly 20 years, this is now the first time googling for my Asterisk problem is not sufficient and I need to ask for support here.

I re-added qualify_frequency=15 to the AOR. I know that 15 seconds is quite a low value, but it’s just for testing. Status has changed from NonQual to Unavail.

CLI> pjsip show contacts

  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

  Contact:  4711/sip:4711@<remote_nat_gw_public_ip>:46250;transpo bf89d1570d Unavail         nan

the transport looks like this:

[transport-tls]
type=transport
protocol=tls
cert_file=<file_containing_cert_and_key>
priv_key_file=<file_containing_cert_and_key>
local_net=10.1.0.0/16
bind=0.0.0.0:5061
method=tlsv1_2

endpoint, auth and aor look like this:

[4711]
type=endpoint
transport=transport-tls
media_encryption=sdes 
callerid=Sven <4711>
context=<my_context>
disallow=all
allow=g722
direct_media=no
rewrite_contact=yes   
force_rport=yes       
rtp_symmetric=yes     
auth=auth_4711
aors=4711

[auth_4711]
type=auth
auth_type=userpass
username=4711
password=<my_password>

[4711]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=15

Incoming calls from 4711 are successful. But when trying an outgoing call to 4711, pjsip set logger host <remote_nat_gw_public_ip> says:

<--- Transmitting SIP request (452 bytes) to TLS:<remote_nat_gw_public_ip>:46250 --->
OPTIONS sip:4711@<remote_nat_gw_public_ip>:46250;transport=tls SIP/2.0
Via: SIP/2.0/TLS <my_public_ip>:5061;rport;branch=z9hG4bKPj2aa7e6d8-ffdf-46cd-9da0-0adcb4bf5b85;alias
From: <sip:4711@<my_public_ip>>;tag=3b9c4039-6ba1-4e06-b470-f6f8b460b98f
To: <sip:4711@<remote_nat_gw_public_ip>>
Contact: <sip:4711@<my_public_ip>:5061;transport=TLS>
Call-ID: ace1c63d-4462-4280-86f9-3e2864a200ae
CSeq: 19712 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk
Content-Length:  0

Thanks for any hint!

Best regards,
Sven

[david551]

@svenfried

OPTIONS sip:4711@<remote_nat_gw_public_ip>:46250;transport=tls SIP/2.0

Firstly transmitting OPTIONS isn’t the result of making an outgoing call. (Also, if the lack of an OPTIONS response is the only problem, you can disable qualify.)

Secondly, this looks as though it is trying the reciprocal path, although it is probably using a new local port number, so it might not be recognized as the same transport connection, but that isn’t something that would be visible in the Asterisk logging, you would need to get TCP level logging.

I’m not sure to what extent it is actually SIP compliant to do what you want to do, even if the other side sends the correct Contact header, which I assume it doesn’t. I don’t actually remember anything in the RFCs that allows connection reuse. A quick skim of RFC 3261 seems to say that the REGISTER connection can only be reused for responses and for requests from the same source as the REGISTER, so implicilty doesn’t support re-use in the reverse direction.

On the other hand, I’m not certain that Asterisk doesn’t use heuristics to reuse connections even when the RFCs say you shouldn’t, so I’d also ask what you have done to confirm that the phone didn’t drop the connection immediately after getting the REGISTER response.

PJSIP Transport Selection - Asterisk Documentation seems to say that a connection will be reused, as long as the address and port of the remote end are correct, which they should be, given you have rewrite-contact.

[svenfried]

@david551

Secondly, this looks as though it is trying the reciprocal path, although it is probably using a new local port number, so it might not be recognized as the same transport connection, but that isn’t something that would be visible in the Asterisk logging, you would need to get TCP level logging.

Many thanks for your reply, @david551!

I checked the port used with pjsip show contacts…

  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

  Contact:  4711/sip:4711@<remote_nat_gw_public_ip>:10656;transpo 5e997b3245 NonQual         nan

…and then checked with netstat whether the connection is still alive, and it is:

# LANG= netstat -n | grep <remote_nat_gw_public_ip>:10656
tcp        0      0 <my_public_ip>:5061      <remote_nat_gw_public_ip>:10656      ESTABLISHED

Then I enabled qualify_frequency and see that the connection is not reused, but a new connection is trying to be established, which of course will not go through:

# LANG= netstat -n | grep <remote_nat_gw_public_ip>:10656
tcp        0      1 <my_public_ip>:46565     <remote_nat_gw_public_ip>:10656      SYN_SENT   
tcp        0      0 <my_public_ip>:5061      <remote_nat_gw_public_ip>:10656      ESTABLISHED

Does this look like a bug or not? I’m using Asterisk version 22.5.2.

Many thanks!
Sven

[jcolp]

@svenfried

transport

Try removing this from the endpoint.

[david551]

I wondered about that, but the documentation, whilst first saying transport must not be explicit, then has some text in a box that seems to contradict that.

[svenfried]

Wow, many thanks for this hint, @jcolp! I would never have found that out by myself. qualify_frequency works now and I can call the remote device behind NAT.

Thanks again,
Sven