[jitsi-dev] Jitsi doesn't transfer my voice

#1

Jitsi seems very promising since it supports video and is written on my favorite programming language.
But it doesn't work for me =((.
When I call to the test number 00000@sipnet.ru I hear the invitation of test center.
Then I speak there something. When the test center playbacks my speech it seems the duration of my speech is 0.

At the same time, Blink SIP client (http://icanblink.com) calls OK on the same machine.
I connected to ISP using the router DLink DI604-UP. The ISP has NAT.

I run Jitsi 1.0-beta1-nightly.build.3820 from PPA under Ubuntu 10.04 and I can help in debugging.

#2

Could you please provide Jitsi's logs as well as described at
http://jitsi.org/index.php/Documentation/FAQ#logs?

···

2012/1/8 user <xxxiter@rambler.ru>:

When I call to the test number 00000@sipnet.ru I hear the invitation of test
center.
Then I speak there something. When the test center playbacks my speech it
seems the duration of my speech is 0.

#3

I was actually curious so I gave it a try. Blink seems to be
connecting over speex which we also support bu the server doesn't seem
to like the streams we encode. I have no idea why, though and their
maintainers. We are using the native speex implementation so I don't
think there's anything actually wrong with the data but maybe the
sipnet service don't like our packetization. Who knows. It would be
nice if someone could check with them in case they are interested in
solving the issue.

Cheers,
Emil

···

On Sun, Jan 8, 2012 at 4:36 PM, Lyubomir Marinov <lubo@jitsi.org> wrote:

2012/1/8 user <xxxiter@rambler.ru>:

When I call to the test number 00000@sipnet.ru I hear the invitation of test
center.
Then I speak there something. When the test center playbacks my speech it
seems the duration of my speech is 0.

Could you please provide Jitsi's logs as well as described at
http://jitsi.org/index.php/Documentation/FAQ#logs?

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31

#4

sipnet.ru accepts 32kHz speex only. Jitsi offers it as payload type
number 98 and spinet.ru maps it to payload type number 99 in their
answer. In order to force Jitsi to use payload type number 99 for
32kHz speex and, consequently, have a message from Jitsi echoed back
by 00000@spinet.ru, the following line needs to be manually placed in
sip-communicator.properties:

net.java.sip.communicator.impl.neomedia.dynamicPayloadTypePreferences.99={clockRate\:32000,encoding\:speex}

#5

Thanx a lot I'll try this option next weekend!

the following line needs to be manually placed in
sip-communicator.properties:

net.java.sip.communicator.impl.neomedia.dynamicPayloadTypePreferences.99={clockRate\:32000,encoding\:speex}

#6

I have tried this option and it works for me.
Are there any reasons against including this option into trunk?
Should I open respective bug report?

* Lyubomir Marinov <lubo@jitsi.org> [Thu, 12 Jan 2012 17:15:06 +0200]:

sipnet.ru accepts 32kHz speex only. Jitsi offers it as payload type
number 98 and spinet.ru maps it to payload type number 99 in their
answer. In order to force Jitsi to use payload type number 99 for
32kHz speex and, consequently, have a message from Jitsi echoed back
by 00000@spinet.ru, the following line needs to be manually placed in
sip-communicator.properties:

net.java.sip.communicator.impl.neomedia.dynamicPayloadTypePreferences.99={clockRate\:32000,encoding\:speex}

#7

I have tried this option and it works for me.
Are there any reasons against including this option into trunk?

Yes. The problem is that sipnet.ru does not respect the payload type we
assign to speex and they always force it to 99. This is not frequent
behaviour but it is legal nonetheless. Jitsi however does not support
asymmetric payload types which is why things fail.

The option simply forces speex to payload type 99 which works for
sipnet.ru. 99 however is not reserved for sipnet.ru so, even if we do
put that by default, the very same issue may occur with a system that
relies some other codec to be 99 or that forces speex to 112 for instance.

All in all, we should symply fix asymmetric PT negotiation.

Should I open respective bug report?

Yes please.

Cheers,
Emil

···

On 13.01.12 19:39, user wrote:

* Lyubomir Marinov <lubo@jitsi.org> [Thu, 12 Jan 2012 17:15:06 +0200]:

sipnet.ru accepts 32kHz speex only. Jitsi offers it as payload type
number 98 and spinet.ru maps it to payload type number 99 in their
answer. In order to force Jitsi to use payload type number 99 for
32kHz speex and, consequently, have a message from Jitsi echoed back
by 00000@spinet.ru, the following line needs to be manually placed in
sip-communicator.properties:

net.java.sip.communicator.impl.neomedia.dynamicPayloadTypePreferences.99={clockRate\:32000,encoding\:speex}

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31