[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?

[John Hughes]

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...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/7113755e/attachment-0001.html>