We found that during testing that when codecs are defined in the order
"vp8,g729" the call is dropped. When codecs are instead defined in the
order "g729,vp8" the call succeeds. For our systems we will make sure
codecs are always in "audio,video" order because that seems to work. It
does smell like there's a bug somewhere but I'm not sure what... Think
it is worth reporting or we made a mistake and docs declare we
configured chan_sip the wrong way?
Dennis Buteyn
Xorcom Ltd
On 7/5/20 9:10 PM, Joshua C. Colp wrote:
On Sun, Jul 5, 2020 at 12:04 PM Dennis Buteyn
<dennis.but...@xorcom.com <mailto:dennis.but...@xorcom.com>> wrote:
Any good reason why Asterisk thinks transcoding audio to video and
vice
versa is possible?
Capabilities: us - (vp8|g729), peer -
audio=(g729)/video=(vp8)/text=(nothing), combined - (vp8|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer -
0x1
(telephone-event|), combined - 0x1 (telephone-event|)
[2020-07-05 13:25:53] WARNING[2295][C-00000028]: channel.c:5850
set_format: Unable to find a codec translation path: (vp8) -> (g729)
[2020-07-05 13:25:53] WARNING[2295][C-00000028]: channel.c:5850
set_format: Unable to find a codec translation path: (g729) -> (vp8)
The legacy way of storing format information combines all types
together, which can result in code mistakenly trying to set up such
translation paths. Entirely possible that there is a bug somewhere
where the video is not eliminated.
--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com <http://www.sangoma.com> and
www.asterisk.org <http://www.asterisk.org>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev