Bug 6936 - (int-148396) Caller voice gets minced after some time when taking call via SIP
(int-148396)
: Caller voice gets minced after some time when taking call via SIP
Status: RESOLVED FIXED
Product: Chat & Call & SMS
SIP
: 5.0/(1.2009.42-11)
: All Linux
: Unspecified normal with 23 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: rtcomm@maemo.org
: sip-bugs
:
:
:
: int-153993
  Show dependency tree
 
Reported: 2009-12-13 23:46 UTC by Bjoern Olausson
Modified: 2010-06-14 21:57 UTC (History)
19 users (show)

See Also:


Attachments
tcpdump -nnvvXS (normal - minced - recovered) (912.54 KB, text/plain)
2009-12-18 22:32 UTC, Bjoern Olausson
Details
tcpdump -nnvvXS (longrun no-distortion) (252.74 KB, application/x-bzip2)
2009-12-18 22:39 UTC, Bjoern Olausson
Details
syslog with TPSIP_DEBUG=all and TPORT_LOG=1 (51.48 KB, text/plain)
2010-05-28 13:24 UTC, Jehan
Details
syslog for a session using G729 (14.06 KB, text/plain)
2010-05-31 12:36 UTC, Rajil Saraswat
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Bjoern Olausson (reporter) 2009-12-13 23:46:27 UTC
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
Comment 1 Venomrush 2009-12-14 13:06:04 UTC
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.
Comment 2 Mikhail Zabaluev nokia 2009-12-14 13:17:19 UTC
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).
Comment 3 Bjoern Olausson (reporter) 2009-12-14 14:58:08 UTC
(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
Comment 4 totalworlddomination 2009-12-17 08:36:51 UTC
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
Comment 5 Bjoern Olausson (reporter) 2009-12-17 11:09:52 UTC
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
Comment 6 Mikhail Zabaluev nokia 2009-12-17 11:20:26 UTC
We're investigating a similar problem reported internally, but I'd need packet
captures to tell if it's really the same.
Comment 7 Bjoern Olausson (reporter) 2009-12-18 22:32:08 UTC
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
Comment 8 Bjoern Olausson (reporter) 2009-12-18 22:39:01 UTC
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
Comment 9 Bjoern Olausson (reporter) 2009-12-23 15:15:06 UTC
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
Comment 10 Olivier Crête 2009-12-28 19:34:48 UTC
*** Bug 7302 has been marked as a duplicate of this bug. ***
Comment 11 Alexander 2009-12-29 00:19:57 UTC
*** This bug has been confirmed by popular vote. ***
Comment 12 Andrius 2010-01-05 11:22:13 UTC
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)
Comment 13 Andrius 2010-01-05 11:36:42 UTC
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.
Comment 14 Andre Klapper maemo.org 2010-01-11 11:19:29 UTC
This has been fixed in telepathy-sofiasip 0.5.19-0maemo3.
Closing after this has been internally released.
Comment 15 Shawn Vega 2010-01-13 20:17:45 UTC
my call gets choppy sometimes with skype. is this the same bug or should I file
a new one?
Comment 16 Bjoern Olausson (reporter) 2010-01-13 20:22:17 UTC
(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
Comment 17 Mikhail Zabaluev nokia 2010-01-21 18:33:47 UTC
The fix for SIP ptime issue is nearing completion.
Comment 18 trajceski 2010-01-27 19:25:57 UTC
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
Comment 19 Andre Klapper maemo.org 2010-01-27 19:57:47 UTC
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.
Comment 20 Shawn Vega 2010-01-30 14:12:24 UTC
the choppyness of skype on my phone was due to a misconfigured router at my
job. I reset it and now skype works fine :)
Comment 21 Mikhail Zabaluev nokia 2010-02-01 13:51:10 UTC
(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.
Comment 22 Andre Klapper maemo.org 2010-02-02 13:36:42 UTC
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/
Comment 23 Andre Klapper maemo.org 2010-03-15 20:52:11 UTC
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).
Comment 24 totalworlddomination 2010-05-26 09:46:43 UTC
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!? :/
Comment 25 Bjoern Olausson (reporter) 2010-05-26 10:26:46 UTC
(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
Comment 26 Mikhail Zabaluev nokia 2010-05-26 11:42:35 UTC
(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.
Comment 27 totalworlddomination 2010-05-26 18:14:53 UTC
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.
Comment 28 gwjgwj 2010-05-27 18:18:12 UTC
(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.
Comment 29 Jehan 2010-05-28 13:19:29 UTC
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.
Comment 30 Jehan 2010-05-28 13:24:24 UTC
Created an attachment (id=2765) [details]
syslog with TPSIP_DEBUG=all and TPORT_LOG=1
Comment 31 Bjoern Olausson (reporter) 2010-05-28 13:36:25 UTC
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
Comment 32 Mikhail Zabaluev nokia 2010-05-28 13:55:01 UTC
(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?
Comment 33 Andre Klapper maemo.org 2010-05-28 14:02:44 UTC
Jehan: Please move comment 30 and answers to the questions in comment 32 to a
new bug report. Thanks.
Comment 34 Bjoern Olausson (reporter) 2010-05-29 04:10:37 UTC
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
Comment 35 Rajil Saraswat 2010-05-31 12:35:36 UTC
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.
Comment 36 Rajil Saraswat 2010-05-31 12:36:40 UTC
Created an attachment (id=2788) [details]
syslog for a session using G729
Comment 37 Mikhail Zabaluev nokia 2010-05-31 15:30:23 UTC
(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?
Comment 38 Jehan 2010-06-01 18:21:06 UTC
This also happens with PCMU codec.
Please notice bug #10388.
Comment 39 gwjgwj 2010-06-01 22:16:09 UTC
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.
Comment 40 gwjgwj 2010-06-01 22:18:06 UTC
Switching the codec to 16000 Hz.
Comment 41 Reto Bachmann-Gmür 2010-06-02 21:26:16 UTC
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.
Comment 42 Jehan 2010-06-03 00:30:52 UTC
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.
Comment 43 Bjoern Olausson (reporter) 2010-06-03 10:29:53 UTC
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
Comment 44 Rajil Saraswat 2010-06-06 12:55:33 UTC
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?
Comment 45 Josh Aas 2010-06-10 00:32:20 UTC
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.
Comment 46 Rajil Saraswat 2010-06-10 19:31:41 UTC
(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.
Comment 47 Rajil Saraswat 2010-06-10 22:19:10 UTC
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.
Comment 48 totalworlddomination 2010-06-11 00:08:51 UTC
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
Comment 49 Rajil Saraswat 2010-06-11 19:40:17 UTC
@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.
Comment 50 Mikhail Zabaluev nokia 2010-06-14 21:57:03 UTC
(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.