[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
john at calva.com
Thu May 14 10:27:57 CDT 2020
On 14/05/2020 16:41, Joshua C. Colp wrote:
> On Thu, May 14, 2020 at 11:31 AM John Hughes <john at calva.com
> <mailto:john at calva.com>> wrote:
> On 14/05/2020 08:10, John Hughes wrote:
>> I am having a problem with one of my callers who is using either
>> g729 or alaw. I can do alaw but not g729 so asterisk should
>> negotiate alaw right? In fact from the sip debug it looks like
>> it does, but then I get the dreaded "channel.c:5630 set_format:
>> Unable to find a codec translation path: (g729) -> (alaw)" and
>> the call hangs up. Why?
>> Last minute thought: Is it possible that the caller is sending
>> g729 in RTP even though the SIP negotiation clearly chooses
>> alaw? Maybe I need some RTP debugging.
> And in fact that is exactly what's happening.
> And when I look at the RTP debugging I see the data from the
> remote is:
>> Got RTP packet from xx.xx.xx.xx:50644 (type 18, seq 001338, ts
>> 610458, len 000020)
> AAArgh! Type 18 is g729. Why on earth is the remote sending me
> g729 when I clearly said the only thing I could do was alaw.
> Is this legal?
> Is the other side broken?
> It shouldn't be sending it, but as well we should be ignoring it. I
> believe we do ignore in modern versions, I can't speak for your old
> one. As for why... I don't really have an answer.
Ok, so maybe upgrading my asterisk would be a good idea, but I don't
think it'll fix this problem, they sent me 6 g729 packets before the
communication was cut, I'm pretty sure they've just ignored the results
of the negotiation.
I hope I can get them to fix their system...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-users