| Summary: | ASTERISK-10428: [patch] New epoll API yields scrambled audio in one way | ||
| Reporter: | phsultan (phsultan) | Labels: | |
| Date Opened: | 2007-10-02 08:01:41 | Date Closed: | 2007-10-02 08:39:09 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/RTP |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) trunk-10867-1.diff | |
| 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 #1) ; - audio from the GoogleTalk client is bad, like scrambled (UDP socket #2). I figured out that UDP socket #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 #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. ****** ADDITIONAL INFORMATION ****** Since epoll is used in SVN trunk, the 1.4 branch is not affected. Also, GoogleTalk sends/receives STUN requests on its RTP sockets, so the problem might be restricted to chan_gtalk and chan_jingle. | ||
| Comments: | By: Digium Subversion (svnbot) 2007-10-02 08:39:09 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 ASTERISK-10428) Reported by: phsultan ------------------------------------------------------------------------ | ||