pwlib, OpenH323 and OpenOpal status not good?

Wed Oct 11 19:55:19 UTC 2006

Hi!

This week I had the chance to test our openh323 and opal libs against the
phone system of my work, it is an ericsson pbx wich has h323 capabilities.

I tested with ohphone, simph323, simpleopal, ekiga and gnomemeeting.

I could only login to the Ericsson with simph323 and ohphone, I could get
phone calls and place them using any of these but I didn't get any sound, in
fact, I was not getting any udp traffic coming through, I checked the
firewall of my machine but that didn't seem the problem, so I'm thinking if
maybe the supported codecs were not compatible between my Debian and the
Ericsson system. Any sugestions on this?

As for ekiga, gnomemeeting and simpleopal... I just could not get them to
login with the machine, even though the extension that I was using didn't
even had a password, I just had to specify the user to ohphone and simph323
to allow them to login. Again... any ideas on how to check with any of
these?

On the other side I thought I had not looked at any of these programs for a
long time, being on the SIP/IAX side right now, so I had a little practice
today here at home between a couple of machines just with the command line
tools and found some weird things...

The clients I used were pul and zul, pul is running a 2.6.18 kernel compiled
by me and only has ipv4 support on it, it runs sid with everything up to
date, zul on the other side is a pure Debian machine running debian's 2.6.18
and thus with IPv6 support, it runs mostly etch with the stuff from sid
needed to be able to install ekiga from there, which means that it has
latest libopal (2.2.3.dfsg-1).

First of all, the libpt alsa support seems to be broken, at least as tested
through ohphone, it says that I don't have permission for full duplex when
I'm using both machines in full duplex with twinkle for example. I could get
it to place a call using oss, but I had the following troubles:

If I try to place the call from a machine with IPv6 interface to another one
with just ipv4 support and I use the name this is what happens:

Listening interfaces : ALL:1720
Waiting for incoming calls for "manty"
Command ? c pul
manty is calling host pul
Command ? Transport error calling "ip$pul:1720"

If I use the IP instead of pul everything goes ok (pul is resolved ok from
any program running on the IPv6 client.

Second... using the OSS support, after I hang the first call, if I try to
place another one, the sound doesn't go through, in fact, even though the
logical channels for audio are announced to be stablished, if I try to turn
silence detection off interactively, I get an error that there is no channel
stablished. This happens even though I restart both ohphones, the only way
to solve this is by unloading the alsa driver on one of the clients and then
loading it again. These is what I see on the receiving client when this
happens, as you can see first call goes well, but second one doesn't:

Listening interfaces : ALL:1720
Waiting for incoming calls for "manty"
Command ? Incoming call from "manty [::ffff:192.168.1.253]" at Wed, 11 Oct
2006 21:33:35 +0200, answer call (Y/n)? y
Started logical channel: sending G.711-ALaw-64k <1>
Started logical channel: receiving G.711-ALaw-64k <1>
Call with "manty [::ffff:192.168.1.253]" established.
Accepting call.
Command ? e
Silence detection off
Command ? Command ? h
Hanging up call.
Command ? Call with "manty [::ffff:192.168.1.253]" completed, duration  5:33
Incoming call from "manty [::ffff:192.168.1.253]" at Wed, 11 Oct 2006
21:39:15 +0200, answer call (Y/n)? y
Started logical channel: sending G.711-ALaw-64k <1>
Started logical channel: receiving G.711-ALaw-64k <1>
Call with "manty [::ffff:192.168.1.253]" established.
Accepting call.
Command ? e
Cannot find audio channel
Command ?

Third, and I consider this a problem on our side, nothing to do with
upstream in any way, when I tried to test simpleopal on the etch machine and
I got this:

manty at zul:~$ simpleopal 
simpleopal: error while loading shared libraries: libpt.so.1.10.2: cannot
open shared object file: No such file or directory
manty at zul:~$ dpkg -l|grep libpt-
ii  libpt-1.10.0                     1.10.1.dfsg-1               Portable
Windows Library
ii  libpt-plugins-oss                1.10.1.dfsg-1               Portable
Windows Library Audio Plugins for t
ii  libpt-plugins-v4l                1.10.1.dfsg-1               Portable
Windows Library Video Plugin for Vi

Same thing happens with ekiga when I try to start it. I believe this is a
problem with libpt itself, as both simpleopal and ekiga depend on
libpt-1.10.0 but it is clear that my libpt-1.10.0 doesn't provide the same
lib soname as the libpt-1.10.0 that the builder used and thus libpt-1.10.0
is completely broken. Should I post a bug on pwlib? or do we discuss this
first?

Well, I believe this is all I have to say for now, as always, this pwlib,
openh323 or opal based things give a lot of problems :-(

How happy I was when I was not testing all this stuff and instead I was with
twinkle (even though our ftp maintainers are not letting me install latest
version) or kiax, or asterisk, or...

Regards...
--
Manty/BestiaTester -> http://manty.net