pwlib, OpenH323 and OpenOpal status not good?

[Kilian Krause]

Hey Manty,

> 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?

provide a -ttt output of ohphone or -d 3 of gnomemeeting/ekiga to Craig
or Damien and they should be able to spot the problem pretty easily.


> 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?

Same as above. Alternatively try tethereal -npi eth0 -V and see the
protocol details for more info if logs from layer 7 won't be good
enough. Right now there's also a "internally-pending" bug about re-add
the debug compile (at least for faster platforms) and ship it in the
*-dbg packages. I haven't yet come round to actually implementing this a
convenient way, but if your problems persist, it might help to do a
recompile with this and then test against the debug version to gain more
output.


> 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).

Ekiga doesn't have any IPv6 support right now.


> 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:

libpt-plugins-alsa/Ohphone has a bug against ALSA problems. Try with
GnomeMeeting. I haven't asked Craig recently about what the problem is
and when it'd be solved. I'll just bring it to his attention again and
hope it's dealt with upstream. Thanks for the heads up.


> 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.

IPv6 support is not yet really tested well with OPAL as Ekiga is
completely IPv4-only for now. It may well be that the problem is in
either OPAL or simpleopal. If ohphone has issues with ipv6, we should
get them reported upstream as I haven't yet been aware of any.


> 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 ?


Nice find. Looks like a real bug that's yet unknown to me. Craig, any
comments?


> 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

Your version of opal (2.2.3.dfsg-1) doesn't match with pwlib 1.10.1.
Obviously PWLib 1.10.2 and OPAL 2.2.3 belong to one another. It might
work to have PWLib upgraded and leave OPAL the old version, yet I
haven't tried. Thus, please install either a set of etch-only or
sid-only debs.


> 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, it's obviously backwards compatibility in mind, but if you feel
that adjusting the SONAME back to the old version we're being compatible
with is the better choice feel free to implement this in the SVN.
Alternatively, we could also go through NEW each new upload if we'd try
to keep back- and forward-compatibility as sane as possible. Obviously
this has been discussed with Craig and right now the best chance to get
the situation straight for you, would be adjusting the debian/rules for
dh_makeshlibs -V '$(PACKAGE) >= $(DEBVERSION)'. Adding this to pwlib and
opal would at least ensure that libs are always older than the apps they
are now referenced by. This would work for the situation you created
above with pwlib/etch and opal/sid. Objections?


> 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 :-(

Well, I have seen worse, so thanks for the update and thanks for your
time. I hope Craig will find the time to look to the problems with OPAL
and ohphone, so they get fixed with the next release. For the internal
debian packaging issues, I'd see the above fix be the most convenient
one IMO.

-- 
Best regards,
 Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20061011/e43296cd/attachment.pgp