siproxd doesn't compile due to bug 1538

Status: NEW => ASSIGNED
Depends on: (none) => 1538
Assignee: bugsquad => maarten.vanraes

removed pdf documentation ( which couldn't get build due to bug 1538 ), since there is already html documentation.

it's now available in cauldron as well as in updates_testing (as a missing package)?

can someone test these, then move them to updates ?

Hardware: i586 => All
Depends on: 1538 => (none)
Assignee: maarten.vanraes => qa-bugs

AL13N : can you provide some testing steps that allow to check that it works well ? I'm sure there are people willing to test but who don't know how to test.

CC: (none) => stormi

I've only installed so far.  Installation pulled in libosip2_4 from
Core Release, so this update is blocked by bug 2317, as anyone who
upgraded from Mandriva 2010.2 with siproxd installed will be unable
to update via mgaapplet.

CC: (none) => davidwhodgins
Depends on: (none) => 2317

(In reply to comment #4)
> I've only installed so far.  Installation pulled in libosip2_4 from
> Core Release, so this update is blocked by bug 2317, as anyone who
> upgraded from Mandriva 2010.2 with siproxd installed will be unable
> to update via mgaapplet.

Are you sure that bug 2317 blocks it ? A full distribution upgrade via mgaapplet will use the release media and there's no way to install the software via MageiaUpdate as it was not present before. AFAIK bug 2317 concerns only new dependencies added to an existing package (A is installed, A is updated and now requires B from core/release).

i guess testing upgrade from mdv is what you can do, but likely bug 2317 will have an affect if you use mgaaplet to upgrade, indeed.

if you want to actually use it; there are the following steps, you can do:

requirements:
 - a NAT LAN network.
 - a personal voip account to an outside party (like ekiga.net eg)

direct sip will not be successfull, but if you configure ekiga to use sip proxy (ip address of sipproxd), it'll be successfull. of course, firewalling still has to be effective. if your modem/router has sip stuff, you'll need to turn that off.

i'll add that siproxd is usually used on firewalls, and they often don't have graphic setup and likely be updated via urpmi sources, thus not having bug 2317 .

(In reply to comment #6)
> i guess testing upgrade from mdv is what you can do, but likely bug 2317 will
> have an affect if you use mgaaplet to upgrade, indeed.

It can be a problem, not during migration to Mageia, but on an existing Mageia system where the old Mandriva package is still here, and only if the siproxd package in mandriva didn't require libosip2_4. Otherwise bug 2317 would not block the upgrade.

This update still requires testing, following the steps in comment #6

thinking about the meeting, I suppose that dependant package could be copied as well. perhaps it should be put into updates_testing as well? so it can be tested by eg: Dave ?

I'll try and test this on i586, if I can figure out how to do this
with an xp guest under VirtualBox.

One thing I've already noticed, is that the ownership of
/var/lib/siproxd and /var/run/siproxd has to changed to
have siproxd as the owner.

(In reply to comment #10)
> thinking about the meeting, I suppose that dependant package could be copied as
> well. perhaps it should be put into updates_testing as well? so it can be
> tested by eg: Dave ?

For now yes, copying libosip2_4 to core updates testing, and later including
it when pushing to updates should be done.

Solving bug 2317 may take a while.

Testing complete on i586 for the srpm
siproxd-0.8.1-1.1.mga1.nonfree.src.rpm

Altered /etc/siproxd.conf to have both the if_inbound and if_outbound
set to eth0.

Changed host_outbound to hodgins.homeip.net, which is registered
at dyndns.org, and kept up-to-date by my router.

Set my router to forward udp ports 7070-7089 to the Mageia 1
system, and opened those ports in /etc/shorewall/rules.drakx

In rules.drakx, I also have
ACCEPT  net:192.168.10.0/16 fw
so that VirtualBox guests can access services on the host.

In the VirtualBox guest using bridged networking, running ekiga in
Knoppix, I've set the Outbound sip proxy to the host ip address.

I sucessfully initiated a call to the echo test user, from the guest.
The call was answered by ekiga on the host.

thanks for testing it!

I myself always use x86_64, so that makes this easier... :-)

Thinking about it a bit more, the echo should have come back to the guest.
Running the test again, without ekiga on the host running siproxd, it
doesn't work.

So while it is passing the connection from the client to ekiga.net, it isn't
passing the results back to the client.

I'm currently installing knoppix to the hd under virtualbox, so I won't
have to reenter the settings each time, and will check things out more
once that's done.  Takes quite a while on my 6 yr old i586 system :-(

I can't install Mageia under VirtualBox due to bug 44.

I was going to test siproxd on x86_64 but I cannot find it on either the ftp.nluug.nl or distrib-coffee.ipsl.jussieu.fr mirrors in updates_testing.

CC: (none) => derekjenn

its in nonfree/updates_testing
http://sophie.zarb.org/rpms/b4f14b3054d7dccf26cc203470c7d589

O_O it should not be in nonfree! something must have gone wrong when submitting.

Can anyone move it? or does it need to be resubmitted and deleted from non_free ?

Might have to get someone else, who has a lan, or more experience with
networking to test this one.

Wireshark shows siproxd is getting the sip request invite from the
guest, passing it on to ekiga, getting the auth required from ekiga,
and passing that back to the guest.

The guest then sends and ack, which siproxd relays ok.

The guest then sends an invite, but there doesn't seem
to be anything after that going back to the guest.

Most likely, I've missed something trying to get the host to
act as a forwarder for traffic from my virtualbox guest.

dmorgan mentions that it's deleted and obgr_seneca submitted it to core updates_testing.

Dave: maybe you can fake a LAN with several virtual machines?

or maybe Derek Jennings can test it...

I have been trying to test siproxd using my asterisk server (on a VPN cloud server) and a Linksys VOIP adapter

I can only install siproxd on a host behind my router.  So far I can register the Linksys on siproxd, but I have not been able to make outgoing or incoming calls.

I shall have another try using a softphone instead of the Linksys VOIP adapter.

OK I have finally managed to get siproxd to work in a test environment.

Test environment was
X-Lite softphone on a windows Virtual Box := configured to use sip proxy

siproxy on a Mageai 1 host x86_64 := configured with if_inbound=if_outbound=eth0 and host_outbound= external ip address

router with ports 5060 and 7070-7089 forwarded to Mageia host

asterisk voice PBX on an Ubuntu cloud server

Logging was not working until I edited siproxd.conf to set  plugindir=/usr/lib64/siproxd/
It may be worth putting something in the advisory to tell people to change this setting if using x86_64

I was able to make outgoing and incoming calls which were duly logged in syslog

Testing on x86_64 is now complete.

maybe i should change this setting in the conf when installing it... wouldn't that be better?

Sure. If it is possible to do that just for the x86_64 rpm

assigning back to AL13N per comment #23, please assign back to qa-bugs once it has been treated.

status update, i made the modifications already, but i may have forgotten submission... :-(

the modification is submitted, can we retest?

Assignee: alien => qa-bugs

I notice on starting siproxd I get this message in the log

siproxd[19231]: utils.c:635 WARNING:couldn't create new PID file: Permission denied

/var/run/siproxd is owned by root.

The previous problem with the library files on x*6_64 is confirmed resolved.

i didn't notice that, this looks easily solvable, i'll take care of it

Assignee: qa-bugs => alien

I fixed this issue, (and also the /var/lib/siproxd/ directory; which is used to store registration file); now someone has to review and submit it, i'll keep you posted.

siproxd-0.8.1-1.3.mga1 submitted, please test.

assigning back to qa

Assignee: alien => qa-bugs

As per comment 13, this package has been partially tested.  Complete testing
has not been able to be done, due to lack of hardware (running mageia 1
as a firewall, providing internet access to a lan), despite a call for testers
in the Mageia General Discussion mailing list.

As the software installs cleanly, and at least appears to function properly,
I'm going to go ahead and validate this update.

Can someone from the sysadmin team push the srpm
siproxd-0.8.1-1.3.mga1.src.rpm
from Core Updates Testing to Core Updates.

Also, please link the rpm package
libosip2_4
From Core Release to Core Updates.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

update pushed.

Status: ASSIGNED => RESOLVED
CC: (none) => dmorganec
Resolution: (none) => FIXED