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