[Home]

Summary:ASTERISK-21777: Asterisk tries to transcode video instead of audio
Reporter:Nick Ruggles (ndruggles)Labels:
Date Opened:2013-05-10 03:24:42Date Closed:2015-04-10 11:26:32
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling Core/CodecInterface
Versions:1.8.18.0 11.3.0 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-24380 core: Native formats are set to h264 with certain audio/video codec configuration, resulting in path translation WARNINGs
Environment:Centos 6.4Attachments:
Description:Asterisk keeps trying to transcode video into audio.

Im trying to pass a call from peer 1, to peer 2.

peer 1 has following enabled.
disallow = all
allow = g722,ulaw,alaw,h264


peer 2 has the following enabled
disallow = all
allow = speex,ulaw,alaw,h264

Unfortunately, i have to have g722 enabled on peer 1, and disabled on peer 2.

Now i would have a successfull call if either, asterisk transcoded the g722 to ulaw or speex, or if asterisk negotiated the whole call to run on ulaw.

instead i get these messages

{noformat}

  -- Executing [8008@Servers:1] Answer("SIP/peer1-0000007c", "") in new stack
   -- Executing [8008@Servers:2] Dial("SIP/peer1-0000007c", "SIP/peer2/8008") in new stack
 == Using SIP VIDEO CoS mark 6
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
   -- Called SIP/peer2/8008
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5081 ast_write: Codec mismatch on channel SIP/peer2-0000007d setting write format to g722 from unknown native formats (h264)
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5309 set_format: Unable to find a codec translation path from (h264) to (g722)
[May 10 09:17:00] WARNING[8952][C-00000042]: chan_sip.c:7280 sip_write: Asked to transmit frame type g722, while native formats is (h264) read/write = unknown/unknown
   -- SIP/peer2-0000007d is ringing
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5081 ast_write: Codec mismatch on channel SIP/peer2-0000007d setting write format to g722 from unknown native formats (h264)
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5309 set_format: Unable to find a codec translation path from (h264) to (g722)
[May 10 09:17:00] WARNING[8952][C-00000042]: chan_sip.c:7280 sip_write: Asked to transmit frame type g722, while native formats is (h264) read/write = unknown/unknown
[May 10 09:17:00] WARNING[16119][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (nothing) formats
[May 10 09:17:00] WARNING[16119][C-00000042]: channel.c:5309 set_format: Unable to find a codec translation path from (ulaw|h264) to (nothing)
[May 10 09:17:00] WARNING[16119][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (nothing) formats
[May 10 09:17:00] WARNING[16119][C-00000042]: channel.c:5309 set_format: Unable to find a codec translation path from (ulaw|h264) to (nothing)
   -- SIP/peer2-0000007d answered SIP/peer1-0000007c
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
   -- Locally bridging SIP/peer1-0000007c and SIP/peer2-0000007d
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5081 ast_write: Codec mismatch on channel SIP/peer2-0000007d setting write format to g722 from h264 native formats (ulaw|h264)
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:940 ast_best_codec: Don't know any of (h264) formats
[May 10 09:17:00] WARNING[8952][C-00000042]: channel.c:5081 ast_write: Codec mismatch on channel SIP/peer2-0000007d setting write format to g722 from h264 native formats (ulaw|h264)

{noformat}
Comments:By: Rusty Newton (rnewton) 2013-05-10 12:47:40.031-0500

Not enough information here to see whats going on.

I'm curious to see the negotiation for each call leg, and what the endpoints offered Asterisk.

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please provide:

* Asterisk VERBOSE and *DEBUG* log, plus a pcap for the same call.
* full sip.conf (or at least general settings, plus the peers involved)



By: Rusty Newton (rnewton) 2013-05-10 12:49:24.877-0500

Please attach all text debug as .txt files to the issue. Thanks!
By: Matt Jordan (mjordan) 2013-05-21 09:09:18.570-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines


By: Leif Madsen (lmadsen) 2013-07-22 09:27:21.861-0500

I can reproduce this easily. I just did it the other day.
By: Leif Madsen (lmadsen) 2013-07-22 09:33:23.240-0500

h2. Overview

This is very easy to reproduce. You just need to have codecs between end points which are mutually exclusive. A simple scenario:

peer 1:  supports ilbc (or g.729, or something not ulaw)
peer 2:  supports ulaw

Both peers support h264.


h3. Failing Scenario
Asterisk is configured with:


*peer 1*
{noformat}
disallow=all
allow=ilbc
allow=h264
{noformat}

*peer 2*
{noformat}
disallow=all
allow=ulaw
allow=h264
{noformat}

If you place a call at this point, you will get the weird transcoding error of Asterisk trying to transcode from an audio codec into a video codec. Of course this doesn't make any sense, and even if it did, Asterisk can't transcode into video.

h3. Working scenario
Leave everything the same on both end points. Peer 1 *only* supports ilbc and h264. Peer 2 *only* supports ulaw and h264.

Change the peer lists to have a mutually inclusive list of codecs:

{noformat}
disallow=all
allow=ilbc
allow=ulaw
allow=h264
{noformat}

With this configuration, the peer 1 will only offer ilbc and will then setup audio to Asterisk via ilbc. The offer to peer 2 will configure itself as only being able to speak ulaw. From what I can tell in the {{core show channel SIP/peer1-00001}} and {{core show channel SIP/peer2-00002}} output, Asterisk is speaking ilbc to peer 1, and ulaw to peer 2.

Without this mutually inclusive list, then the peers will get the weird one way audio and crazy WARNING spam on the screen.

I reproduced this with Asterisk 1.8.18.0, but it looks like the exact same issue all the way though to 11.3.0 as well.
By: Richard Mudgett (rmudgett) 2015-04-09 21:06:49.781-0500

I think this call actually connects and operates just fine.  You are just treated to a bunch of warning messages.
By: Richard Mudgett (rmudgett) 2015-04-09 21:08:39.803-0500

The reviewboard patch (https://reviewboard.asterisk.org/r/4605/) is for ASTERISK-24380.  However, the v11 version of the patch clears up all but the first warning message.  The remaining warning message seems to be benign.
By: r mundkowsky (rmundkowsky) 2015-05-28 15:35:41.991-0500

Would this problem cause video to not work?

Why I try this using sipml5 and Firefox, the video to Asterisk works, but the video from Asterisk does not work.  Yet the audio works.
By: Richard Mudgett (rmudgett) 2015-05-28 15:52:50.509-0500

No.  As I stated above: This problem is just a bunch of benign warning messages since a video codec was erroneously picked as the best codec and there are no video to audio translation paths.