After upgrading from Asterisk 13.1.0 to Asterisk 13.18.3 (Ubuntu 16.04 to Ubuntu 18.04), calls get dropped immediately after resuming a call. When a call is put on hold, moh plays until the exact moment the call gets resumed. The problem occurs without moh too.
By enabling sip logging, I found that the phone that was put on hold (and played the moh) receives an INVITE header without any audio codecs. Therefore, that phone does not accept the resume (SIP/2.0 488 Not acceptable here). What I do not understand is why no audio codecs are added to the INVITE request.
I have created a sip log from the moment the call gets resumed (by 192.168.0.2). The problem starts at line 102 where the codecs should be added. Any suggestions are deeply appreciated.
Do you have a suggestion on how to investigate this further? None of the log levels I tried provided any useful output. For example, notice,warning,error,debug,verbose(999),dtmf,fax produced the following output, where you can see the resume/disconnect in the last four lines.
[Sep 18 14:28:01] VERBOSE[27349][C-00000020] netsock2.c: Using SIP RTP CoS mark 5
[Sep 18 14:28:01] VERBOSE[27349][C-00000020] res_rtp_asterisk.c: 0x7f47540842c0 – Strict RTP learning after remote address set to: 192.168.0.3:7076
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] pbx.c: Executing [104@LocalSets:1] Dial(“SIP/android-00000020”, “SIP/yealink”) in new stack
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] netsock2.c: Using SIP RTP CoS mark 5
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] app_dial.c: Called SIP/yealink
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] app_dial.c: SIP/yealink-00000021 is ringing
[Sep 18 14:28:01] VERBOSE[27349][C-00000020] res_rtp_asterisk.c: 0x7f4730009e50 – Strict RTP learning after remote address set to: 192.168.0.2:12480
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] app_dial.c: SIP/yealink-00000021 answered SIP/android-00000020
[Sep 18 14:28:01] VERBOSE[28543][C-00000020] bridge_channel.c: Channel SIP/yealink-00000021 joined ‘simple_bridge’ basic-bridge
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] bridge_channel.c: Channel SIP/android-00000020 joined ‘simple_bridge’ basic-bridge
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] bridge.c: Bridge e69ed07e-4927-479a-9771-c27ad4e75236: switching from simple_bridge technology to native_rtp
[Sep 18 14:28:01] VERBOSE[28542][C-00000020] bridge_native_rtp.c: Remotely bridged ‘SIP/android-00000020’ and ‘SIP/yealink-00000021’ - media will flow directly between them
[Sep 18 14:28:01] VERBOSE[27349][C-00000020] res_rtp_asterisk.c: 0x7f4730009e50 – Strict RTP learning after remote address set to: 192.168.0.2:12480
[Sep 18 14:28:02] VERBOSE[28543][C-00000020] res_rtp_asterisk.c: 0x7f4730009e50 – Strict RTP switching to RTP target address 192.168.0.2:12480 as source
[Sep 18 14:28:02] VERBOSE[27349][C-00000020] res_rtp_asterisk.c: 0x7f47540842c0 – Strict RTP learning after remote address set to: 192.168.0.3:7076
[Sep 18 14:28:14] VERBOSE[28542][C-00000020] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘SIP/android-00000020’
[Sep 18 14:28:14] VERBOSE[27349][C-00000020] res_rtp_asterisk.c: 0x7f47540842c0 – Strict RTP learning after remote address set to: 192.168.0.3:7076
[Sep 18 14:28:14] VERBOSE[28542][C-00000020] res_rtp_asterisk.c: 0x7f47540842c0 – Strict RTP switching to RTP target address 192.168.0.3:7076 as source
[Sep 18 14:28:16] VERBOSE[28542][C-00000020] res_rtp_asterisk.c: 0x7f47540842c0 – Strict RTP learning complete - Locking on source address 192.168.0.3:7076
[Sep 18 14:28:44] VERBOSE[28542][C-00000020] res_musiconhold.c: Stopped music on hold on SIP/android-00000020
[Sep 18 14:28:44] VERBOSE[28542][C-00000020] bridge_channel.c: Channel SIP/android-00000020 left ‘native_rtp’ basic-bridge
[Sep 18 14:28:44] VERBOSE[28543][C-00000020] bridge_channel.c: Channel SIP/yealink-00000021 left ‘native_rtp’ basic-bridge
[Sep 18 14:28:44] VERBOSE[28542][C-00000020] pbx.c: Spawn extension (LocalSets, 104, 1) exited non-zero on ‘SIP/android-00000020’
If you don’t need direct media then disable it. If you do need it then the first step would be to upgrade to an actual supported configuration. Personally I don’t spend time supporting old versions because in many times things are already fixed. If after upgrading the problem still occurs then you’d need to provide configuration and further details to reproduce it.