[asterisk-bugs] [JIRA] (ASTERISK-26666) chan_pjsip: Opus offered and used, but uLaw is sent, Result No Audio

Wed Feb 15 10:35:11 CST 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235208#comment-235208 ] 

Richard Mudgett edited comment on ASTERISK-26666 at 2/15/17 10:34 AM:
----------------------------------------------------------------------

Order of codecs in Asterisk does not matter.

Test 1: uLaw endpoint calls Opus endpoint (ulaw endpoint hears audio, Opus does not)
{noformat}
[Feb 15 01:28:49] DEBUG[80906][C-00000173] res_rtp_asterisk.c: Unsupported payload type received
[Feb 15 01:28:49] DEBUG[80906][C-00000173] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000028c' when we're sending 'ulaw', switching to match
[Feb 15 01:28:49] DEBUG[80906][C-00000173] channel.c: Channel PJSIP/100-0000028c setting write format path: ulaw -> ulaw
{noformat}
It's definitely making the attempt to switch the channel to Opus, but the path it sets is uLaw -> uLaw instead of uLaw -> Opus or whatever the order is.

Test 2 failed as well, it was just the other direction (Opus endpoint calling uLaw endpoint)

Test 3 (This is interesting)... The previous uLaw endpoint is now using iLBC:30... Infinite loop is caused. Look here:
{noformat}
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000029b' when we're sending 'ilbc', switching to match
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting write format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting read format path: opus -> opus
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge_native_rtp.c: Packetization differs between RTP streams (30 != 30 or 20 != 30). Cannot native bridge in RTP
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Chose bridge technology simple_bridge
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling simple_bridge technology constructor
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: moving 0x7ffaec236a90(PJSIP/101-0000029a) to dummy bridge temporarily
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: moving 0x7ffaec727240(PJSIP/100-0000029b) to dummy bridge temporarily
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec236a90(PJSIP/101-0000029a) is leaving native_rtp technology (dummy)
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge_native_rtp.c: Discontinued RTP bridging of 'PJSIP/101-0000029a' and 'PJSIP/100-0000029b' - media will flow through Asterisk core
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec727240(PJSIP/100-0000029b) is leaving native_rtp technology (dummy)
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling native_rtp technology stop
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec236a90(PJSIP/101-0000029a) is joining simple_bridge technology
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting read format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/101-0000029a setting write format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec727240(PJSIP/100-0000029b) is joining simple_bridge technology
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling simple_bridge technology start
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling native_rtp technology destructor
.... 
{noformat}
The constant switching goes on eternally until I stop the test.

Test 4: Same test, but iLBC:20 and got the same one-way audio, iLBC could hear Opus but Opus could not hear iLBC endpoint.

was (Author: lukeescude):
Order of codecs in Asterisk does not matter.

Test 1: uLaw endpoint calls Opus endpoint (ulaw endpoint hears audio, Opus does not)
[Feb 15 01:28:49] DEBUG[80906][C-00000173] res_rtp_asterisk.c: Unsupported payload type received
[Feb 15 01:28:49] DEBUG[80906][C-00000173] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000028c' when we're sending 'ulaw', switching to match
[Feb 15 01:28:49] DEBUG[80906][C-00000173] channel.c: Channel PJSIP/100-0000028c setting write format path: ulaw -> ulaw

It's definitely making the attempt to switch the channel to Opus, but the path it sets is uLaw -> uLaw instead of uLaw -> Opus or whatever the order is.

Test 2 failed as well, it was just the other direction (Opus endpoint calling uLaw endpoint)

Test 3 (This is interesting)... The previous uLaw endpoint is now using iLBC:30... Infinite loop is caused. Look here:
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000029b' when we're sending 'ilbc', switching to match
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting write format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting read format path: opus -> opus
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge_native_rtp.c: Packetization differs between RTP streams (30 != 30 or 20 != 30). Cannot native bridge in RTP
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Chose bridge technology simple_bridge
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling simple_bridge technology constructor
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: moving 0x7ffaec236a90(PJSIP/101-0000029a) to dummy bridge temporarily
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: moving 0x7ffaec727240(PJSIP/100-0000029b) to dummy bridge temporarily
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec236a90(PJSIP/101-0000029a) is leaving native_rtp technology (dummy)
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge_native_rtp.c: Discontinued RTP bridging of 'PJSIP/101-0000029a' and 'PJSIP/100-0000029b' - media will flow through Asterisk core
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec727240(PJSIP/100-0000029b) is leaving native_rtp technology (dummy)
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling native_rtp technology stop
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec236a90(PJSIP/101-0000029a) is joining simple_bridge technology
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/100-0000029b setting read format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] channel.c: Channel PJSIP/101-0000029a setting write format path: ilbc -> ilbc
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: 0x7ffaec727240(PJSIP/100-0000029b) is joining simple_bridge technology
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling simple_bridge technology start
[Feb 15 01:35:44] DEBUG[81214][C-0000017b] bridge.c: Bridge 582f9bfe-a2fa-4d33-9464-71f52f0fc6a1: calling native_rtp technology destructor
.... 
The constant switching goes on eternally until I stop the test.

Test 4: Same test, but iLBC:20 and got the same one-way audio, iLBC could hear Opus but Opus could not hear iLBC endpoint.

> chan_pjsip: Opus offered and used, but uLaw is sent, Result No Audio
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-26666
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26666
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.13.1
>         Environment: x64 CentOS
>            Reporter: Luke Escude
>         Attachments: asterisk.pcap, asterisk.txt, call2.pcap, flowroute-280984.pcap, gs.pcap, opus-debug, opus-debug2.txt, opus-debug.txt, yl.pcap
>
>
> The following codecs are configured for an endpoint, in order of priority:
> Opus
> uLaw
> iLBC
> g729
> Asterisk and the handset settle on Opus being the codec for the call, but no audio can be heard from the echo test (or extension-to-extension, or anything).
> Running "pjsip show channelstats" shows uLaw as the codec, even though it should say Opus. opus-debug file shows a lot of the following error:
> Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001d' when we're sending 'ulaw', switching to match

--
This message was sent by Atlassian JIRA
(v6.2#6252)