Res_rtp_asterisk.c: Unknown RTP codec 95 received from

Hello

I m getting the following error while using Asterisk :

[Aug 11 22:52:25] NOTICE[31223][C-00000001] res_rtp_asterisk.c: Unknown RTP codec 95 received from '(null)'
[Aug 11 22:52:25] NOTICE[31223][C-00000001] res_rtp_asterisk.c: Unknown RTP codec 95 received from '51.20.189.70:32770'

Version : Asterisk 11.23.0

Peer device : Android phone using Zoiper

About the other thinkgs u asking me, i dont know how to.

here is my configuration :

sip.conf

[general]
transport=udp

friends_internal
type=friend
host=dynamic
context=from-internal
disallow=all
allow=ulaw

user1
secret=pass; put a strong, unique password here instead

user2
secret=pass; put a strong, unique password here instead

user3
secret=pass; put a strong, unique password here instead

extentions.conf

[from-internal]
exten=>6001,1,Dial(SIP/user1,20)
exten=>6002,1,Dial(SIP/user2,20)
exten=>6003,1,Dial(SIP/user3,20)

Please provide the version number of Asterisk, the identity of the peer device, and the SDP exchange from the INVITE or ACK and the corresponding 200 OK for the call leg on which this is occurring. These can be obtained using sip set debug on, with suitable logger.conf settings.

Also please mark configuration files as preformatted text on the forum.

post updated with some needed info

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

1 Like

Seems pretty straight forward. You probably have a codec enabled that is not installed or supported by something. I am guessing g729. Disable that on your trunks and extensions and on asterisk/freepbx.

You need to install the g729 codec separately from the digium site and purchase a license before it will work.

For starters, disable everything codec related except for ulaw on everything everywhere.

This is not due to a missing codec.

During the session setup, the peers tell each other which codecs they will use and assign numbers to them. That it got this far means that all the codecs were recognized, although not necessarily present. What has happened here is that the peer has sent a codec number for which Asterisk has not assigned a number.

At first sight that would be a bug in the peer. However, some versions of Asterisk had problems dealing with peers that propose a value other than 101 for the pseudo codec used represent RFC 2833 telephony events. The questions I was asking were trying to find out if the peer was broken, if this was a version of Asterisk that had broken handling of non-standard RFC 2833 media type numbers. (If Asterisk is the second party to send SDP on a transaction, it will follow the codec numbers used by the first party, but some versions were failing to update its internal list of numbers in this case.)

If the codec was known to Asterisk, but there wasn’t a suitable translator installed, you would have got an “unable to create translation path” error.

Dynamic payloads start at 96, anything below that is supposed to be an assigned one. In this case 95 is unassigned so I’m unaware of what the remote device would be wanting there…

I had this problem using zoiper, the fix for me was turn off Google voice on any screen. It takes over the device microphone. Doing this meant calls worked fine afterwards.

I know this is an old thread but I had found this from Zoiper:

"When using Asterisk, you might see warning messages in the logfile or on the CLI “Unknown RTP codec 95 error”.

You can safely ignore these messages, they are the result of Zoiper sending a fake small packet with rtp codec id 95 for the purpose of opening a NAT binding in case there is a NAT between Zoiper and the server.

This happens immediately after the call is answered, early media starts, or unhold session refresh (if SDP changes).

This should not cause any issues and it there only to speed up the process of the audio flowing in both directions."