The following scenario:
PJSIP user A is configured with UDP
PJSIP user B is configured with TLS
I am using Asterisk Verion 20.0.0
User A calls user B and user B accepts the call. Everything is fine now.
Now user B puts user A on hold. User B terminates the connection because in the 200 Ok of the RE-INVITE in the contact header the SIP URI starts with sip instead of sips!
Why does Asterisk use the incorrect SIP URI in the CONTACT header?
It is strange that the error only occurs in this combination!
Here is the SIP trace starting with the RE-INVITE:
<— Received SIP request (1143 bytes) from TLS:192.168.71.102:57209 —>
INVITE sips:asterisk@192.168.70.118:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.71.102:57209;rport;branch=z9hG4bKPj-De200zkiQCzvKIKUSpjhB1OCikpl.gd;alias
Max-Forwards: 70
From: sips:8900102@192.168.71.102;ob;tag=8ROA3kobWSExKaCvDE6PRkmjy7.7.Vtl
To: sip:8900101@192.168.176.2;tag=981c0d22-16ec-418e-8592-7e4ad2ce843f
Contact: sips:8900102@192.168.71.102:57209;transport=TLS;ob
Call-ID: 20350c4d-fb13-436e-beda-53a24630b67d
CSeq: 18609 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 430
v=0
o=- 3947846873 3947846875 IN IP4 192.168.71.102
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4006 RTP/SAVP 8 9 120
c=IN IP4 192.168.71.102
b=TIAS:64000
a=rtcp:4007 IN IP4 192.168.71.102
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120 telephone-event/8000
a=fmtp:120 0-16
a=ssrc:823331964 cname:2fe5df0b221c4f21
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PYnctbhBT9DZNwwFloGlhANmdG6kFyOVmRxuilLJ
a=sendonly
-- Started music on hold, class 'default', on channel 'PJSIP/8900101-00000bf2'
<— Transmitting SIP response (1021 bytes) to TLS:192.168.71.102:57209 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.71.102:57209;rport=57209;received=192.168.71.102;branch=z9hG4bKPj-De200zkiQCzvKIKUSpjhB1OCikpl.gd;alias
Call-ID: 20350c4d-fb13-436e-beda-53a24630b67d
From: sips:8900102@192.168.71.102;ob;tag=8ROA3kobWSExKaCvDE6PRkmjy7.7.Vtl
To: sip:8900101@192.168.176.2;tag=981c0d22-16ec-418e-8592-7e4ad2ce843f
CSeq: 18609 INVITE
Session-Expires: 600;refresher=uas
Contact: <sip:asterisk@192.168.70.118:5061;transport=TLS>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: MACSIP
Content-Type: application/sdp
Content-Length: 331
v=0
o=- 1250195955 1250195956 IN IP4 192.168.70.118
s=MACS-IP-Docker
c=IN IP4 192.168.70.118
t=0 0
m=audio 8122 RTP/SAVP 9 120
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:vD8ly23f5oUErydnQJd0By92ZOzMCsGM+I15/WGs
a=rtpmap:9 G722/8000
a=rtpmap:120 telephone-event/8000
a=fmtp:120 0-16
a=ptime:20
a=maxptime:150
a=recvonly
<— Received SIP request (464 bytes) from TLS:192.168.71.102:57209 —>
BYE sip:asterisk@192.168.70.118:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.71.102:57209;rport;branch=z9hG4bKPjpMyJKsovx8gfW5CZNsM2N3iYk8LzD.FI;alias
Max-Forwards: 70
From: sips:8900102@192.168.71.102;ob;tag=8ROA3kobWSExKaCvDE6PRkmjy7.7.Vtl
To: sip:8900101@192.168.176.2;tag=981c0d22-16ec-418e-8592-7e4ad2ce843f
Call-ID: 20350c4d-fb13-436e-beda-53a24630b67d
CSeq: 18610 BYE
Warning: 381 ngd-192-168-71-102 “SIPS Required”
Content-Length: 0
<— Transmitting SIP response (399 bytes) to TLS:192.168.71.102:57209 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.71.102:57209;rport=57209;received=192.168.71.102;branch=z9hG4bKPjpMyJKsovx8gfW5CZNsM2N3iYk8LzD.FI;alias
Call-ID: 20350c4d-fb13-436e-beda-53a24630b67d
From: sips:8900102@192.168.71.102;ob;tag=8ROA3kobWSExKaCvDE6PRkmjy7.7.Vtl
To: sip:8900101@192.168.176.2;tag=981c0d22-16ec-418e-8592-7e4ad2ce843f
CSeq: 18610 BYE
Server: MACSIP
Content-Length: 0