Asterisk 13.7.2 pjsip 2.4.5 unexpected BYE with SIP cause 58 while answering

Asterisk Asterisk Support
1

Hi,

I’m upgrading Asterisk 11 to 13 and testing new configuration with WebRTC enpoints. For some reason PJSIP is dropping call sending BYE to replying endpoint after receiving OK packet from that end. No any errors in the console, only == Everyone is busy/congested at this time (1:0/0/1) populated between sending ACK and BYE

At the same time clients are able to place a call and listen messages or perform calls routed via iax

With same scenario Asterisk 11 just establishing connection:

-- SIP/920-00000009 answered SIP/929-00000008 Audio is at 10292 Adding codec 100003 (ulaw) to SDP

Could you please advise what could be a reason for such behaviour?
P.S with the same config Asterisk 13 is sending/receiving SIP MESSAGE perfectly

[code]<— Received SIP response (1462 bytes) from WSS:94.254.177.82:51347 —>
SIP/2.0 200 OK
Via: SIP/2.0/WSS 94.254.177.82:51347;rport;branch=z9hG4bKPjc97efa14-c181-494c-9bb1-5c3456bcc6ef;alias
To: sip:77b9dm51@94.254.177.82;tag=o72806o3ri
From: sip:929@droffice;tag=4315e4c2-f555-4d4d-a921-10a6a6dedfe9
Call-ID: 15e9955f-b0c4-4ec1-b88b-96e76410061a
CSeq: 31682 INVITE
Contact: sip:77b9dm51@192.0.2.181;transport=ws
Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE,MESSAGE
Supported: outbound
User-Agent: SIP.js/0.7.2
Content-Type: application/sdp
Content-Length: 951

v=0
o=mozilla…THIS_IS_SDPARTA-40.0.3 4294967295 0 IN IP4 192.0.2.139
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 56:0F:50:16:0D:2F:A5:A3:4E:FB:D8:28:7E:10:9C:9B:33:A3:7C:12:5F:EC:D5:D4:6F:CE:C6:95:5A:29:3B:04
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 31118 UDP/TLS/RTP/SAVPF 0
c=IN IP4 94.254.177.82
a=candidate:0 1 UDP 2128609535 192.168.8.102 51733 typ host
a=candidate:0 2 UDP 2128609534 192.168.8.102 51734 typ host
a=candidate:1 1 UDP 1692467199 94.254.177.82 31118 typ srflx raddr 192.168.8.102 rport 51733
a=candidate:1 2 UDP 1692467198 94.254.177.82 31135 typ srflx raddr 192.168.8.102 rport 51734
a=sendrecv
a=end-of-candidates
a=ice-pwd:df50a97245f128509801fd272fcb3ef8
a=ice-ufrag:75cbdc4c
a=msid:{4169adb5-b608-4c33-9ee0-d4d74a5417bb} {b3ed1a9c-2722-4b53-ad02-d6bf82a36803}
a=rtcp:31135 IN IP4 94.254.177.82
a=rtpmap:0 PCMU/8000
a=setup:active
a=ssrc:35926506 cname:{122b0db9-7933-468e-9ad1-8a90ec3d077a}

<— Transmitting SIP request (416 bytes) to WSS:94.254.177.82:51347 —>
ACK sip:77b9dm51@94.254.177.82:51347;transport=wss SIP/2.0
Via: SIP/2.0/WSS 94.254.177.82:51347;rport;branch=z9hG4bKPj0d67880b-c194-46c2-b0a0-4a93df7ed4f7;alias
From: sip:929@droffice;tag=4315e4c2-f555-4d4d-a921-10a6a6dedfe9
To: sip:77b9dm51@94.254.177.82;tag=o72806o3ri
Call-ID: 15e9955f-b0c4-4ec1-b88b-96e76410061a
CSeq: 31682 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 13.7.2
Content-Length: 0

== Everyone is busy/congested at this time (1:0/0/1)
<— Transmitting SIP request (440 bytes) to WSS:94.254.177.82:51347 —>
BYE sip:77b9dm51@94.254.177.82:51347;transport=wss SIP/2.0
Via: SIP/2.0/WSS 94.254.177.82:51347;rport;branch=z9hG4bKPja6804328-ff34-436e-a360-1c2bcaf2caa1;alias
From: sip:929@droffice;tag=4315e4c2-f555-4d4d-a921-10a6a6dedfe9
To: sip:77b9dm51@94.254.177.82;tag=o72806o3ri
Call-ID: 15e9955f-b0c4-4ec1-b88b-96e76410061a
CSeq: 31683 BYE
Reason: Q.850;cause=58
Max-Forwards: 70
User-Agent: Asterisk PBX 13.7.2
Content-Length: 0

[/code]

droffice*CLI> pjsip show contacts

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

  Contact:  920/sip:77b9dm51@94.254.177.82:51347;transport ae66a46a6e Unknown         nan
  Contact:  929/sip:7go0gbmf@94.254.178.9:9019;transport=W efcecc6553 Unknown         nan

Endpoint config in pjsip.conf:

[920]
type = endpoint
context = full
;allow = !all,alaw
allow = !all,ulaw
direct_media = no
device_state_busy_at = 1
dtmf_mode = rfc4733
media_encryption = dtls
dtls_verify = no
dtls_cert_file = /etc/asterisk/keys/self/asterisk.pem
dtls_ca_file = /etc/asterisk/keys/self/ca.crt
dtls_setup = actpass
use_avpf = yes
force_avp = yes
ice_support = yes
media_use_received_transport = yes
message_context = messages
allow_subscribe = yes
rewrite_contact = yes

auth = 920
aors = 920
callerid =  <920>
2

Hi,

I found the reason, it was option “force_avp = yes” in an endpoint configuration. Could someone advise why it was a case, when media details as “m=audio 31118 UDP/TLS/RTP/SAVPF 0” are present in all INVITE and OK packets?

Another question, is there any reasonable way to debug such issues? I meant to get readable message in console/log with reason of channel unavailability? I guess it should be inside of pjsip library, but is there any way to get it?

P.S. Also I found, that without option “use_avpf = yes” (and without “force_avp = yes” as well) connection has been established, however no audio is going between endpoints.