| Summary: | ASTERISK-01570: usleep in rtp.c of 500ms causes audible blip before call is bridged. | ||
| Reporter: | Brian West (bkw918) | Labels: | |
| Date Opened: | 2004-05-09 00:55:46 | Date Closed: | 2008-01-15 14:56:31.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | If you change the usleep to 5000 instead of 50000 the blip is gone. I don't know why we are waiting 500ms here but usleep is blocking at that point and that anoying delay before the call is bridged up. | ||
| Comments: | By: twisted (twisted) 2004-05-09 01:33:59 Attempted to reproduce under various conditions, and was not able to reproduce, not even once. I'm not sure where the problem is, but I can't find anything out of order here. By: Brian West (bkw918) 2004-05-09 01:46:01 I can produce the click, blip every single time. I'm not sure if we need to wait 500ms there or not but that is a noticeable click and sometimes will chop 500ms from the person that answered. bkw By: connor (connor) 2004-05-09 02:28:38 I can reproduce this as well.. and I've brought it to Mark's attention before.. He said some stuff that was way over my head.. but, this needs looked at.. By: Mark Spencer (markster) 2004-05-09 10:33:52 It's there to keep us from sending an invite right away after we just sent the first one. It would take some work in chan_sip to fix that. By: Brian West (bkw918) 2004-05-09 12:16:55 Ok maybe you can explain this to me... I don't see anywhere in there where an invite might or might not be sent... Maybe i'm just missing it. bkw By: connor (connor) 2004-05-24 16:57:08 OKay, we've been running the usleep at 5000 vs 50000 and we had problems with our 7960's sometimes not bridging the channels. (using re-invites) putting a Answer() in the dialplan fixed the problem.. but this REALLY needs to be redone. I upped the 5000 to 10000 and still had the same issue. The usleep simply blocks ALL audio for that 1/2 second making things sound very strange. By: Mark Spencer (markster) 2004-05-27 00:52:01 Fixed in CVS, re-open if it doesnt' work for you. By: Digium Subversion (svnbot) 2008-01-15 14:56:31.000-0600 Repository: asterisk Revision: 3090 U trunk/apps/app_controlplayback.c U trunk/channels/chan_sip.c U trunk/rtp.c ------------------------------------------------------------------------ r3090 | markster | 2008-01-15 14:56:31 -0600 (Tue, 15 Jan 2008) | 2 lines Doc fix for controlplayback, get rid of 500ms wait in rtp.c (bug ASTERISK-1570) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3090 | ||