[chandave]

Originally Posted by thameema

Another problem i have is, most of the times i m getting the following lines in my asterisk log.

Aug  2 20:22:28 NOTICE[2772]: rtp.c:515 ast_rtp_read: Unknown RTP codec 72 received
Aug  2 20:22:29 NOTICE[2772]: rtp.c:515 ast_rtp_read: Unknown RTP codec 72 received
Aug  2 20:22:34 NOTICE[2772]: rtp.c:515 ast_rtp_read: Unknown RTP codec 72 received

I might be able to shed some light on the RTP codec message.

I, too, get these messages on my Asterisk console. I've looked into the code for the problem and it might have to do with RTCP packets in the RTP voice data stream.

Here's my take on it.

Normal VOIP using 2 RTP data streams and 2 RTCP datastreams for voice traffic. Each RTP and RTCP datastream is normally unidirectional. So, when you initiate a call, you tell the remote end which IP and UDP port you are listening on for voice traffic TO your machine. The remote end will also tell you which IP and UDP port you should send your voice traffic to in order for them to receive it. These are the unidirectional RTP data streams.

In addition to the RTP streams, are the RTCP data streams that provides statistics and synchronization info (used, for example, when you have DTMFmode=rfc2888, to coordinate the DTMF tone and the SIP INFO packet representing the DTMF tone). These data streams are usually setup separate from the RTP streams (i.e. 2 more UDP ports are used).

This changes with Symmetric RTP. Symmetric RTP abandons the use of separate RTP streams. When you make a call, you establish an RTP data stream for voice traffic to the remote end. The remote end is suppose to use that same RTP data stream to send voice traffic back to you.

Most VOIP implementations use Symmetric RTP to work around problems with Network Address Translation (NAT) systems and troublesome Firewalls.

How does this affect you?

It looks like some SIP UA implementations inject RTCP packets into the Symmetric RTP datastream. As a result, you get the "Unknown RTP codec 72 received" message on the Asterisk console. I believe the codec 72 is really an RTCP "Sender Report" (Payload type 200) with the high-order bit masked off ( 200 - 128 = 72).

I believe your XTen client has Symmetric RTP support enabled. As a result, it is sending it's RTCP "Sender Reports" back to Asterisk using the same RTP data stream as your voice traffic. Asterisk doesn't understand the RTCP packet that appears to be announcing itself as an RTP with a payload type 72 and ignores the packet.

Why this is degrading your BV connection is a mystery. I can only tell you that I get the NOTICE messages but my audio quality does not degrade.

In my sip.conf entry for BV, I use "NAT=no" and I port forward on my NAT devices. Contrary to expected meaning, "NAT=no" does not turn off NAT support (Asterisk's behavior of using externip in the SIP messages). Instead, this only disables Symmetric RTP for the connection.

You might want to try turning off Symmetric RTP support on the XTen and just use STUN to open up the pinholes in your firewall.

See ya...

d.c.

[thameema]

Thanks chandave. You are the man. Now I am clear about the error message. Your answer raises two questions. First, when you said turn off Symmetric support in xten, i went to Xten menu > Advanced Settings > RTP Settings > Send RTCP messages = NO. Is this the right way to turn off symmetric support?
Second question. If i want to use STUN server, Can i use any stun server available like stun.fwdnet.net:3872 or Do I need to run my own STUN in my asterisk box or somewhere?

[chandave]

I would suggest you start by turning off the RTCP messages. That might just remove all the "Unknown RTP codec type 72 received" messages.

To turn off Symmetric RTP, I think the setting is in Main Menu > Advanced System Settings > RTP Settings > Obey Reverse UDP Mapping Rules = NO.

You might also encounter another "Obey Reverse UDP Rules" in Main Menu > Advanced System Settings > SIP Settings > Obey Reverse UDP Rules". DO NOT SET THIS TO "NO" IF YOUR DESIRE IS TO DISABLE SYMMETRIC RTP. This setting controls how SIP_REGISTER, SIP_INVITE, SIP_ACK, SIP_BYE, SIP_OPTIONS, etc are sent to the SIP proxy and registrar.

For STUN servers, it does not matter which to use. It only matters that the STUN server can reliably be reached. You can run your own if you feel that FWD's STUN is too overloaded. VOIP-INFO.ORG has a list of publicly accessible STUN server. Just search for STUN.

See ya...

d.c.

[thameema]

You are great. It works without any noise problems. I did exactly what you have told and it solved my problem.


I am using FWD STUN and I am not sure how to check the load on FWD stun server. If anybody knows how and whats the impact on using public stun server that would be more helpful.

[mberlant]

If you read one of the threads here that describes the function of a STUN server you will see that a STUN server enjoys a very low workload, much like a time server.