PJSIP calling SIPS endpoint using TLS leads to immediate BYE upon call pickup

Hi there,
I run into a problem migrating some of my PJSIP endpoints from using simple SIP to SIPS using TLS transport.

Symptoms:

  • client (linphone) can register to asterisk PBX flawlessly using TLS transport on both IPv4 or IPv6
    client (linphone) can place calls to asterisk PBX flawlessly using TLS transport on both IPv4 or IPv6 + SRTP
  • asterisk PBX can ring the registered client (linphone) using TLS transport on both IPv4 or IPv6 but as soon as the client answers the call, asterisk PJSIP ends it with a “BYE” message + warning “SIPS required”

my anticipations so far:

  • according to PJSIP documentation use of TLS transports forces the use of sips: in SIPS URI scheme but asterisk calling the endpoint does write a sip: URI instead of sips: in its from-header for some reason
    ** if that is really the cause: how to configure asterisk to set a correct from-header?

further variants tried so far without having an obvious effect on the problem:

  • transport = transport-tls6 set in endpoint configuration
  • transport = transport-tls set in endpoint configuration
  • client configured to use IPv4 / IPv6 exclusively with according registration

Software in use:

  • Asterisk 16.28.0~dfsg-0+deb11u3 (Debian 11)
  • pjsip show version: PJPROJECT version currently running against: 2.12.1
  • client registered / connected: Linphone Desktopn 4.4.10 as found in Debian 12

Configuration deemed relevant:

pjsip.conf

[global]
type = global
debug = no
keep_alive_interval = 30

[transport-tls6]
type=transport
protocol=tls
bind=[::]:5061
external_signaling_port = 5061
cert_file=/etc/asterisk/ssl/fullchain.pem
priv_key_file=/etc/asterisk/ssl/privkey.pem
ca_list_file=/etc/ssl/certs/ca-certificates.crt
method=tlsv1_2
allow_reload = yes
require_client_cert = no
symmetric_transport = yes
verify_client = false
verify_server = false

[transport-udp6]
type=transport
protocol=udp
bind=::
external_signaling_port = 5060
allow_reload = yes

[transport-tcp6]
type=transport
protocol=tcp
bind=::
external_signaling_port = 5060
allow_reload = yes

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
local_net = 192.168.0.0/24
local_net = 192.168.200.0/24
local_net = 127.0.0.1/32
external_media_address = sip.example.org
external_signaling_address = sip.example.org
external_signaling_port = 5061
cert_file=/etc/asterisk/ssl/fullchain.pem
priv_key_file=/etc/asterisk/ssl/privkey.pem
ca_list_file=/etc/ssl/certs/ca-certificates.crt
method=tlsv1_2
allow_reload = yes

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
local_net = 192.168.0.0/24
local_net = 192.168.200.0/24
local_net = 127.0.0.1/32
external_media_address = sip.example.org
external_signaling_address = sip.example.org
external_signaling_port = 5060
allow_reload = yes

[transport-tcp]
type=transport
protocol=tcp
bind = 0.0.0.0
local_net = 192.168.0.0/24
local_net = 192.168.200.0/24
local_net = 127.0.0.1/32
external_media_address = sip.example.org
external_signaling_address = sip.example.org
external_signaling_port = 5060
allow_reload = yes

[username-tls]
type = aor
max_contacts = 10

[username-tls]
type=auth
auth_type=userpass
password=topsecret
username=username-tls

[username-tls]
type = endpoint
language = de
context = sip-intern-username
aors = username-tls
auth = username-tls   
rtp_symmetric=yes
rtp_ipv6 = true
allow = opus,g722,alaw,ulaw,gsm,h263p,h264,vp8
accountcode = username
direct_media = no
identify_by = auth_username
ice_support = yes
media_encryption = sdes

Dialplan command used from extensions.ael:

Dial(${PJSIP_DIAL_CONTACTS(username-tls)},300,TtrkK);

PJSIP log lines deemed relevant (user names and IPs replaced by consistend bogus values):

