no incoming sound

[GoogleCodeExporter]

What steps will reproduce the problem?
1.no incoming sound 
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

2.2 android
Please provide any additional information below.

I use galaxy i9000 on wifi works well on 3 g   ican call other party hear me 
i cant hear the other party tried stun doesnt help to resolve
the problem

Original issue reported on code.google.com by yosef.d...@gmail.com on 2 Feb 2011 at 3:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sorry I didn't see your mail. I'll investigate thanks for logs ;)

Original comment by r3gis...@gmail.com on 2 Feb 2011 at 10:36

• Changed state: New

[GoogleCodeExporter]

I & others using my ISP have been experiencing this issue for quite a while. It 
seems to be quite a random thing. 
From my point, i am using huawei u8150 phone with Android 2.2 froyo.
Here is a link to a little information posted on my isp user forum
https://forum.exetel.com.au/viewtopic.php?f=308&t=37609

Original comment by baldrick...@gmail.com on 3 Feb 2011 at 6:24

[GoogleCodeExporter]

What could be interesting would be to reduce number of codecs activated in 
CSipSimple configuration which will reduce packets size. (long press on a codec 
row to deactivate)

I don't think that's the root of this problem but could be interesting to test.

Original comment by r3gis...@gmail.com on 3 Feb 2011 at 9:10

[GoogleCodeExporter]

I actually already have reduced to only use 2 codecs as pcma & pcmu a long time 
back. ( This is the case for both narrow & wideband set up )
Also forgot to mention before, my connections for fixed adsl & WBB both use 
static IP addresses from my provider. The adsl is nat'd but the wirelessBB is 
not. Using STUN, ICE or both makes no difference. my provider also supplies the 
SIP service we are using and have no port blocking for voIp as they are 
actively encouraging us to use their voip service & in fact have written their 
own app for use on iphones.
Also while i think of it, your CSipsimple application is by far the best mobile 
Sip client I have tried to date. If this little nag could be fixed it would 
wonderful.

Original comment by baldrick...@gmail.com on 3 Feb 2011 at 9:48

[GoogleCodeExporter]

Hi, Managed to catch this error into a log which I have now forwarded to your 
'developers address.
Hope this helps.

Original comment by baldrick...@gmail.com on 10 Feb 2011 at 11:29

[GoogleCodeExporter]

i tried to canel the other codecs and it didnt work still dont have incoming
sound,on siproid it works fine withiut problem.but i prefer csipsimple
please help me to resolve this issue

Original comment by yosef.d...@gmail.com on 11 Feb 2011 at 7:40

[GoogleCodeExporter]

Any resolution to this?  I see the exact same problem with Sipgate, showing no 
incoming audio.  Strangely, the Sipgate echo test line works fine.

Original comment by sata...@gmail.com on 10 Jun 2011 at 1:37

[GoogleCodeExporter]

I have the same problem on Sipgate.de

What happens is as follows:

ON AN INCOMING CALL:
- no incoming audio from the caller
- outgoing audio from my side works (ie. the caller can hear me).

ON AN OUTGOING CALL:
- both sides audio works.

This is on a HTC Sensation using the gingerbread daily build (7/21).

Original comment by gurur...@gmail.com on 22 Jul 2011 at 8:03

[GoogleCodeExporter]

I have this same problem even when using WiFi, and the problem did not occur 
when I first installed the application (i.e. everything used to work fine).  

I have updated, but unfortunately I do not recall what the old (working) 
version was or precisely when the problem started.  To reiterate, I have 
acceptable audio on outgoing calls, but for incoming calls I cannot hear 
anything, however apparently the incoming caller can hear me.  

This is on a Nexus one running CM7.

Original comment by gregory....@gmail.com on 5 Aug 2011 at 3:34

[GoogleCodeExporter]

According to the FAQ, the problem with lost incoming audio can be fixed with a 
STUN server.  Has anyone tried setting up STUN and seeing if it resolves this 
issue?

Original comment by gurur...@gmail.com on 5 Aug 2011 at 3:43

[GoogleCodeExporter]

@guru : if incoming and outgoing does not behaves the same way it could also be 
linked to the codec negociation.
So servers does not support very well codec renegociation and it may lead to 
receive audio in a codec not expected by the application.
To check if this is the problem, a good test is to disable all codecs but PCMU 
and see how it goes. 
Then, you should select the best codec supported by your sip provider as the 
only available codec in csipsimple.

Original comment by r3gis...@gmail.com on 16 Aug 2011 at 9:10

[GoogleCodeExporter]

I'm having the same issue on 3g, though all is perfect on wifi. 

Tried different codecs... Only 8kHz codecs work.

Sipdroid does work really well using PCMA/U 64kbit on same 3g.

Tried STUN, ICE. And a couple different stun servers.

These are for incoming calls. Gv/iptel on 2.3.4gb 45.2.17 bell.

Any other things to try?  Thanks!

Original comment by whitebre...@gmail.com on 25 Sep 2011 at 3:38

[GoogleCodeExporter]

Same problem here, only on incoming calls on 3g.

Also tried the guide online to use STUN and ICE, doesn't help.

