[asterisk-bugs] [Asterisk 0011933]: RTCP interferes with Cisco 7940 jitter buffer

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11933 
====================================================================== 
Reported By:                jolan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11933
Category:                   Core/RTP
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-05-2008 15:45 CST
Last Modified:              03-06-2008 14:22 CST
====================================================================== 
Summary:                    RTCP interferes with Cisco 7940 jitter buffer
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
http://bugs.digium.com/view.php?id=359 and
http://bugs.digium.com/view.php?id=873.  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 http://bugs.digium.com/view.php?id=359 and
http://bugs.digium.com/view.php?id=873, 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.
====================================================================== 

---------------------------------------------------------------------- 
 jolan - 03-06-08 14:22  
---------------------------------------------------------------------- 
No ideas from me.  My diff fixes the issue for me. Sorry :( 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-06-08 14:22  jolan          Note Added: 0083554                          
======================================================================