Summary:	ASTERISK-04800: RTCP and NAT issue
Reporter:	Herve JOURDAIN (hjourdain)	Labels:
Date Opened:	2005-08-15 06:08:19	Date Closed:	2011-06-07 14:02:52
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) rtp.c.diff
Description:	I have discovered, and solved (OK, just 1 line...), an issue that's normally harmless, but that can be very disruptive under some conditions, about the handling of RTCP with NAT enabled. In fact, there is a bug in rtp.c, where when you receive a RTCP packet it's the RTP "them" that's updated, not the RTCP "them"! The impact is that after receiving a RTCP packet when in NAT, the next RTP packet will be sent to the RTCP port, not the RTP port, of the peer!!!! Usually, it's not an issue, as you're supposed to receive a RTP packet within the next 20 ms, so everything goes back to normal quite fast, and is not noticeable. But if you happen to work with an equipment generating VAD/CNG, and there is no voice detected, the peer will send CNG packets - not fully handled yet, I noticed - every several seconds (in my case, every 4 seconds). The consequence is that if you're working in this environment (NAT ON, CNG activated) ASTERISK will send voice to the RTP port for 4 seconds, and to the RTCP port for 4 seconds! Which makes it quite unusable and severe then...
Comments:	By: Olle Johansson (oej) 2005-08-15 06:53:02 Have you sent a disclaimer? By: Herve JOURDAIN (hjourdain) 2005-08-15 08:00:09 [oej] I guess not... Is there a way to do it on a per-patch basis, as I might not be a big fan of this disclaimer, but for issues such as this one I guess it will be fine with me By: Mark Spencer (markster) 2005-08-15 23:22:14 This was already solved in CVS head several days ago, but was the source of a very serious problem for one customer! By: Russell Bryant (russell) 2005-08-26 12:54:35 backported fix that went into cvs