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? -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev