First Last Prev Next    No search results available
Bug 8082 - (int-153993) Voice can be heard only one way with Saunalahti Nettipuhelin
(int-153993)
: Voice can be heard only one way with Saunalahti Nettipuhelin
Status: CLOSED FIXED
Product: Chat & Call & SMS
SIP
: 5.0/(3.2010.02-8)
: N900 Maemo
: Unspecified major with 2 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: rtcomm@maemo.org
: sip-bugs
:
:
: int-148396
:
  Show dependency tree
 
Reported: 2010-01-15 22:23 UTC by Tuomas Kulve
Modified: 2011-09-02 21:40 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

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

Description Tuomas Kulve (reporter) 2010-01-15 22:23:00 UTC 
SOFTWARE VERSION: 2009.51-1.

I have Saunalahti Nettipuhelin SIP service on my n900. If somebody calls to me
from a normal cellular phone, I can hear him but he can't hear me. If somebody
calls from a Saunalahti SIP service, then everything works as expected. I have
the same service in other use as well and that works properly in the same
network.

Based on comments from others and from google this seems to be a common
problem.

I didn't do any thorough examination but I took a tcpdump from both calls and
there is at least one clear difference.

The properly working call is started by the Saunalahti service offering PCMU as
the first choice in SDP and that's also the first choice offered by the N900
and it also gets selected for the RTP stream.

When the other end is calling from a cellular phone, the Saunalahti service
offers PCMA as the first choice in SDP and there's no PCMU at all in the choice
list. N900 replies to this by offering the PCMA also as the first choice (PCMU
is 5th) and the PCMA is accepted as the audio codec for the RTP stream.

On the broken one-way-call both ends are really sending RTP packets according
to the tcpdump. Wireshark is able to playback the voice calls in a tcpdump, one
direction in one audio channel (really nice feature :).

On the working call I can hear both directions as expected but on the
one-way-call I can hear only the incoming call properly. The outgoing call
seems a bit more interesting. I seem to hear only the echo from the other end
(we had the test call with both parties in one room) but I don't hear my
outgoing voice at all.

So it sounds like it's not even trying to send my voice out and is sending
something else. I don't know if this really is possible or if this was just a
glitch in my test. Any way, the test scenario seems to be reproducable 
independently of the caller or the Internet connection (3G, different WLANs).

If you have any suggestions, I'm happy to do some tests.
Comment 1 Andre Klapper maemo.org 2010-01-21 16:29:02 UTC 
Hmm, bug templates are always welcome. ;-)
Does this happen always?
Comment 2 Tuomas Kulve (reporter) 2010-01-21 16:34:07 UTC 
(In reply to comment #1)
> Hmm, bug templates are always welcome. ;-)

For some reason I often find the templates not fitting for the particular bug..

> Does this happen always?

Yes.
Comment 3 Mikhail Zabaluev nokia 2010-01-21 17:37:01 UTC 
Oh, Saunalahti.
While we can try to reproduce it in some time, I'm very interested to see that
packet capture. You can send it to me if you don't want to attach it here.
Comment 4 Tuomas Kulve (reporter) 2010-01-21 18:04:34 UTC 
Dumps delivered, thus removing moreinfo keyword.
Comment 5 Mikhail Zabaluev nokia 2010-01-21 18:36:03 UTC 
(In reply to comment #4)
> Dumps delivered, thus removing moreinfo keyword.

Great thanks. 
It seems there is a problem with packet timing that we're fixing as bug #6936.

There is an interesting addition to the SDP session, referring to a DV codec
you apparently have installed, and a second DTMF payload matching its declared
sample rate of 90000. But this doesn't seem to hurt anything.
Comment 6 Tuomas Kulve (reporter) 2010-01-21 19:56:15 UTC 
Yes, I have this installed:

http://maemo.org/downloads/product/Maemo5/decoders-support/

Should have mentioned it, but couldn't think of it at the time.
Comment 7 Tuomas Kulve (reporter) 2010-02-02 13:46:03 UTC 
Bug #6936 got fixed. Is this fixed as well now..?
Comment 8 Mikhail Zabaluev nokia 2010-02-02 14:41:50 UTC 
(In reply to comment #7)
> Bug #6936 got fixed. Is this fixed as well now..?

We didn't get around to verify this yet.
Comment 9 Tuomas Kulve (reporter) 2010-02-02 14:46:47 UTC 
(In reply to comment #8)
> (In reply to comment #7)
> > Bug #6936 got fixed. Is this fixed as well now..?
> 
> We didn't get around to verify this yet.

If the fix is to some open source component, I'm happy to test it. Or if
there's anything else I can try out.
Comment 10 Andre Klapper maemo.org 2010-03-29 13:18:56 UTC 
Nokia internally assumes that this issue has been fixed, but it's not totally
sure. Hence retesting after PR1.2 release welcome.
Forwarding internal comments:

"Currently we don't have Saunalahti SIP account to test this bug, but at least
actionvoip.com works well for me, i am able to do two ways communication."

"This bug cannot be seen anymore with actionvoip.com accounts. If we see later
that Saunalahti is still broken, we can reopen this bug."
Comment 11 Mikhail Zabaluev nokia 2010-03-29 20:18:41 UTC 
(In reply to comment #10)
> "Currently we don't have Saunalahti SIP account to test this bug, but at least
> actionvoip.com works well for me, i am able to do two ways communication."

I honestly tried to get a Saunalahti account through our corporate purchasing,
but it takes a ridiculous amount of time to get it worked out between
Saunalahti and Nokia purchasing, or we may have filed something wrongly. This
is just to not let you think we've been sitting on our thumbs (but then, maybe
you still think we do as a company :)).
Comment 12 Tuomas Kulve (reporter) 2010-05-27 09:39:21 UTC 
Verified with PR1.2
Comment 13 Tuomas Kulve (reporter) 2011-09-02 21:40:29 UTC 
Closing as this has been verified ages ago.
First Last Prev Next    No search results available