Original comment by timsudal...@gmail.com on 29 Apr 2012 at 9:28

[GoogleCodeExporter]

Issue 673 has been merged into this issue.

Original comment by r3gis...@gmail.com on 13 May 2012 at 7:17

[GoogleCodeExporter]

This problem is usually due to codec negociation on server side.
A good test is to disable all codecs but PCMU for example.
If one that has this problem can try with a nightly build
http://nightlies.csipsimple.com/trunk/
with only STUN enabled and only PCMU codec enabled and collect some logs with 
this issue number as reference (see HowToCollectLogs wiki page).

Original comment by r3gis...@gmail.com on 13 May 2012 at 7:21

• Changed state: Need-Details

[GoogleCodeExporter]

Issue 581 has been merged into this issue.

Original comment by r3gis...@gmail.com on 13 May 2012 at 7:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Great news. Thanks for the feedback :)

Original comment by r3gis...@gmail.com on 16 May 2012 at 9:19

• Changed state: NextRelease

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sorry r3gis...@gmail.com I spoke to soon.

Strangely enough the first time I tested it seemed to have been fixed, but 
since, I have not been able to make it work at all.

I don't think this is an codec negociatio problem. I think it relates instead 
to the incorrect routing of audio set by the ROM on my phone. (ZTE Crescent) 
Theres more details on a similar problem with various handsets including the 
ZTE blade over @ sipdroid where with their latest release, the audio is being 
sent out of the Rear loudspeaker rather than earpiece.

http://code.google.com/p/sipdroid/issues/detail?can=2&start=0&num=100&q=&colspec
=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars&groupby=&so
rt=&id=366

Although it seems the problem is related to a broken rom, It would be nice to 
see a way to set the output speaker mode, similar to the mic input mode as you 
can in advance preferences.

Original comment by timsuda...@gmail.com on 17 May 2012 at 12:08

[GoogleCodeExporter]

According to the working patch in sipdroid issue list the option to turn on in 
CSipSimple is "use mode API".
I think there is no need of extra tweaking options than the ones we already 
have.
Somebody on the sipdroid mentioned a working work around in csipsimple. I'll 
search in history what were working settings to share.
Normally when there is working workaround I add auto detection for the device 
so that any body benefit of that.
Can you send me logs from your device (see HowToCollectLogs wiki page) so that 
I can see the device model.
Also after switching to use mode API,try to reboot the phone.If it's a rom bug 
they don't take into account reset made by apps.

Original comment by r3gis...@gmail.com on 17 May 2012 at 7:04

[GoogleCodeExporter]

Known values for ZTE blade :
Use Mode API = true
Audio mode while in call = MODE_IN_CALL

Apparently some other values for ZTE Joe are necessary :
http://code.google.com/p/csipsimple/issues/detail?id=1736#c4
Use Mode API = true
Use Routing API = true

Original comment by r3gis...@gmail.com on 17 May 2012 at 2:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

r3gis...@gmail.com thanks for your ongoing help. It is fantastic.

This is a seperate issue from Sipdroid.

With Sipdroid, Audio is routed inccorectly through rear speaker, with CSip, no 
audio is heard at all.

This is what I tried after what you said. Convinced I had tried all these 
options before, including the Samsung Galaxy S hack, i thought I best give it a 
go again, but this time log my doings:

1-
Use Mode API = true
Use Routing API = true
Audio mode while in call = MODE_IN_CALL
Reboot
Test Call
Result= No Incoming Audio through Earpiece

2- 
Use Mode API = true
Use Routing API = FALSE
Audio mode while in call = MODE_IN_CALL
Reboot
Test Call
Result= No Incoming Audio through Earpiece

3-
Use Mode API = true
Use Routing API = true
Samsung Galaxy Hack = true
Audio mode while in call = MODE_IN_CALL
Reboot
Test call
Result= No Incoming Audio through Earpiece

4-
Mode API = true
Use Routing API = true
Audio mode while in call = MODE_IN_COMMUNICATION (Default)
Reboot
Test Call
Result= No Incoming Audio through Earpiece

5- (Default Set Up)
Use Mode API = FALSE
Use Routing API = FALSE
Audio mode while in call = MODE_IN_COMMUNICATION (Default)
Reboot
Test Call
Result= No Incoming Audio through Earpiece

I tried mode in call = Normal and RINGTONE too. No change.

I sent the log, but here it is also.

Based on GPL application CSipSimple version : 0.04-00 r1513
 Here are important informations about Device : 
 android.os.Build.BOARD : blade2
 android.os.Build.BRAND : ZTE
 android.os.Build.DEVICE : blade2
android.os.Build.ID : GRJ22
 android.os.Build.MODEL : Blade S
 android.os.Build.PRODUCT : P736V_FFR
 android.os.Build.TAGS : release-keys
 android.os.Build.CPU_ABI : armeabi
 android.os.Build.VERSION.INCREMENTAL : eng.zhangchun.20111208.093059
 android.os.Build.VERSION.RELEASE : 2.3.5
 android.os.Build.VERSION.SDK_INT : 10

----

