|Summary:||ASTERISK-07978: After a correct blind/attended transfer audio comes and go leaving audio holes.|
|Reporter:||Chris B. (chrisb)||Labels:|
|Date Opened:||2006-10-23 05:48:32||Date Closed:||2011-06-07 14:02:40|
|Environment:||Attachments:||( 0) Debug.txt|
( 1) exten.conf
( 2) features.conf
( 3) queues.conf
( 4) sip.conf
( 5) zapata.conf
we are facing a strange problem and even if we have updated asterisk more then once, it is still there. So either this is a configuration issue or has not been fixed.
We have asterisk running on a powerful machine with a 410P Digium card and 2 GB of RAM.
We have enabled blind and attended transfer on features.conf and transfers work well. But when the call has been transferred from ISDN to internal extensions, we can hear audio holes and RTP traffic between Asterisk and on field ATA's stop flowing!
Attached our configuration files and a debug of the problem!
On debug file, you can see rtp and sip debug: call has been already trasferred and rtp traffic bidrectional flowing, until stops. And the restart again after about 5 seconds.
****** ADDITIONAL INFORMATION ******
We can say that it is not a network problem since we have a stable 4Mbps connection.
We have performed a loopback test on each port of digium card, all passed successfully.
|Comments:||By: Serge Vecher (serge-v) 2006-10-26 08:23:09|
I have faced a problem with audio problems where RTP traffic was chopped by a SPI firewall.
By: Chris B. (chrisb) 2006-10-30 02:58:12.000-0600
I understand, but this is not my case: ATAs and IPPhones registered to the Asterisk server have no SPI in front of them.
By: Serge Vecher (serge-v) 2006-10-30 12:57:34.000-0600
ok, next question: what modifications have you done to the source code and what happens if you just use a clean 1.2.13 tarball.
By: Chris B. (chrisb) 2006-11-03 05:01:44.000-0600
I had a problem: when users made an attendant/blind transfer to a mobile phone, the time the mobil was ringing was too short. So I've changed the 15000 ms timeout of transfer in 45000 ms timeout in res_features.c. This is the only change I've made on source code.
Where can I find 1.2.13 tarball exactly? I still make a bit of confusion between branches, trunks and so on.
Thank you for your Help.
By: Serge Vecher (serge-v) 2006-11-09 09:34:46.000-0600
>Where can I find 1.2.13 tarball exactly?
By: Chris B. (chrisb) 2006-11-09 10:19:44.000-0600
installed and compiled! Let you know.
By: Chris B. (chrisb) 2006-11-10 08:05:20.000-0600
do you think the problem can be due to mpg123? We had a server with 70% of CPU load (asterisk stopped) while a mpg123 istance was still running. Killed mpg123 the load has decreased to zero.
However we see that after musiconhold is played, asterisk don't close mpg123 and sometime this mpg123 remains as zombie application!
Do you think the cpu overload due to mpg123 affects audio?
What could be the solution?
In the meanwhile we have 1.2.13 running from this morning without problems: if the audio problem comes up again, what kind of the debug you need more?
By: Ronald Chan (loloski) 2006-11-10 08:55:00.000-0600
yes, it's a know problem that's why mpg123 is now deprecated they decide to remove it. what you can do for now is to convert those files into a native format, supported by asterisk. there's a convert utility available at asterisk console to do this if you are in 1.4beta, hope this help
By: Chris B. (chrisb) 2006-11-10 09:45:09.000-0600
I'm a bit afraid of installing a 1.4 beta...this server is in production enviroenment: there's no solution on normal 1.2 to play a MOH?
All this years with audio problems without finding a solution to MOH?
That's impossible: there should exists a solution to this in 1.2 too.
Anyone can help?
By: Ronald Chan (loloski) 2006-11-10 10:07:24.000-0600
I'm not saying you can't use MOH, what i'm trying to say is instead you are using mp3 file format you should convert it to some more asterisk friendly format e.g slinear,wav,gsm,ulaw,alaw whatever available in your asterisk installation.
your_moh.mp3 you should convert it to your_moh.sl,your_moh.wav,your_moh.ulaw etc. etc. then place those converted files to /var/lib/asterisk/moh or wherever you put those moh files.
mpg123 is a known source of asterisk stability issues on 1.2 you can ask on the mailing list also for second opinion.
By: Chris B. (chrisb) 2006-11-13 02:09:00.000-0600
thanks so far. Are you all confidents about a relation between mpg123 and my audio problems during transfer? Or the two issues are not related?
Anyway, now I'm using rawplayer... it takes only a couple of days to verify if this is the right fix.
By: Ronald Chan (loloski) 2006-11-13 08:40:30.000-0600
IMHO yes it could be but i'm not certain, since on my experience if the CPU spikes about 70-80 cpu utilization due to the bug the mpg123 incured i'm experiencing the same behavior as well, IMO gsm/wav49 format would be good.
By: Chris B. (chrisb) 2006-11-14 05:45:20.000-0600
some problem still remains. I often see this message:
Nov 14 12:22:02 NOTICE: res_features.c:1171 ast_feature_request_and_dial: Don't know what to do about control frame: -1
It happens when we use *2 to start an attended transfer.
What does it means? Is it someting related to my audio problem?
By: Ronald Chan (loloski) 2006-11-14 07:28:38.000-0600
Haven't you consider to you the latest SVN branch for 1.2?? maybe that issue has been address there already, please don't use the bug tracker for getting a support, we might get both ourselves kick here since this is not a suitable place to ask for support :)
you can get the latest svn branch for 1.2 by using subversion
svn checkout http://svn.digium.com/svn/asterisk/branches/1.2 asterisk
please connect to irc.freenode.net #asterisk or #asterisk-bugs
By: Chris B. (chrisb) 2006-11-14 10:55:21.000-0600
This is a bug report not a support request. The issue I've reported has not been fixed by suggestions received. I'm using 1.2.13 tarball after serge-v request, once I used 1.2 last branch without luck.
By: Serge Vecher (serge-v) 2006-11-17 11:55:59.000-0600
Ok, let's look at the rtp debug again ... The RTP packets flow nicely, then all of a sudden the packets *from* the client stop and resume after a certain period. Since there is no firewall in between, the logical answer is -- the client is responsible for not sending the packets. Unless you can show that the same happens if you use any other client, I would think this is a client issue.
By: Chris B. (chrisb) 2006-11-20 02:52:07.000-0600
You are right serge.
Thanks for this hint: I feel so stupid I haven't noticed it by myself.
Please close the issue.
By: Serge Vecher (serge-v) 2006-11-20 08:27:18.000-0600
UA issue, not Asterisk -- closing ...