<--- Received SIP response (1755 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 200 Ok
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPja8f06af5-ffb2-469f-ab4e-f3a6c0478686;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 316 INVITE
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Contact: <sip:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394;transport=tls>;expires=599;+sip.instance="<urn:uuid:50358e3f-8ae2-4070-8bae-0cd9257efad7>";+org.linphone.specs="ephemeral/1.1,groupchat/1.1"
Content-Type: application/sdp
Content-Length: 840

v=0
o=username-tls 69 1371 IN IP6 2a02:3100:5967:601:1234:1234:1234:1234
s=Talk
c=IN IP6 2a02:3100:5967:601:1234:1234:1234:1234
t=0 0
a=ice-pwd:b2bae5ac4b1cf6f584527990
a=ice-ufrag:6d0fd334
m=audio 7078 RTP/SAVP 9 8 0 3 101
c=IN IP4 77.187.19.62
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:aTur/YgPHIRXilSGZllRSl8G/Q2UJHxRtXsIDUsK
a=candidate:1 1 UDP 2130706303 192.168.3.149 7078 typ host
a=candidate:1 2 UDP 2130706302 192.168.3.149 7079 typ host
a=candidate:2 1 UDP 2130706431 2a02:3100:5967:601:1234:1234:1234:1234 7078 typ host
a=candidate:2 2 UDP 2130706430 2a02:3100:5967:601:1234:1234:1234:1234 7079 typ host
a=candidate:3 1 UDP 1694498687 77.187.19.62 7078 typ srflx raddr 192.168.3.149 rport 7078
a=candidate:3 2 UDP 1694498686 77.187.19.62 7079 typ srflx raddr 192.168.3.149 rport 7079

<--- Transmitting SIP request (597 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
BYE sip:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394;transport=tls SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPjf14fa680-f8d8-4790-a54a-d5cfcf99ec21;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 317 BYE
Warning: 381 SIP "SIPS Required"
Max-Forwards: 70
User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0


    -- PJSIP/username-tls-000001dc answered PJSIP/username-all-000001db
    -- Channel PJSIP/username-tls-000001dc joined 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
    -- Channel PJSIP/user-all-000001db joined 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
<--- Received SIP response (568 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 200 Ok
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPjf14fa680-f8d8-4790-a54a-d5cfcf99ec21;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 317 BYE
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Supported: replaces, outbound, gruu
Content-Length: 0


    -- Channel PJSIP/username-tls-000001dc left 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
    -- Channel PJSIP/username-all-000001db left 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
  == Spawn extension (telefonanlage, 330, 1) exited non-zero on 'PJSIP/username-all-000001db'

More comprehensive logs:

Logs during client registration:

<--- Received SIP request (752 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
REGISTER sips:sip.example.org SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;branch=z9hG4bK.2b4y-RGKT;rport
From: <sips:username-tls@sip.example.org>;tag=o43SvNbIz
To: sips:username-tls@sip.example.org
CSeq: 20 REGISTER
Call-ID: Gg3tzSF470
Max-Forwards: 70
Supported: replaces, outbound, gruu
Accept: application/sdp
Accept: text/plain
Accept: application/vnd.gsma.rcs-ft-http+xml
Contact: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394>;+sip.instance="<urn:uuid:50358e3f-8ae2-4070-8bae-0cd9257efad7>";+org.linphone.specs="ephemeral/1.1,groupchat/1.1"
Expires: 600
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Content-Length: 0


<--- Transmitting SIP response (549 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;rport=45394;received=2a02:3100:5967:601:1234:1234:1234:1234;branch=z9hG4bK.2b4y-RGKT
Call-ID: Gg3tzSF470
From: <sips:username-tls@sip.example.org>;tag=o43SvNbIz
To: <sips:username-tls@sip.example.org>;tag=z9hG4bK.2b4y-RGKT
CSeq: 20 REGISTER
WWW-Authenticate: Digest realm="asterisk",nonce="1710583966/c9aa6beaee1427ca651e45410ce05360",opaque="47b437bb2f75d226",algorithm=MD5,qop="auth"
Server: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0


<--- Received SIP request (1038 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
REGISTER sips:sip.example.org SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;branch=z9hG4bK.CmrStZr66;rport
From: <sips:username-tls@sip.example.org>;tag=o43SvNbIz
To: sips:username-tls@sip.example.org
CSeq: 21 REGISTER
Call-ID: Gg3tzSF470
Max-Forwards: 70
Supported: replaces, outbound, gruu
Accept: application/sdp
Accept: text/plain
Accept: application/vnd.gsma.rcs-ft-http+xml
Contact: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394>;+sip.instance="<urn:uuid:50358e3f-8ae2-4070-8bae-0cd9257efad7>";+org.linphone.specs="ephemeral/1.1,groupchat/1.1"
Expires: 600
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Content-Length: 0
Authorization:  Digest realm="asterisk", nonce="1710583966/c9aa6beaee1427ca651e45410ce05360", algorithm=MD5, opaque="47b437bb2f75d226", username="username-tls",  uri="sips:sip.example.org", response="1b0f0ee269b6025e3848f990f2c2e0cd", cnonce="jjO7HOMLVWQISGSJ", nc=00000001, qop=auth


    -- Added contact 'sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394' to AOR 'username-tls' with expiration of 600 seconds
<--- Transmitting SIP response (616 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;rport=45394;received=2a02:3100:5967:601:1234:1234:1234:1234;branch=z9hG4bK.CmrStZr66
Call-ID: Gg3tzSF470
From: <sips:username-tls@sip.example.org>;tag=o43SvNbIz
To: <sips:username-tls@sip.example.org>;tag=z9hG4bK.CmrStZr66
CSeq: 21 REGISTER
Date: Sat, 16 Mar 2024 10:12:46 GMT
Contact: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:39020>;expires=143
Contact: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394>;expires=599
Expires: 600
Server: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0

Logs during call placement, answer and unexpected BYE:



<--- Transmitting SIP request (2093 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
INVITE sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394 SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPja8f06af5-ffb2-469f-ab4e-f3a6c0478686;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>
Contact: <sips:asterisk@[2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;transport=TLS>
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 316 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Type: application/sdp
Content-Length:  1225

v=0
o=- 1648783594 1648783594 IN IP6 2a02:3100:5967:601:abcd:abcd:abcd:abcd
s=Asterisk
c=IN IP6 2a02:3100:5967:601:abcd:abcd:abcd:abcd
t=0 0
m=audio 10026 RTP/SAVP 9 8 0 107 3 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VveFI4zv65p1y51jK+lhJCp5Oq7bygB14G4VtQ3t
a=ice-ufrag:6e2a86b852331f997e106ddd1dc93922
a=ice-pwd:0d88d532374bee6e21ee598163e3cf9a
a=candidate:H36e300d2 1 UDP 2130706431 2a02:3100:5967:601:abcd:abcd:abcd:abcd 10026 typ host
a=candidate:Hb201d231 1 UDP 2130706431 fe80::210:f3ff:fe20:df32 10026 typ host
a=candidate:H915b26d8 1 UDP 2130706431 fd41:e1ce:8da:c8::1 10026 typ host
a=candidate:H8aeac26c 1 UDP 2130706431 fe80::8cef:b89f:bb09:5e5a 10026 typ host
a=candidate:H36e300d2 2 UDP 2130706430 2a02:3100:5967:601:abcd:abcd:abcd:abcd 10027 typ host
a=candidate:Hb201d231 2 UDP 2130706430 fe80::210:f3ff:fe20:df32 10027 typ host
a=candidate:H915b26d8 2 UDP 2130706430 fd41:e1ce:8da:c8::1 10027 typ host
a=candidate:H8aeac26c 2 UDP 2130706430 fe80::8cef:b89f:bb09:5e5a 10027 typ host
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:107 opus/48000/2
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:60
a=sendrecv

<--- Received SIP response (416 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPja8f06af5-ffb2-469f-ab4e-f3a6c0478686;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 316 INVITE
Content-Length: 0


<--- Received SIP response (576 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPja8f06af5-ffb2-469f-ab4e-f3a6c0478686;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 316 INVITE
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Supported: replaces, outbound, gruu
Content-Length: 0


    -- PJSIP/username-tls-000001dc is ringing
<--- Received SIP response (1755 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 200 Ok
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPja8f06af5-ffb2-469f-ab4e-f3a6c0478686;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 316 INVITE
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Contact: <sip:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394;transport=tls>;expires=599;+sip.instance="<urn:uuid:50358e3f-8ae2-4070-8bae-0cd9257efad7>";+org.linphone.specs="ephemeral/1.1,groupchat/1.1"
Content-Type: application/sdp
Content-Length: 840

v=0
o=username-tls 69 1371 IN IP6 2a02:3100:5967:601:1234:1234:1234:1234
s=Talk
c=IN IP6 2a02:3100:5967:601:1234:1234:1234:1234
t=0 0
a=ice-pwd:b2bae5ac4b1cf6f584527990
a=ice-ufrag:6d0fd334
m=audio 7078 RTP/SAVP 9 8 0 3 101
c=IN IP4 77.187.19.62
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:aTur/YgPHIRXilSGZllRSl8G/Q2UJHxRtXsIDUsK
a=candidate:1 1 UDP 2130706303 192.168.3.149 7078 typ host
a=candidate:1 2 UDP 2130706302 192.168.3.149 7079 typ host
a=candidate:2 1 UDP 2130706431 2a02:3100:5967:601:1234:1234:1234:1234 7078 typ host
a=candidate:2 2 UDP 2130706430 2a02:3100:5967:601:1234:1234:1234:1234 7079 typ host
a=candidate:3 1 UDP 1694498687 77.187.19.62 7078 typ srflx raddr 192.168.3.149 rport 7078
a=candidate:3 2 UDP 1694498686 77.187.19.62 7079 typ srflx raddr 192.168.3.149 rport 7079

<--- Transmitting SIP request (597 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
BYE sip:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394;transport=tls SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPjf14fa680-f8d8-4790-a54a-d5cfcf99ec21;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 317 BYE
Warning: 381 SIP "SIPS Required"
Max-Forwards: 70
User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0


    -- PJSIP/username-tls-000001dc answered PJSIP/username-all-000001db
    -- Channel PJSIP/username-tls-000001dc joined 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
    -- Channel PJSIP/user-all-000001db joined 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
<--- Received SIP response (568 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 200 Ok
Via: SIP/2.0/TLS [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5061;rport;branch=z9hG4bKPjf14fa680-f8d8-4790-a54a-d5cfcf99ec21;alias
From: "User Name" <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=84e62361-5cca-481e-8352-b5a45d201231
To: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=VjR~EP3
Call-ID: 8e3063fa-b0b5-4a95-bbd3-37b1a533f438
CSeq: 317 BYE
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Supported: replaces, outbound, gruu
Content-Length: 0


    -- Channel PJSIP/username-tls-000001dc left 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
    -- Channel PJSIP/username-all-000001db left 'simple_bridge' basic-bridge <79484098-14f9-485a-8919-e50afdac8aff>
  == Spawn extension (telefonanlage, 330, 1) exited non-zero on 'PJSIP/username-all-000001db'
<--- Transmitting SIP request (579 bytes) to UDP:[2a02:3100:5967:600:3631:c4ff:fe03:89cd]:5060 --->
BYE sip:username-all@[2a02:3100:5967:600:3631:c4ff:fe03:89cd];uniq=A848C0345284F9A73A01192CABEA7EA SIP/2.0
Via: SIP/2.0/UDP [2a02:3100:5967:601:abcd:abcd:abcd:abcd]:5060;rport;branch=z9hG4bKPjb58278ec-c813-4734-a222-c53b5b1caac9
From: <sip:330@sip.example.org>;tag=3f96f201-dfd0-492e-8c13-5708eeca50c1
To: "09999123456" <sip:09999123456@sip.example.org>;tag=52212D1A8156511C
Call-ID: 1651706FB251D31B@2a02:3100:5967:600:3631:c4ff:fe03:89cd
CSeq: 310 BYE
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0


<--- Received SIP request (849 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
MESSAGE sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32] SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;branch=z9hG4bK.qGYXBZcay;rport
From: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=RkW5bamA4
To: sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]
CSeq: 20 MESSAGE
Call-ID: OgO-77ToKD
Max-Forwards: 70
Route: <sips:sip.example.org;lr>
Supported: replaces, outbound, gruu
Date: Sat, 16 Mar 2024 10:15:49 GMT
Content-Type: application/im-iscomposing+xml
Content-Length: 170
Priority: non-urgent
Expires: 0
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65

<?xml version="1.0" encoding="UTF-8" standalone="no" ?><isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"><state>active</state><refresh>60</refresh></isComposing>
<--- Transmitting SIP response (586 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;rport=45394;received=2a02:3100:5967:601:1234:1234:1234:1234;branch=z9hG4bK.qGYXBZcay
Call-ID: OgO-77ToKD
From: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=RkW5bamA4
To: <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=z9hG4bK.qGYXBZcay
CSeq: 20 MESSAGE
WWW-Authenticate: Digest realm="asterisk",nonce="1710584149/57578f92c0c2e9262085e38ebb49bc1e",opaque="4fdb534e1b1a040e",algorithm=MD5,qop="auth"
Server: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0


<--- Received SIP request (1163 bytes) from TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
MESSAGE sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32] SIP/2.0
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;branch=z9hG4bK.AlAZfir~0;rport
From: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=RkW5bamA4
To: sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]
CSeq: 21 MESSAGE
Call-ID: OgO-77ToKD
Max-Forwards: 70
Route: <sips:sip.example.org;lr>
Supported: replaces, outbound, gruu
Date: Sat, 16 Mar 2024 10:15:49 GMT
Content-Type: application/im-iscomposing+xml
Content-Length: 170
Priority: non-urgent
Expires: 0
User-Agent: Linphone Desktop/4.4.10 (zimp14) Debian GNU/Linux 12 (bookworm), Qt 5.15.8 LinphoneCore/5.1.65
Authorization:  Digest realm="asterisk", nonce="1710584149/57578f92c0c2e9262085e38ebb49bc1e", algorithm=MD5, opaque="4fdb534e1b1a040e", username="username-tls",  uri="sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]", response="a058ba240556351b276ba4b5d490f36b", cnonce="JKukioNMYLSOZLOM", nc=00000001, qop=auth

<?xml version="1.0" encoding="UTF-8" standalone="no" ?><isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"><state>active</state><refresh>60</refresh></isComposing>
<--- Transmitting SIP response (450 bytes) to TLS:[2a02:3100:5967:601:1234:1234:1234:1234]:45394 --->
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/TLS [2a02:3100:5967:601:1234:1234:1234:1234]:45394;rport=45394;received=2a02:3100:5967:601:1234:1234:1234:1234;branch=z9hG4bK.AlAZfir~0
Call-ID: OgO-77ToKD
From: <sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]>;tag=RkW5bamA4
To: <sip:123456@[2a01:c22:cdd5:4500:210:f3ff:fe20:df32]>;tag=z9hG4bK.AlAZfir~0
CSeq: 21 MESSAGE
Server: Asterisk PBX 16.28.0~dfsg-0+deb11u3
Content-Length:  0

Any help is appreciated pointing out whether this could be a PJSIP configuration problem, wrong use of some dialplan configuration any bug or misbehavior at the linphone client application.

My guess would be that this is the problem. They seem to be be trying to force you out of TLS.

Thanks david for pointing that out. To get it perfectly clear: If this hypothesis is correct, it would be the linphone client sending a malformed Contact URI within the INVITE Respone, correct?

Given that hypothesis let me add two more things:

Registration of the AOR looks like that:

pjsip show contact username-tls/sips:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:48258 

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

  Contact:  username-tls/sips:username-tls@[2a02:3100:5967:601 5da855965f NonQual         nan

Looks perfectly ok for me including the sips: URI scheme.

Please confirm.

Furthermore the INVITE reply from linphone client does not start with sips: (but sip: instead) but includes the ;transport=tls option which in my understanding is a little outdated but should basically indicate the same to PJSIP as using sips:

So in this case linphone client still could be behaving correctly (but using deprecated transport indication) and PJSIP is not as generously in interpreting its INVITES as it could be … (I can guess how a potential answer from linphone developers could sound like)

I’m interested to hear if my interpretation is correct or am I missing something about the “sips:” and “;transport=tls” story?

Unfortunately I’m not aware of any other “easy to install + known to work” SIPS capable client on Debian 12 for testing purposes. Suggestions are welcome.

The questionable Contact is in the OK, not the register. It is the URI to which ACK, re-iNVITEs and BYE will be sent. The REGISTER one is the one used for initial INVITEs. (I think, with TLS, it will only be used in anger if the TLS connection is dropped during the call, and has to be re-estsablished, from the Asterisk side.

Ok, thank you so much for digging into that so far.

Just to make sure that I get everything correctly:
If the hypothesis is that the register within my linphone UA may contain the wrong non-sips: URL I agree, I anticipate that could cause the linphone client to reply with

Contact: <sip:username-tls@[2a02:3100:5967:601:1234:1234:1234:1234]:45394;transport=tls>;expires=599;+sip.instance="<urn:uuid:50358e3f-8ae2-4070-8bae-0cd9257efad7>";+org.linphone.specs="ephemeral/1.1,groupchat/1.1"

which as a consequence is declined by Asterisk according to RFC 5630 (as found here: RFC 5630 - The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP))

Please note (+ confirm that this also matches your understanding of the problem):

pjsip show registrations

does not show my linphone UA and the associated account at all and this is by intention because the linphone UA is roaming around using different IPs each day, noting my asterisk server could potentially register to initially. The asterisk server is deemed to rely on the TLS connection initiated by the linphone client for call processing (and asterisk does that perfectly correct for signalling, as the client indicates ringing).

The only reason I could imagine that linphone does send a non-sips contact URL as a reply is that the “From” field filled by Asterisk is using a simple sip: URL instead of sips: . Any idea how I could potentially change that “From” field to sips: just in case this could influence linphone’s behavior?

Before I start bugging the linphone developers about this potential misbehavior let me please ask once again: Any knowledge of an alternative client software know to work in a sips: scenario together with asterisk, because that would be a rather easy test to narrow down the problem to either the client or asterisk side.