Siproxyd not working

nsumner

This package is totally hosed. I can't make any configuration changes (to make it work). As a result listening interface is LAN and broadcast interface is LAN which is guaranteed to make it not work. Suprise suprise it doesn't work. It is likely just that no configuration changes will be saved but this makes the package at this point useless! It is of course possible that once the interface is fixed the rest will work 100% fine.

sullrich

The package has no maintainer. Want to adopt it?

nsumner

I would love to but my programing skills are zero. Since it is probably just an interface issue I will take a look tommorow (I know to late for beta3 but then again as a package it is likely seperate anyhow). If I can fix this problem great, if not well as I say my programing skills are 0.

sullrich

I'll see if I can get it working a little later for beta3.

gen-ik

I have the same problem as the thread starter with RC1. Is there any news on it?

sullrich

@gen-ik:

I have the same problem as the thread starter with RC1. Is there any news on it?

No.

buraglio

I just started playing with siproxd and found that it will start from the cli (although I have never tried sip through a NAT so I'm fumbling around to get a config working). It's my humble, possibly incorrect belief that the binary does work. The one caveat that I need to add is that I've read 0 on problems others are having and 0 on how to make it work. =P


# /usr/local/sbin/siproxd -c /usr/local/etc/siproxd.conf
19:18:04 INFO:siproxd.c:189 siproxd-0.5.11-7 i386-unknown-freebsd6.0 starting up

# ps -auxww |grep sipro
nobody  7114  0.0  1.1  1976  1400  ??  S     7:13PM   0:00.04 /usr/local/sbin/siproxd
root    7465  0.0  0.5  1468   668  p0  R+    7:18PM   0:00.00 grep sipro
#

…Upon further investigation and some tcpdumps I believe my ATA is configured incorrectly. I'll work on getting that to work and see if siproxd works from there.

gen-ik

I was also able to manually start siproxyd. I took a peek at how it seems to work: there is a file pkg_edit.php in directory /usr/local/www. This file receives as a url parameter the name of the xml file, which contains information and functionality (as embedded PHP code) of that package. In this case, the file is siproxd.xml, which is in directory /usr/local/pkg.

Probably there is some error in the xml file (maybe in function sync_package_sipproxd()), causing the operation to be terminated, resulting in the configurations never being saved.

I'm no php expert, but I'll take a look if I can find out something.

mschuerm

… some news here? ???
I have the same problem with the package siproxd on pfsense 1.0-SNAPSHOT-09-21-06.
Siproxd doesn´t start. But manually it starts.
Now i can make a SIP call over my ASTERISK. Everthing works for this outgoing call. But incoming calls doesn´t work.

Any help here?

Thanks!
Cheers
Markus

hoba

Search the forum for "static port". It fixes a lot of voip related problems. On top of it portforward needed ports for your voip. You might not need the siproxd package then. I know of some people that have it working this way without proxy.

mschuerm

Hi hoba,

thanks a lot. I have enabled advanced outbound NAT and have added Static Port in the default mapping.

Then i have added the following UDP Ports in the Firewall:NAT:Port Forward section:

UDP 5060 192.168.10.253 5060
and
UDP 10000-20000 192.168.10.253 10000-20000

This settings are for sipgate.de

After that i had an outgoing voip call over sipgate with a very good quality although another web connection has a download with about 3 MBit/s ;D

It´s too late to test an incoming call because everyone is sleeping here :o

Cheers Markus

mschuerm

It´s me again,

i am happy! Even incoming calls work properly ;D

What´s about security wich static nat?

Cheers
Markus

hoba

There is no real problem with static ports. some consider it a bit more secure when the prts are changed while going through a nat, however this breaks the SIP protocol unless you use a STUN server or the provider has some kind of proxy to fix it again at their end. You should be fine. I also would only use the static port option for your SIP device or the SIP portrange, you can make everything else use the default port translation by adding the default rule below the special rule for the sip device.