[asterisk-dev] 13: RTP pass-through creates no-media situations

[Alexander Traud]

No, I do not want to start another thread about codec-negotiation in
chan_sip. However, while playing with the audio-codec Opus in Asterisk 12
and Asterisk 13, I was able to establish a call without audio:

sip.conf
directmedia=no
disallow=all
allow=opus,ulaw

leg 1: VoIP/SIP client is calling Asterisk 13
       Asterisk 13 offers opus,ulaw to leg 2
leg 2: VoIP/SIP client chooses ulaw because it does not have opus
       Asterisk establishes the call and
       tries to transcode between opus <-> ulaw

This fails because Opus is a pass-through codec and cannot be transcoded.
However, the call is established and stays up infinitely. I am not able to
prevent this situation via the dial plan or the user configuration because I
do not know which media codecs are supported/offered by those clients in
advance. Actually, this is exactly the same as ASTERISK-11782. However, back
then the call was not established at all.
Question 1: Is this new (?) behavior intended (establishment vs. dropping)?

While testing, I found another issue (tested with Asterisk 13.3.2):
1) sip.conf with
   disallow=all
   allow=ulaw
2) started Asterisk
3) changed sip.conf to
   allow=opus,ulaw
4) CLI: sip reload
5) called Asterisk from a VoIP/SIP client
6) other clients get ulaw,opus (order is the other way around)
7) CLI: core stop now
started over with step 2, now the expected order (opus,ulaw) is offered.
Question 2: Shall I open an issue for this, or is that intended?