[asterisk-bugs] [JIRA] (ASTERISK-26666) PJSIP Opus offered and used, but uLaw is sent, Result No Audio
Joshua Colp (JIRA)
noreply at issues.asterisk.org
Tue Jan 3 06:23:10 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua Colp updated ASTERISK-26666:
-----------------------------------
Assignee: Luke Escude (was: Unassigned)
Status: Waiting for Feedback (was: Triage)
The "Don't have" message is normal. It's a dynamic payload from the remote side, so there is no default on our side.
As for the underlying problem I'd suggest using 13 from git or waiting until the next release as I believe this was already fixed by ASTERISK-26603. The format would not switch in all circumstances.
> 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: Luke Escude
> Severity: Critical
> Attachments: call2.pcap, flowroute-280984.pcap, opus-debug, opus-debug2.txt, opus-debug.txt
>
>
> 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)
More information about the asterisk-bugs
mailing list