16.30.1 is only supported for security issues. 16.19.0 is a lot older than that.
As a back to back user agent, there is no fundamental reason for Asterisk to send 183 with no information.
Also Asterisk doesn’t forward 183; in the general case, it actually sends AST_CONTROL_PROGRESS from the B side to the core, the DIal application forwards that to the B side, which the generates any appropriate signalling (e.g. SIP 183) on the A side.
You need to reproduce on 20.3.1 or 18.18.1 for anyone to really take an interest, and even then the answer may be that it is intended behaviour.
I upgraded to version 18.18.1. Now Asterisk is forwarding the 183, but it receives from carrier 183 without SDP and sends to the phone 183 with SDP, then the phone opens RTP in its leg and gets without audio, because the carrier does not open 183, since they didn’t send SDP. I did some resources and found that in the some cases carriers use 183 without SDP to ring phones. Is there a way to convert this 183 without SDP to 180 when sending to the phone ?
I added allow_sending_180_after_183=yes in both endpoints configuration phone and carrier.
nope that is one of the realy anoing limites with asterisk
as long at the core is based on ISUP this will always be a problem
as ISUP have no consept of 183
your only option is to use this option
ignore_183_without_sdp = yes
; Do not forward 183 when it doesn't contain SDP.
; Certain SS7 internetworking scenarios can result in
; a 183 to be generated for reasons other than early
; media. Forwarding this 183 can cause loss of
; ringback tone. This flag emulates the behavior of
; chan_sip and prevents these 183 responses from
; being forwarded.
; (default: no)
the 183 without SDP is in essence an 100 Trying Harder except that you can add SDP 183 Session Progress just mean somthing is happening we are still working on your call
witch is nice as it normaly indicate that your INVITE is moving from server to server