Is siproxd capable of doing some basic SIP routing? I'd like to be able to selectively route certain calls to a local FXO device (i.e. for 911 calls from the local network phones) while passing everything else through to our ITSP in the cloud...
2013-05-13 11:56:02 PDT by ouidonet
I've forced changed port in Contact field to range above 10000. The both phones has been registered successfully, but NOTIFY messages have come to port 1000x instead of 5060. Attempt INVITE message sending has returned 403 Forbidden. I can't guess what is wrong. PBX - Siemens Open Scape Voice.
2013-05-07 06:50:22 PDT by afx33sd
If the PBX does identify the UACs only by IP & port number (ignoring the "user" part of the URI) it does not properly follow the SIP RFCs - IMHO. If this really is the case, siproxd cannot do anything about it - please file a bug report with the provider of the PBX.
2013-04-29 11:42:00 PDT by tries
I try to use siproxd as proxy about the sheme: US(subnetwork1) <----> (eth0 - subnetwork1 ) siproxd (eth1 - subnetwork2) <-----> PBX (subnetwork 2) I have several user stations connected to my proxy, however only one station may register in PBX. A soon as the next phone agent tries beeing registering, PBX rejects the request. I have an idea that it happens due to the same port...
2013-04-29 11:26:14 PDT by afx33sd
Hi Thomas, like I said in post #6, I could figure out where the 22.214.171.124 came from, it was the current, correct internet gateway IP at that time (just like 126.96.36.199). I had the "Discover public IP address" disabled, however I still had an STUN server configured. Disabling the STUN server did the trick! And so far siproxd works smoothly :). Thanks a lot for your...
2013-04-23 03:50:03 PDT by ntux
Siproxd is designed to allow local UAC that are located behind NAT to access a public PBX. Your setup seems exactly the reverse. There is no official scenario that does support such a setup, nor am I aware of someone running siproxd in a setup like this. Regards, /Thomas.
2013-04-14 06:26:37 PDT by tries
You are right, the IP 188.8.131.52 does show up in the SDP description of the client (according to the new siproxd log with valgrind). I just had a look at the first log (April12) you made, there a public IP of 184.108.40.206 shows up, strange. In this particular case, siproxd would behave correctly, sending the RTP targeted for the local phone towards the IP address specified by the phone. So,
2013-04-14 02:11:15 PDT by tries
Hrm, now I know where "220.127.116.11" comes from: It's the internet ip address of the sip client device. And it looks like siproxd is actually behaving fine by using it as the sip client announced it as the "Connection Address" in its SIP/SDP packet, right? I've deactivated the options "Discover public ip address" and "Loose Routing", so I'm not sure why...
2013-04-13 23:54:18 PDT by ntux
Okay, I think I'm seeing what's going wrong, it looks like a bug in siproxd to me: I've now been using a wireshark filter 'sip || rtp || (udp && !dns && !(eth.dst & 1))' instead of simply 'sip || rtp'. And I'm seeing the incoming RTP packets which are supposed to show up on eth0 on eth1 instead. At least I think they are the ones supposed for eth0 as they have the...
2013-04-13 23:29:42 PDT by ntux
Hi Thomas, no, there's no iptables rule on the host running siproxd and INPUT is set to the ACCEPT default policy, so the firewall is disabled. I also haven't configured any SELINUX stuff. It's a pretty clean Debian wheezy VM for now, had created this VM just for the siproxd purpose. Cheers, Linus.
2013-04-13 16:58:18 PDT by ntux