|Summary:||ASTERISK-01556: VoiceTronix Interface driver|
|Date Opened:||2004-05-07 13:00:07||Date Closed:||2011-06-07 14:05:20|
|Environment:||Attachments:||( 0) atach.txt|
( 1) patch.txt
|Description:||After chan_vpb was completely updated at the beginning of April, the following problem arose. If people call PSTN via vpb, sometimes the PSTN party&ASTERISK-7996;s voice gets interrupted.|
And when one connects to us through IAX2 and then to PSTN via vpb, then the sound tends to be off right from the start only to break through later at times.
Exploring and debugging the chan_vpb code has revealed that frames are not enqueued in the second case (IAX2).
Please see the code: atach.txt
To my mind, trylock must not be used here, since, if the resource is already locked, the code goes on being executed through the next data reading cycle, without enqueuing the frames read in the current cycle, i.e. the data will be lost.
If only lock is used, this results in a deadlock, according to the code.
I&ASTERISK-7996;ve gotten over the problem by making these changes: atach.txt
This solution works successfully at present. I think there could be other solutions as well.
****** ADDITIONAL INFORMATION ******
cvs last update
OS - linux Slackware 9.1 (kernel 2.4.26)
|Comments:||By: twisted (twisted) 2004-05-08 00:31:35|
Please provide the patch it it's own unified diff. Thanks.
By: Brian West (bkw918) 2004-05-08 00:50:58
I have sent notice to the guy that mantains this channel driver for us.
By: Brian West (bkw918) 2004-05-09 19:42:22
Using cvs head or stable?
By: VoiceTronix (benkramer) 2004-05-09 23:36:22
progman, before I can apply the patch I need the information as requested above:
Asterisk version - devel or stable
a unified diff, eg cvs diff -u chan_vpb.c
By: progman (progman) 2004-05-11 12:21:51
1) Asterisk version - last cvs update (today)
2) Patch is atached. But unfortunately this solution is not quite stable. In certain cases, and it is not yet clear in which cases exactly, a deadlock occurs and then one of the vpb channels remains "up". This does not happen under various tests. :(
By: Mark Spencer (markster) 2004-05-11 22:59:57
This problem has had to be solved for the other channel drivers, so here's what you do.... When you have the channel lock (e.g. in one of the callback routines) you can safely grab the private lock.
If you have the private lock, and need the channel lock, you need to be careful (see how it's done in IAX2 and on SIP).
By: Mark Spencer (markster) 2004-05-19 10:42:36
Any update here?
By: progman (progman) 2004-05-19 11:45:32
Testing on vpb stoped, for now.
Now we trying TDM cards with FXO ports.
By: Malcolm Davenport (mdavenport) 2004-05-26 15:41:52
Closing unless someone decides they want to reopen. Find a bug marshall on IRC if you need it reopened.