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 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).

(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

Comment 6 Mikhail Zabaluev 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.

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.

Comment 14 Andre Klapper 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.

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

Comment 17 Mikhail Zabaluev 2010-01-21 18:33:47 UTC

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

Comment 19 Andre Klapper 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.

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 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 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 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).

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

Comment 26 Mikhail Zabaluev 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.

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

Comment 32 Mikhail Zabaluev 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 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.

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

Comment 37 Mikhail Zabaluev 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?

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.

Comment 50 Mikhail Zabaluev 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.