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

[Kevin Harwell (JIRA)]

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

Kevin Harwell commented on ASTERISK-26666:
------------------------------------------

There appears something odd to be going on. When you look at the debug logs it seems that it keeps trying to switch to opus after receiving opus from the endpoint, but doesn't seem to actually do it. For instance in one debug log you see the following:
{noformat}
[Dec 22 02:27:18] DEBUG[21455][C-00000013] acl.c: For destination '72.190.32.250', our source address is '206.126.62.165'.
[Dec 22 02:27:18] DEBUG[21455][C-00000013] res_rtp_asterisk.c: Setting RTCP address on RTP instance '0x7fe71c00c720'
[Dec 22 02:27:18] DEBUG[21455][C-00000013] res_rtp_asterisk.c: RTP NAT: Got audio from other end. Now sending to address 72.190.32.250:5006
[Dec 22 02:27:18] VERBOSE[21455][C-00000013] res_rtp_asterisk.c: Got  RTP packet from    72.190.32.250:5006 (type 125, seq 011941, ts 126720, len 000042)
[Dec 22 02:27:18] DEBUG[21455][C-00000013] channel.c: Channel PJSIP/100-0000001f setting write format path: gsm -> ulaw
[Dec 22 02:27:18] DEBUG[21455][C-00000013] res_rtp_asterisk.c: Ooh, format changed from none to ulaw
[Dec 22 02:27:18] VERBOSE[21455][C-00000013] res_rtp_asterisk.c: Sent RTP packet to      72.190.32.250:5006 (type 00, seq 032522, ts 000160, len 000160)
[Dec 22 02:27:18] DEBUG[21455][C-00000013] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
[Dec 22 02:27:18] VERBOSE[21455][C-00000013] file.c: <PJSIP/100-0000001f> Playing 'demo-echotest.gsm' (language 'en')
[Dec 22 02:27:18] DEBUG[21455][C-00000013] res_rtp_asterisk.c: 0x7fe71c0059a0 -- Probation learning mode pass with source address 72.190.32.250:5006
[Dec 22 02:27:18] VERBOSE[21455][C-00000013] res_rtp_asterisk.c: Got  RTP packet from    72.190.32.250:5006 (type 125, seq 011942, ts 127680, len 000042)
[Dec 22 02:27:18] DEBUG[21455][C-00000013] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001f' when we're sending 'ulaw', switching to match
[Dec 22 02:27:18] DEBUG[21455][C-00000013] channel.c: Channel PJSIP/100-0000001f setting write format path: gsm -> ulaw
[Dec 22 02:27:18] VERBOSE[21455][C-00000013] res_rtp_asterisk.c: Sent RTP packet to      72.190.32.250:5006 (type 00, seq 032523, ts 000320, len 000160)
{noformat}
And in another you see something similar:
{noformat}
Dec 19 23:56:34] VERBOSE[95833][C-00000011] file.c: <PJSIP/100-0000001d> Playing 'demo-echotest.gsm' (language 'en')
[Dec 19 23:56:34] DEBUG[95833][C-00000011] res_rtp_asterisk.c: 0x7fe778021d70 -- Probation learning mode pass with source address 72.190.32.250:5006
[Dec 19 23:56:34] DEBUG[95833][C-00000011] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001d' when we're sending 'ulaw', switching to match
[Dec 19 23:56:34] DEBUG[95833][C-00000011] channel.c: Channel PJSIP/100-0000001d setting write format path: gsm -> ulaw
[Dec 19 23:56:34] DEBUG[95833][C-00000011] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001d' when we're sending 'ulaw', switching to match
[Dec 19 23:56:34] DEBUG[95833][C-00000011] channel.c: Channel PJSIP/100-0000001d setting write format path: gsm -> ulaw
[Dec 19 23:56:34] DEBUG[95833][C-00000011] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001d' when we're sending 'ulaw', switching to match
[Dec 19 23:56:34] DEBUG[95833][C-00000011] channel.c: Channel PJSIP/100-0000001d setting write format path: gsm -> ulaw
[Dec 19 23:56:34] DEBUG[95833][C-00000011] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/100-0000001d' when we're sending 'ulaw', switching to match
{noformat}
It seems to keep trying to switch without success. Another oddity is why is Asterisk choosing ulaw in the first place when opus was negotiated?

> 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
>            Assignee: Kevin Harwell
>         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)