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

[Joshua Colp]

Alexander Traud wrote:
> 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)?

I'd expect it to fail. The new bridging work may have had a side effect 
of not making it fatal.

>
> 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?

If you reload it should have the new preference order. This would be a 
bug, likely in chan_sip itself.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org