No Am I tested this right? Because when I perform the Audio test, the earpiece 
works FINE!!

Original comment by timsuda...@gmail.com on 17 May 2012 at 5:47

[GoogleCodeExporter]

Also want to add the model is listed as the Blade2 / Blade S

That is the french market name for the ZTE Crescent from my ROM. It is indeed 
the ZTE Crescent that I am using.

Original comment by timsuda...@gmail.com on 17 May 2012 at 5:48

[GoogleCodeExporter]

MMmhh, it's maybe something with network NAT traversal or with codec.
Can you :
 * ensure that stun is activated (only stun not ice)
 * try to disable all codecs but PCMA/PCMU for both fast and slow networks

Original comment by r3gis...@gmail.com on 17 May 2012 at 8:39

[GoogleCodeExporter]

Unfortunately that doesn't help.
Sipdroid gives me no problems with the earpiece, despite no stun server set. So 
surely it can't be a related to codecs negotiation/network problems?

Original comment by almostdu...@gmail.com on 17 May 2012 at 11:21

[GoogleCodeExporter]

On another note I get massive delay using PCMA both in Csip and Sipdroid. I 
never had this before but it started happening all of a sudden. Its not a 
problem because I GSM gives me no delay.

I just want to find out why Csip I don't get incoming audio! Annoying!

Original comment by almostdu...@gmail.com on 17 May 2012 at 11:22

[GoogleCodeExporter]

Tried everything I could. Managed to work once on one of my tests using Mode in 
Call and rest default, but couldnt repeat it the second time around.

Tried Stun, Ice, TURN...all with no luck.

No idea what can be wrong.

Original comment by almostdu...@gmail.com on 19 May 2012 at 9:47

[GoogleCodeExporter]

Fring seems to work okay, sometimes you have to switch between earpiece and 
speaker but it works.

Sipdroid latest build routes audio through speaker.

The fixed sipdroid routes audio through earpiece correctly.

Skype also routes audio through speaker similar to latest sipdroid.

Clearly something is not right!

Original comment by almostdu...@gmail.com on 19 May 2012 at 10:00

[GoogleCodeExporter]

Mmmh, indeed very weird.
The more strange things is that when doing an audio test you get things working 
properly. That's why I thought that was something with media negotiation (
topology or codec).

What could be interesting, is that when in call, you press the menu key.
And select "Media" option.

Here there is some jauge indicating level received from your mic and from other 
side. If there is no activity on remote side, it's definitely something with 
network/audio negotiation. If there is activity it's something with android 
audio layer only.

You could also, when in call press the little arrow under the contact photo and 
select "Info", you'll see packet loss statistic and remote peer. It could be 
interesting to see if a peer is detected or not.

Also, I've fixed something in recent nightlies that could have side effects on 
this kind of situation (I'm not sure it's not regression free, but worth to 
test). This fix could explain why it works only once and then is broken.

Original comment by r3gis...@gmail.com on 19 May 2012 at 11:23

• Changed state: Need-Details

[GoogleCodeExporter]

Well I just performed some more tests again, reinstalled the latest nightly.

All tests were made on default settings apart from Mode=In Call

--

Call 1 - Suceeded, Audio through earpiece.
Call 2 - Unsucceeded, No Audio through earpiece.
Call 3 - Suceeded, Audio through earpiece.

Rest of my calls no longer work. Strange

Well, i checked in the info and each time it shows an IP address/sip address 
that it is connected too, sometimes the call id is unknown, sometimes it comes 
up with the caller id name. There is no packet loss at all each time I have 
checked. There is a figure though, one small figure usually 150~ms, the other 
ranges from 5000-8000~ ms. Is this the delay? is this causing the problem?

Bandwidth is shown as 64kbps/74kbps

On top of this, sometimes the call doesn't reach csip at all, e.g it doesn't 
ring. This continues until i re register the client.

Still doesn't make any sense that firing works flawlessly and this doesn't!

Ill try the latest non-nightly build.

Original comment by almostdu...@gmail.com on 20 May 2012 at 1:50

[GoogleCodeExporter]

Same behavior in the latest stable

Original comment by almostdu...@gmail.com on 20 May 2012 at 2:02

[GoogleCodeExporter]

I tried use Talkatone, which seems to look like it is similar to csip. 
Talkatone routes audio via the external speaker like sipdroid does. In 
talkatone you can only chose between system, music and VOICE CALL as options.

I also tried Counterpath Bria. This works fine through the earpiece with "Voice 
Call" selected as the playback stream.

In Bria all settings are default apart from the connection strategy as (server 
side NAT). With Stun, Stun3g, Ice, Ice3g all disabled and only DNS SRV enabled.

Now I am wondering if the problem with Csip is indeed the connection to the 
server, but more-so how csip lets built in server NAT work of my providor 
(IPtel).

Would be interesting to learn how these applications work differently, but it 
does seem like the problem with csip is not a routing one, but instead a 
connection related one. Even since the settings seem to be the same.

To rule out a problem with codec negotion, I have disabled all codecs but GSM 
in my tests, since I know that works fine.

Original comment by timsudal...@gmail.com on 23 May 2012 at 5:23