[asterisk-bugs] [Asterisk 0010867]: [patch] New epoll API yields scrambled audio in one way

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10867 
====================================================================== 
Reported By:                phsultan
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10867
Category:                   Core/RTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 84361 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-02-2007 08:01 CDT
Last Modified:              10-02-2007 08:39 CDT
====================================================================== 
Summary:                    [patch] New epoll API yields scrambled audio in one
way
Description: 
Using Asterisk SVN trunk, a call from a GoogleTalk client to a SIP gateway
has the following symptoms :
- audio from the SIP gateway to the GoogleTalk client is fine (UDP socket
http://bugs.digium.com/view.php?id=1) ;
- audio from the GoogleTalk client is bad, like scrambled (UDP socket
http://bugs.digium.com/view.php?id=2).

I figured out that UDP socket http://bugs.digium.com/view.php?id=2 on Asterisk
has a reception queue filled
with packets which are not processed. The queue seems to be flushed when
receiving audio on UDP socket http://bugs.digium.com/view.php?id=1 (eg. from the
SIP gateway), which makes it
practically impossible to have a correct conversation.

It turned out that SVN trunk revision 78683 introduced this problem. I
attach a patch that makes file descriptors available to both channels in
rtp.c, which sovled my problem. I'm really not sure it is the right way to
do it though, this is why I'm submitting the bug to the community, more
precisely to file ;)

Josh, can you give your advice on that please? My knowledge in the epoll
API is limited, and I don't want to mess your work.
====================================================================== 

---------------------------------------------------------------------- 
 svnbot - 10-02-07 08:39  
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 84368

U   trunk/main/rtp.c

------------------------------------------------------------------------
r84368 | file | 2007-10-02 08:39:08 -0500 (Tue, 02 Oct 2007) | 4 lines

Don't swap channel priority if using epoll as polling should/will only
happen off the first channel.
(closes issue http://bugs.digium.com/view.php?id=10867)
Reported by: phsultan

------------------------------------------------------------------------ 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-02-07 08:39  svnbot         Note Added: 0071304                          
10-02-07 08:39  svnbot         Status                   new => assigned     
10-02-07 08:39  svnbot         Assigned To               => file            
======================================================================