Summary:	ASTERISK-11384: RTCP interferes with Cisco 7940 jitter buffer
Reporter:	jolan (jolan)	Labels:
Date Opened:	2008-02-05 15:45:51.000-0600	Date Closed:	2011-06-07 14:08:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) rtcp_cisco_7940.pcap ( 1) rtcp_disable_diff.txt
Description:	I have reason to believe that the RTCP packets that Asterisk sends out cause an error with the Cisco 7940 jitter buffer. The simple test case I have been using is two Cisco 7940 phones registered to asterisk-1.4.18-rc8 (reproduced with 1.6.0-beta2 as well) with the following sip.conf options: nat=yes type=friend host=dynamic canreinvite=no qualify=yes When, i.e. extension 100 calls extension 101, audio will work fine until an RTCP packet is sent.  Then extension 101 will lose audio for 1-2 seconds.  After searching around we found the Cisco issue CSCdz52758 which reads: Cisco IP Phone displays a huge MaxJtr value on the Call Statistics           screen and the RxDisc value changes from 0000. The audio may cut out         for a period of 1 or 2 seconds. This issue is marked as resolved in the call manager firmware but we believe the problem is still present in the SIP firmware.  I have reproduced the issue with versions 7.5, 8.7, and 8.8 of the SIP firmware. Further searching revealed the root cause on this issue: Phone displays huge MaxJtr value when RTP SSRC ID and Timestamp change. The 1-2 second audio loss that I see happens right after the RTCP packet hits the phone. I have a capture which I will attach to the bug.  Some example packets (as numbered by wireshark) from the capture are ASTERISK-356 and ASTERISK-867.  The SSRC, timestamp, and sequence number are all different from the audio stream. I am not sure if this is problem is caused by an asterisk bug, a Cisco 7940 firmware bug, or if it is a simple interoperability issue. However, there is definitely at least one bug in the RTCP code.  If you look at packets ASTERISK-356 and ASTERISK-867, the sequence number is 12 for both packets.  If the SSRC/timestamp/sequence number for the RTCP packet does not need be the same as the audio stream's, then I would imagine that the RTCP sequence number should at least increase. I have confirmed that disabling the transmission of RTCP packets fixes the problem (as does downgrading to asterisk 1.2.x which does not have RTCP support).  However, I have not pinpointed if it is the different SSRC, different timestamp, or different sequence numbering that triggers the problem on the Cisco 7940.
Comments:	By: Douglas Gillespie (douglasg) 2008-03-06 09:11:07.000-0600 I am having the same problem I rolled back to 1.2 and the problem went away.  However when I applied your patch to 1.4 it did not correct the problem.  Any ideas?  thanks.. By: jolan (jolan) 2008-03-06 14:22:29.000-0600 No ideas from me.  My diff fixes the issue for me. Sorry :( By: Joshua C. Colp (jcolp) 2008-05-28 10:46:23 After looking at things and the changes done some stuff I reverted would have fixed this.