maemo.org Bugzilla – Bug 6936
Caller voice gets minced after some time when taking call via SIP
Last modified: 2010-06-14 21:57:03 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: Maemo 1.2009.42-11 on Nokia N900 EXACT STEPS LEADING TO PROBLEM: 1. Create a SIP account on the phone 2. Connect to the SIP account (I did via WLAN) 3. Take an incoming call and chat for some time (20 to 30 min) EXPECTED OUTCOME: A smooth conversation. ACTUAL OUTCOME: The opponents voice will be chopped and it will be impossible to understand a word after some time. BUT the caller can clearly understand you and you can tell him to call again. Than the story starts from the beginning. So it's a one way problem. REPRODUCIBILITY: Always EXTRA SOFTWARE INSTALLED: - OTHER COMMENTS: The WLAN connection and SIP connection works flawless using the a Fritz!BOX 7270 with Fritz!Fon or any other fon connected to the box. It suggests a bug in the N900. I connected to a 1und1 VoIP (SIP) Flatrate. (1und1-8.sip.mgc.voip.telefonica.de:5060) dmesg does not show anything related By the way.. where to look for logs? /var/log just contains pycentral.log User-Agent: Opera/9.80 (X11; Linux i686; U; en) Presto/2.2.15 Version/10.20 Cheers Bjoern Olausson
I was on a SIP call for almost an hour, didn't notice any choppiness in the voice. Perhaps it's got to do with your connection (especially when you downloading something) I'm using 2009.42-11 retail.
Can you provide traffic captures? You can use tcpdump from the tools repository. Logs could be made available by installing the sysklogd package. In order to analyze this problem better, make sure to export TPORT_LOG=1 and TPSIP_DEBUG=all in the device environment (/etc/osso-af-init/af-defines.sh is a good place to export them).
(In reply to comment #2) > Can you provide traffic captures? You can use tcpdump from the tools > repository. > > Logs could be made available by installing the sysklogd package. > In order to analyze this problem better, make sure to export TPORT_LOG=1 and > TPSIP_DEBUG=all in the device environment (/etc/osso-af-init/af-defines.sh is a > good place to export them). > Thanks for the advice, I'll investigate into this. For now I could reproduce the behaviour three times after the third time I was pissed off so i used my Fritz!Fon to take the call from a friend (nothing did change in the environment during these four calls) and everything was fine. I'll post my result as soon as possible. Cheers Bjoern
Interestingly i have the reverse bug, stopping me from answering my SIP at home with my N900...(and it doesn't seem time related at all) I can here the opponent very well but my own voice gets really choppy. Even locally on an echo test with asterisk, as if there was some kind of noise cancellation running amok... Saying "AAAAAAAAAAAA" results in hearing "AAAaaa-._AAAaaa-._" Asterisk 1.6.2.0~rc7-1 (Debian) It's particularly weird as i have SPA2102 ATA around with older typical phones connected to them without this issue. A friend of mine is having the same issue... Is anyone experiencing this? On the N900 I have Transport to Auto, discover public address and loose routing off, keep-alive mechanism/period to auto and auto-detect STUN checked. And on the sip.conf side: [n900] type=friend defaultuser=n900 md5secret=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx qualify=yes canreinvite=no dtmfmode=rfc2833 host=dynamic context=iax nat=yes callerid=xxxx@xxxx.xxxx.xx <xxxxxxxxxx> mailbox=xxxx@default allow=gsm,ulaw,alaw,h263,g729
I had no time jet to investigate further, but I'll keep an ear on both sides of communication. Actually I hope to do the tests on this weekend, otherwise it will first happen in the second week of 2010 :-) *holidays are coming* *sing* Cheers Bjoern
We're investigating a similar problem reported internally, but I'd need packet captures to tell if it's really the same.
Created an attachment (id=1798) [details] tcpdump -nnvvXS (normal - minced - recovered) Okay, right now I am on it. 30 minutes ago I got a call from a friend and it was minced right when I took the call. Now I have set up a test environment. Mobile phone calling N900 on VoIP account. First attempt: The first few minutes were okay. Then again the voice (actually music) got minced but recovered after a few minutes. I captured this with "tcpdump -nnvvXS | tee dump.log". Now running another test (since 20 minutes). The environment dit not change, no distortion so far (dump2.log). This bug turns out to be a nasty one cause I don't know how to reproduce it reliable. But I never observed such a behavior when using the phones connected to the Fritz!Box 7270 Please find the logs attached to this bug. Kind regards Bjoern
Created an attachment (id=1799) [details] tcpdump -nnvvXS (longrun no-distortion) No distortion on this run. Might be interesting to compare those two files. Cheers Bjoern
Oh, I forgot to mention: The second attachement is a bziped tar archive (dump2.log.tar.bz2). Just in case anyone is wondering. Sorry. Kind regards Bjoern
*** Bug 7302 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
I can confirm that choppy audio problem present on n900, at least using it with asterisk pbx v. 1.6.1. With same setings and same dialplan nokia e75 and e71 works great, while on n900 i getting choppy audio. i have tried various settiong on nokia and asterisk and i have tried different codecs. so often quality of speech is unacceptable and actually i am using n900 only for testing, if i want to accept incoming call, i am using gtalk or skype/asterisk (but there i cannot set callerid and do not know, who calling me)
Cannot edit this, but i should add too: I am receiving choppy voice always with this code (which should playback clear voice message before action). exten => _X!,1,Playback(long-duration-message,noanswer) exten => _X!,n,Dial(SIP/trunk/${EXTEN},40,t) exten => _X!,n,Hangup So, by using e75, everything is fine, and on n900: 1. Playback are always choppy 2. Ringback signal during dial are choppy often 3. After answer, call speech voice are choppy sometimes, but too often, getting choppy audio at X-th second/minute of talk and in some time (10-20 seconds), voice becoming normal and i can continue talking. Again, i have tested different trunks too.
This has been fixed in telepathy-sofiasip 0.5.19-0maemo3. Closing after this has been internally released.
my call gets choppy sometimes with skype. is this the same bug or should I file a new one?
(In reply to comment #15) > my call gets choppy sometimes with skype. is this the same bug or should I file > a new one? > Good question, as I observed the same. Choppy in both ways, with SIP and SKYPE. You could search for an existing bug, if there is none, open a new one (you might add me to the CC list when you create a new one) Cheers Bjoern
The fix for SIP ptime issue is nearing completion.
I have the same BUG as reported. I urge for a sollution. Please give me un solution since this was the main reason for buying this expencive phone
trajceski: This is not a discussion forum. If your comment doesn't add any valuable new information, please go to http://talk.maemo.org for general discussion, and/or click "Vote for this bug" here instead of adding a "me too" comment. This helps keep developers developing (and fixing) instead of reading mail.
the choppyness of skype on my phone was due to a misconfigured router at my job. I reset it and now skype works fine :)
(In reply to comment #20) > the choppyness of skype on my phone was due to a misconfigured router at my > job. I reset it and now skype works fine :) Thanks for following up. Now we're down to the SIP problem which we have hopefully fixed, pending a public release.
This has been fixed in the internal build version 2010.05-2 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
Well, just upgraded to PR1.2 and did a quick echo test: Saying: AHHHHHHHHHHHHHHH I got: AHHHhh...Ahhhh...ahh... in return. Problem must be somewhere else i guess!? :/
(In reply to comment #24) > Well, just upgraded to PR1.2 and did a quick echo test: > > Saying: > AHHHHHHHHHHHHHHH > I got: > AHHHhh...Ahhhh...ahh... > in return. > > Problem must be somewhere else i guess!? :/ > Arrrg, I hope you are fooling around! I was so desperately looking forward to 1.2 because of this Bug as this was my main reason for buying this phone! Well, Germany gets the update today (I hope) and I'll test against this bug... for sure. Desperate... Bjoern
(In reply to comment #24) > Well, just upgraded to PR1.2 and did a quick echo test: > > Saying: > AHHHHHHHHHHHHHHH > I got: > AHHHhh...Ahhhh...ahh... > in return. Did you try it with the handset speaker, headset, or the loudspeaker? If the latter, echo cancellation can produce this effect. A proper test is a two-way call where two parties are acoustically isolated.
I'll try to retest with someone later on but some people apparently don't have this problem with the asterisk 1.4.x branch while i use 1.6.2... So it might be a weird setting problem on asterisk / debian's part.
(In reply to comment #26) > (In reply to comment #24) > > Well, just upgraded to PR1.2 and did a quick echo test: > > > > Saying: > > AHHHHHHHHHHHHHHH > > I got: > > AHHHhh...Ahhhh...ahh... > > in return. > > Did you try it with the handset speaker, headset, or the loudspeaker? If the > latter, echo cancellation can produce this effect. > A proper test is a two-way call where two parties are acoustically isolated. > I have just upgraded to PR1.2. I am using the provider called "naglos". Sometimes I get a good call quality, but most of the time the sound is so choppy, that I hear half of the initial message. Ekiga from the PC works perfectly at the same network.
Tried with pbxes.org and still have the same problem calling *43 and other. Using twinkle or my old E60 I experience no choppy audio. Please note that putting the call on hold fixes the choppy audio temporarily. Also I noticed a "Internal GStreamer error: clock problem." message in syslog output but don't know if this could cause such symptoms. I'll attach my syslog output.
Created an attachment (id=2765) [details] syslog with TPSIP_DEBUG=all and TPORT_LOG=1
My first test yesterday resulted in the same error, but this was only one shot and is therefore not really representative. I was using 1und1 as VoIP provider, connected via WLAN. I'll do some more testing and digging in the logs/tcpdump... So this is how industry level development/communication with the community works... I am kinda impressed... *sigh* Cheers Bjoern
(In reply to comment #30) > Created an attachment (id=2765) [details] [details] > syslog with TPSIP_DEBUG=all and TPORT_LOG=1 Thanks. This time, it does not seem to be the ptime issue, but the codec chosen is iLBC. We had some issues with the iLBC codec that were considered fixed, so it's bad news that they still occur. This should be reported as a different bug (to Platform/Multimedia). Interestingly, your session offer omits PCMU and PCMA codecs; did you disable them somehow? If the gateway selects a PCM codec, is the problem reproducible?
Jehan: Please move comment 30 and answers to the questions in comment 32 to a new bug report. Thanks.
Okay, after some more testing with 1und1 as VoIP provider I couldn't reproduce the bug. The tests were done via a WLAN connection. I'll try with a direct mobile connection tomorrow. Thanks Bjoern
I also have a very choppy voice with sip after running for few minutes. I have PR 1.2 on the phone. The audio call was between N900 and N95 through my own asterisk server Asterisk 1.6.1.10. The codec used was G729. I have attached the syslog for the session.
Created an attachment (id=2788) [details] syslog for a session using G729
(In reply to comment #35) > I also have a very choppy voice with sip after running for few minutes. I have > PR 1.2 on the phone. The audio call was between N900 and N95 through my own > asterisk server Asterisk 1.6.1.10. The codec used was G729. I have attached the > syslog for the session. Can you configure a different codec than G.729 and see if the problem persists?
This also happens with PCMU codec. Please notice bug #10388.
I have noticed, that the problem is with the SPEEX codec at 8000 Hz. Switching the codec in /etc/stream-engine/gstcodecs.conf fixes the problem.
Switching the codec to 16000 Hz.
I was hping the problem woul disappear with PR 1.2, I still have the situation I don't hear the other part for a while while they hear me. I know replace 8000 with 16000 in /etc/stream-engine/gstcodecs.conf an hope this helps.
Unfortunately I can't test SPEEX with 16000 Hz since pbxes.org seem not to support it - anyway switching iLBC to 16000 Hz didn't help.
Mmmh, i run into another problem... when making a VoIP call from my n900 to a landline the other person will here me but all I can hear is silence. All other tests where done with incoming calls. Anyone with the same problem? Again, all tests were done with 1und1 voip (sip.1und1.de) Cheers Bjoern
I tested with PCMU codec today over wifi and had the same problem. Can the devs please let us know what codec they use for testing? I would like to test with that. Can this bug be re-opened?
I have been experiencing the problem described here, I can also confirm that the 1.2 update did not fix the problem. I'm using an N900 device. On our network PCMU is the default, PCMA and GSM are available if the client requests it. If there is any other information I can provide to help here let me know.
(In reply to comment #27) > I'll try to retest with someone later on but some people apparently don't have > this problem with the asterisk 1.4.x branch while i use 1.6.2... > So it might be a weird setting problem on asterisk / debian's part. > I downgraded to asterisk 1.4.22.1 from 1.6 and the problem persists. Calls get minced after 2 minutes.
Also wanted to add that the choppiness was from asterisk to N900. The remote device is as Linksys PAP2 ATA, with an RTP Packet Size = 0.020 and Network Jitter Level=high. Wifi is set to WPA2 with maximum power-saving.
PR1.2 ended up being much better for me... I had a long conversation and test from wifi at remote location connecting me back home and had quite good results every time. Only the local echo seems to have a weird interaction with maybe the noise cancellation (even though I'm not on the speakerphone). So if this can help, here is how my user look like in asterisk 1.6.2.7: [user] type=friend defaultuser=user md5secret=... qualify=yes canreinvite=no dtmfmode=rfc2833 host=dynamic context=voipprovider nat=yes callerid=me@some.dyndns.com <5555555555> mailbox=555@default allow=gsm,ulaw,alaw,h263,g729
@Mikhail, I have sent you an email with the tcpdump capture of a call which got minced after a few minutes. I didnt post it here as the file might have sensitive information in it. Hope it might be helpful.
(In reply to comment #49) > @Mikhail, I have sent you an email with the tcpdump capture of a call which got > minced after a few minutes. I didnt post it here as the file might have > sensitive information in it. Thank you. Please follow this issue under bug #10388, this bug is resolved because it originally exposed a different problem.