siproxd-users Mailing List for siproxd - SIP proxy/masquerading daemon (Page 9)
Status: Beta
Brought to you by:
tries
Menu
▾
▴
siproxd-users — Users Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(7) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2004 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2005 |
Jan
(14) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
(5) |
Feb
(4) |
Mar
(3) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
| 2009 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2010 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
(4) |
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2012 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Thomas R. <tr...@gm...> - 2004-10-29 16:39:47
|
Hello Mike,
As mentioned in the documentation, siproxd MUST be running on the
router / NAT-device between the private and public network.
If you have additional NAT devices installed, it also depends on their
behavior. Siproxd depends on "having access" to the network interface
holding the internal (private) IP AND the network interface holding the
external (public) IP.
A local-UA to local-UA call looks:
internal external
IP IP
UA1 ----+
|
+- . . . . ---+
siproxd |
+- . . . . ---+
|
UA2 ----+
The RTP traffic is takes the full path through siproxd, there is no
"Ah, it's a loop-back"-shortcut.
Regards,
/Thomas
On 29 Oct, si...@mi... wrote:
>
>
>
>
> I note from the FAQ that local call functionality was added v0.5.3 Feb
> 2004.
>
> In my configuration, siproxd is running on a NAT/firewall with a private
> LAN IP. To access the internet it goes through a separate ADSL NAT
> router/firewall gateway. This works for incoming/outgoing calls, but
> fails for internal private local UA-UA calls.
>
> I am guessing this is perhaps because siproxd relies on the UDP packets
> being "loopedback" from the ADSL public IP?
>
> Can siproxd be configured to "loopback" locally without requiring packets
> to be reflected from the public IP?
>
> Any suggestions?
>
> Thanks,
> Mike.
>
>
>
> -------------------------------------------------------
> This Newsletter Sponsored by: Macrovision
> For reliable Linux application installations, use the industry's leading
> setup authoring tool, InstallShield X. Learn more and evaluate
> today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
--
GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
- Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94
- Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP: sip:174...@pr... |
|
From: <si...@mi...> - 2004-10-29 12:21:38
|
I note from the FAQ that local call functionality was added v0.5.3 Feb 2004. In my configuration, siproxd is running on a NAT/firewall with a private LAN IP. To access the internet it goes through a separate ADSL NAT router/firewall gateway. This works for incoming/outgoing calls, but fails for internal private local UA-UA calls. I am guessing this is perhaps because siproxd relies on the UDP packets being "loopedback" from the ADSL public IP? Can siproxd be configured to "loopback" locally without requiring packets to be reflected from the public IP? Any suggestions? Thanks, Mike. |
|
From: Thomas R. <tr...@gm...> - 2004-08-27 19:58:24
|
Hi Jody, this looks to me like the mask_host is not setup propery. I can't see more from that short log snipplet. How do you have configure the mask_host and masked_host? The masked_host MUST be the outbound IP of siproxd (which I doubt in your case). Regards, /Thomas On 27 Aug, Jody McIntyre wrote: > Thanks for the reply. > > On Thu, Aug 26, 2004 at 07:29:57PM +0200, Thomas Ries wrote: > >> 1) You may want to put in the correct access control mask into the >> configuration: >> >> hosts_allow_sip = 205.233.128.0/24 >> >> should *probably* be: 205.233.218.0/24 (218 instead of 128) > > You're right. I was actually looking at things this morning again and > noticed that. > >> 2) Why does phone 1000 send an INVITE to 1002@192.168.90.1 ?? >> 1002 is supposed to be registered at the asterisk server, which >> then should be called as 1002@205.233.218.10. > > I'm just dialing "1002" on the phone, which apparently sends the wrong > thing. It does ring the phone though. > >> 3) The phone 1000 must have the public side IP configured as domain >> part of it's SIP URI (can be seen in a sent INVITE request, e.g. >> at 13:03:27 of your debugfile). >> As "From" header it shows "sip:user@192.168.90.1", however this must >> contain the public (outbound) IP of siproxd "sip:user@205.233.218.5" - >> otherwise incoming calls will not work properly. >> On some phones you simply cannot configure the domain part independently >> from the registration server - if this the case you must use the >> mask_host feature of siproxd to correct the header fields properly. > > OK, the phone does actually offer this feature, but it's called "Bypass > Firewall NAT" at the bottom of the "SIP Configuration" page. > > Unfortunately the feature does not work as it should. Instead, the > From: address still ends up as sip:user@192.168.90.1 and the Contact: > becomes sip:user@205.233.218.5. Fortunately the mask_host feature does > fix the problem. > > I still can't connect back through siproxd. I tried dial by URL: > sip:1005@205.233.218.5 from extension 1002 (the phone on the internal > network is now extension 1005 not 1000). siproxd does not recognize the > URL and treats it as an attempted outgoing call, which of course does > not work. A log is attached. Any suggestions? > > Thanks, > Jody > > > >> >> >> Regards, >> /Thomas >> >> ###################################################################### >> -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... |
|
From: Jody M. <si...@mo...> - 2004-08-27 19:46:13
|
Thanks for the reply. On Thu, Aug 26, 2004 at 07:29:57PM +0200, Thomas Ries wrote: > 1) You may want to put in the correct access control mask into the > configuration: > > hosts_allow_sip = 205.233.128.0/24 > > should *probably* be: 205.233.218.0/24 (218 instead of 128) You're right. I was actually looking at things this morning again and noticed that. > 2) Why does phone 1000 send an INVITE to 1002@192.168.90.1 ?? > 1002 is supposed to be registered at the asterisk server, which > then should be called as 1002@205.233.218.10. I'm just dialing "1002" on the phone, which apparently sends the wrong thing. It does ring the phone though. > 3) The phone 1000 must have the public side IP configured as domain > part of it's SIP URI (can be seen in a sent INVITE request, e.g. > at 13:03:27 of your debugfile). > As "From" header it shows "sip:user@192.168.90.1", however this must > contain the public (outbound) IP of siproxd "sip:user@205.233.218.5" - > otherwise incoming calls will not work properly. > On some phones you simply cannot configure the domain part independently > from the registration server - if this the case you must use the > mask_host feature of siproxd to correct the header fields properly. OK, the phone does actually offer this feature, but it's called "Bypass Firewall NAT" at the bottom of the "SIP Configuration" page. Unfortunately the feature does not work as it should. Instead, the From: address still ends up as sip:user@192.168.90.1 and the Contact: becomes sip:user@205.233.218.5. Fortunately the mask_host feature does fix the problem. I still can't connect back through siproxd. I tried dial by URL: sip:1005@205.233.218.5 from extension 1002 (the phone on the internal network is now extension 1005 not 1000). siproxd does not recognize the URL and treats it as an attempted outgoing call, which of course does not work. A log is attached. Any suggestions? Thanks, Jody > > > Regards, > /Thomas > > ###################################################################### > |
|
From: Thomas R. <tr...@gm...> - 2004-08-26 17:30:23
|
Hi Jody, 1) You may want to put in the correct access control mask into the configuration: hosts_allow_sip = 205.233.128.0/24 should *probably* be: 205.233.218.0/24 (218 instead of 128) 2) Why does phone 1000 send an INVITE to 1002@192.168.90.1 ?? 1002 is supposed to be registered at the asterisk server, which then should be called as 1002@205.233.218.10. 3) The phone 1000 must have the public side IP configured as domain part of it's SIP URI (can be seen in a sent INVITE request, e.g. at 13:03:27 of your debugfile). As "From" header it shows "sip:user@192.168.90.1", however this must contain the public (outbound) IP of siproxd "sip:user@205.233.218.5" - otherwise incoming calls will not work properly. On some phones you simply cannot configure the domain part independently from the registration server - if this the case you must use the mask_host feature of siproxd to correct the header fields properly. Regards, /Thomas ###################################################################### On 18 Aug, Jody McIntyre wrote: > I'm trying to get siproxd to work as a proxy between a Mitel 5055 phone > on a private network and an Asterisk server on the Internet. Here is > my test setup: > > +-----------------------+ > | 5055 Phone, ext. 1000 | > +-----------------------+ > |.9 > |192.168.90.0/24 (private network) > | > |.1 > +-------------------+ > | Gateway (siproxd) | > +-------------------+ > |.5 > | > |205.233.218.0/25 .14+-----------------------+ > +------------------------| 5055 Phone, ext. 1002 | > | +-----------------------+ > |.10 > +----------+ > | Asterisk | > +----------+ > > Ext. 1000 registers with siproxd and uses siproxd as a proxy. Siproxd > in turn uses Asterisk as a proxy. > > When I dial 1002 from ext. 1000, ext. 1002 rings. When I answer, no > connection is made, and ext. 1002 rings again a few seconds later. > > tcpdump on the internal network shows only packets from ext. 1000, none > from siproxd, e.g. > > 12:14:45.688449 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 > 12:14:46.237597 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 > 12:14:47.287526 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 > 12:14:49.337487 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 > 12:14:53.387489 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 > 12:14:57.257638 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 > 12:14:57.807521 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 > 12:14:58.864287 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 > 12:15:00.922289 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 > > tcpdump on the external network from the gateway shows a fair amount > of traffic between Asterisk and the gateway, e.g. > > 12:53:08.096222 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) > 12:53:08.096433 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) > 12:53:08.080950 205.233.218.10.5060 > 205.233.218.5.5060: udp 443 (DF) > 12:53:08.627450 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) > 12:53:08.627955 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) > 12:53:09.685765 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) > 12:53:09.686264 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) > 12:53:09.857811 205.233.218.10.5060 > 205.233.218.5.5060: udp 715 (DF) > 12:53:10.365812 205.233.218.10.15838 > 205.233.218.5.7070: udp 172 (DF) > [...] > 12:53:15.845776 205.233.218.10.15838 > 205.233.218.5.7070: udp 172 (DF) > 12:53:15.863486 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) > 12:53:15.864133 205.233.218.10.5060 > 205.233.218.5.5060: udp 715 (DF) > > (traffic between Asterix and ext. 1002 is not shown because this is a > switched network) > > tcpdump on Asterisk shows that ext. 1002 is responding: > > 13:05:15.661738 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 > 13:05:15.662196 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 > 13:05:15.662877 IP 205.233.218.10.5060 > 205.233.218.14.5060: UDP, length 749 > 13:05:15.663012 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 443 > 13:05:15.735000 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 353 > 13:05:15.736693 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 354 > 13:05:16.204154 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 > 13:05:16.204206 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 > 13:05:17.255575 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 > 13:05:17.255674 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 > 13:05:19.055489 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 703 > 13:05:19.055655 IP 205.233.218.10.5060 > 205.233.218.14.5060: UDP, length 383 > 13:05:19.055873 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 715 > 13:05:19.128410 IP 205.233.218.14.20056 > 205.233.218.10.18332: UDP, length 172 > [...] > > So the problem really seems to be siproxd not relaying the connection > back to ext. 1000. > > I have uploaded a log of one call attempt with full debugging to > http://modernduck.com/temp/siproxd.debug.1 . Relevant times: > 13:03:25: dialed 1002 from 1000 > 13:03:27: Answer from 1002 > 13:03:34: 1002 shows the call as dropped > 13:03:36: hangup on 1000 > > My configuration is at http://modernduck.com/temp/siproxd.conf . > > Any suggestions on things to try? > > Thanks, > Jody > > -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... |
|
From: Jody M. <si...@mo...> - 2004-08-18 17:26:49
|
I'm trying to get siproxd to work as a proxy between a Mitel 5055 phone on a private network and an Asterisk server on the Internet. Here is my test setup: +-----------------------+ | 5055 Phone, ext. 1000 | +-----------------------+ |.9 |192.168.90.0/24 (private network) | |.1 +-------------------+ | Gateway (siproxd) | +-------------------+ |.5 | |205.233.218.0/25 .14+-----------------------+ +------------------------| 5055 Phone, ext. 1002 | | +-----------------------+ |.10 +----------+ | Asterisk | +----------+ Ext. 1000 registers with siproxd and uses siproxd as a proxy. Siproxd in turn uses Asterisk as a proxy. When I dial 1002 from ext. 1000, ext. 1002 rings. When I answer, no connection is made, and ext. 1002 rings again a few seconds later. tcpdump on the internal network shows only packets from ext. 1000, none from siproxd, e.g. 12:14:45.688449 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 12:14:46.237597 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 12:14:47.287526 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 12:14:49.337487 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 12:14:53.387489 192.168.90.9.5060 > 192.168.90.1.5060: udp 704 12:14:57.257638 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 12:14:57.807521 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 12:14:58.864287 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 12:15:00.922289 192.168.90.9.5060 > 192.168.90.1.5060: udp 365 tcpdump on the external network from the gateway shows a fair amount of traffic between Asterisk and the gateway, e.g. 12:53:08.096222 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) 12:53:08.096433 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) 12:53:08.080950 205.233.218.10.5060 > 205.233.218.5.5060: udp 443 (DF) 12:53:08.627450 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) 12:53:08.627955 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) 12:53:09.685765 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) 12:53:09.686264 205.233.218.10.5060 > 205.233.218.5.5060: udp 442 (DF) 12:53:09.857811 205.233.218.10.5060 > 205.233.218.5.5060: udp 715 (DF) 12:53:10.365812 205.233.218.10.15838 > 205.233.218.5.7070: udp 172 (DF) [...] 12:53:15.845776 205.233.218.10.15838 > 205.233.218.5.7070: udp 172 (DF) 12:53:15.863486 205.233.218.5.5060 > 205.233.218.10.5060: udp 809 (DF) 12:53:15.864133 205.233.218.10.5060 > 205.233.218.5.5060: udp 715 (DF) (traffic between Asterix and ext. 1002 is not shown because this is a switched network) tcpdump on Asterisk shows that ext. 1002 is responding: 13:05:15.661738 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 13:05:15.662196 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 13:05:15.662877 IP 205.233.218.10.5060 > 205.233.218.14.5060: UDP, length 749 13:05:15.663012 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 443 13:05:15.735000 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 353 13:05:15.736693 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 354 13:05:16.204154 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 13:05:16.204206 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 13:05:17.255575 IP 205.233.218.5.5060 > 205.233.218.10.5060: UDP, length 809 13:05:17.255674 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 442 13:05:19.055489 IP 205.233.218.14.5060 > 205.233.218.10.5060: UDP, length 703 13:05:19.055655 IP 205.233.218.10.5060 > 205.233.218.14.5060: UDP, length 383 13:05:19.055873 IP 205.233.218.10.5060 > 205.233.218.5.5060: UDP, length 715 13:05:19.128410 IP 205.233.218.14.20056 > 205.233.218.10.18332: UDP, length 172 [...] So the problem really seems to be siproxd not relaying the connection back to ext. 1000. I have uploaded a log of one call attempt with full debugging to http://modernduck.com/temp/siproxd.debug.1 . Relevant times: 13:03:25: dialed 1002 from 1000 13:03:27: Answer from 1002 13:03:34: 1002 shows the call as dropped 13:03:36: hangup on 1000 My configuration is at http://modernduck.com/temp/siproxd.conf . Any suggestions on things to try? Thanks, Jody -- |
|
From: Thomas R. <tr...@gm...> - 2004-05-20 20:48:42
|
Release Notes for siproxd-0.5.6 =============================== Major changes since 0.5.5: - Better recognition of redirected incoming requests (incoming calls from sipgate.de are now working) - Bugfix for local registration with linphone (authentication) - made some corrections for building siproxd against uClibc for use with fli4l 2.1.7. General Overview: - SIP (RFC3261) Proxy for SIP based softphones hidden behind a masquerading firewall - works with "dial-up" conenctions (dynamic IP addresses) - Multiple local users/hosts can be masqueraded simultaneously - Access control (IP based) for incoming traffic - Proxy Authentication for registration of local clients (User Agents) with individual passwords for each user - May be used as pure Outbound proxy (registration of local UAs to a 3rd party registrar) - Fli4l OPT_SIP (still experimental) available, check http://home.arcor.de/jsffm/fli4l/ - supports Linux, FreeBSD and Solaris - Full duplex RTP data stream proxy for *incoming* and *outgoing* audio data - no firewall masquerading entries needed - Port range to be used for RTP traffic is configurable (-> easy to set up apropriate firewall rules for RTP traffic) - RTP proxy can handle multiple RTP streams (eg. audio + video) within a single SIP session. - Symmetric RTP support - Symmetric SIP signalling support - Supports running in a chroot jail and changing user-ID after startup - All configuration done via one simple ascii configuration file - Logging to syslog in daemon mode - RPM package support - The host part of UA registration entries can be masqueraded (mask_host, masked_host config items). Some Siemens SIP phones seem to need this 'feature'. Requirements: - pthreads (Linux) - glibc2 / libc5 / uClibc - libosip2 Currently tested on: - Fedora Core1 (Kernel 2.4.x, Glibc) This is my main development and testing environment. Other platforms are not extensively tested by myself. Builds on: - Linux (Fedora Core1) - FreeBSD (FreeBSD 4.10-BETA) - OpenBSD (OpenBSD 3.4 GENERIC#18) - SunOS (SunOS 5.9) - Mac OS X (Darwin 6.8) Reported interoperability with softphones: - Grandstream BudgeTone-100 series - Linphone (local and remote UA) (http://www.linphone.org) - Kphone (local and remote UA) (http://www.wirlab.net/kphone/) - MSN messenger 4.6 (remote and local UA) - X-Lite (Win XP Professional) Reported interoperability with SIP service providers: - Sipphone (http://www.sipphone.com) - FWD (http://www.fwd.pulver.com) - Sipgate (http://www.sipgate.de) 0.5.6 ===== 20-May-2004: - Released 0.5.6 - some cleanup in configure.in 14-May-2004: - FAQ update 16-May-2004: - INFO/WARN/ERROR are always logged to syslog, even if running in foreground (syslog still can be silenced using the silence_log config option) 09-May-2004: - Authentication headers: enquote Realm (linphone) - complain about empty values in config file - fli4l-uclibc: statically link against libpthread (as it seems to be not included in fli4l distribution) 02-May-2004: - better recognition of redirected incoming requests (like INVITES from sipgate.de - SIP URI points to the real wanted target but To: header only points to the initially wanted target before the redirection) - compiling on BSD (fwapi.c, custom_fw_module.c) 11-Apr-2004: - on termination, stop all active RTP streams 24-Apr-2004: - simplified SIP RX & TX routines -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... |
|
From: Thomas R. <tr...@gm...> - 2004-04-24 15:53:25
|
Hi Anders, You may want to use tha latest snapshot to start with (I just cleaned up some things around sending/receiving SIP packets). For implementing TCP transport, I think changes can be limited to sock.c. sipsock_listen() - create socket and listen on TCP port sipsock_wait() - include active TCP sockets to fd_set - accept() new connections - close() expired TCP connections (Criteria? In the 1st run this will probably a timeout of 'n' seconds without traffic) sipsock_read() - read one SIP message from transport (UDP or TCP) sipsock_send() - figure out the transport protocol to use *) - send to destination *) I did not yet look through RFC3261 how to determine the transport to be used for sending. I'll let you figure how to do this ;-) I hope this may help as a starting point. Looking forward to see some what will come out. Regards, /Thomas On 24 Apr, Quest wrote: > Thomas Ries <tr...@gm...> writes: > >> up to now, no TCP support is planned. But I'll put it on the >> nice-to-have list. > > I'll take a shot at implementing it. > >> Does this UA you mention *only* support TCP? This sounds rather strange >> to me. > > So it seems. It's not that I must absolutely use that particular UA. > It's more of an excuse to get into the SIP protocol. :) > > The client is called ActiveContacts. > -- > Anders "Quest" Qvist > > "Alvays remember: _any_ plan vere you lose you hat is a bad plan." > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Siproxd-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/siproxd-users -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... |
|
From: Quest <qu...@ly...> - 2004-04-24 11:26:28
|
Thomas Ries <tr...@gm...> writes: > up to now, no TCP support is planned. But I'll put it on the > nice-to-have list. I'll take a shot at implementing it. > Does this UA you mention *only* support TCP? This sounds rather strange > to me. So it seems. It's not that I must absolutely use that particular UA. It's more of an excuse to get into the SIP protocol. :) The client is called ActiveContacts. -- Anders "Quest" Qvist "Alvays remember: _any_ plan vere you lose you hat is a bad plan." |
|
From: Thomas R. <tr...@gm...> - 2004-04-24 06:51:30
|
Hi, up to now, no TCP support is planned. But I'll put it on the nice-to-have list. Does this UA you mention *only* support TCP? This sounds rather strange to me. Regards, /Thomas On 23 Apr, Quest wrote: > I have a client I want to support that uses TCP to make SIP > connections. Is there any plans to support TCP connections with > siproxd? > -- > Anders "Quest" Qvist > > "Alvays remember: _any_ plan vere you lose you hat is a bad plan." > > -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... |
|
From: Quest <qu...@ly...> - 2004-04-23 15:46:47
|
I have a client I want to support that uses TCP to make SIP connections. Is there any plans to support TCP connections with siproxd? -- Anders "Quest" Qvist "Alvays remember: _any_ plan vere you lose you hat is a bad plan." |
|
From: Thomas R. <tr...@gm...> - 2004-02-14 10:46:33
|
Release Notes for siproxd-0.5.3 =============================== Major changes since 0.5.2: - Support for connections between 2 local (masqueraded) UAs - Symmetric SIP signalling - handling of Max-Forwards header - A lot of smaller bugfixes General Overview: - SIP (RFC3261) Proxy for SIP based softphones hidden behind a masquerading firewall - works with "dial-up" conenctions (dynamic IP addresses) - Multiple local users/hosts can be masqueraded simultaneously - Access control (IP based) for incoming traffic - Proxy Authentication for registration of local clients (User Agents) with individual passwords for each user - May be used as pure Outbound proxy (registration of local UAs to a 3rd party registrar) - Fli4l OPT_SIP (still experimental) available, check http://home.arcor.de/jsffm/fli4l/ - supports Linux, FreeBSD and Solaris - Full duplex RTP data stream proxy for *incoming* and *outgoing* audio data - no firewall masquerading entries needed - Port range to be used for RTP traffic is configurable (-> easy to set up apropriate firewall rules for RTP traffic) - RTP proxy can handle multiple RTP streams (eg. audio + video) within a single SIP session. - Supports running in a chroot jail and changing user-ID after startup - All configuration done via one simple ascii configuration file - Logging to syslog in daemon mode - RPM package - The host part of UA registration entries can be masqueraded (mask_host, masked_host config items). Some Siemens SIP phones seem to need this 'feature'. Requirements: - pthreads (Linux) - glibc2 / libc5 / uClibc - libosip2 Currently tested on: - Redhat 6.0 (Kernel 2.2.x, Glibc) - Redhat 7.2 (Kernel 2.4.x, Glibc) - SUSE 5.3 (kernel 2.0.x, libc5) - Redhat 7.2 build against uClibc Reported to build on: - FreeBSD 4.7-STABLE - OpenBSD 2.9 - Solaris2 Reported interoperability (tested with softphones): - Grandstream BudgeTone-100 series - Linphone (local and remote UA) (http://www.linphone.org) - Kphone (local and remote UA) (http://www.wirlab.net/kphone/) - MSN messenger 4.6 (remote and local UA) If you can confirm other SIP phones working, please drop me a short note. Known bugs: There will be... If you port siproxd to a new platform or do other kinds of changes or bugfixes that might be of general interest, please drop me a line. Also if you intend to include siproxd into a software distribution I'd be happy to get a short notice. ----- md5sum for siproxd-0.5.3.tar.gz: 00a3d5d8d847da0db6cb9b16751f027a GnuPG signature for siproxd-0.5.3.tar.gz archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBALfgaCfzBioe83JQRAu0sAJ9u0NkyeU2RUrTil73VDXBhbGg2dwCeJO1G Uf3/9BnBuxsp+zuPGcsEYIs= =4NVr -----END PGP SIGNATURE----- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... 0.5.3 ===== 14-Feb-2004: - Released 0.5.3 - Removed superfluous backslashes for line continuation 11-Feb-2004: - Use same SIP port number for RX & TX (-> support symmetric SIP signalling) 7-Feb-2004: - Fix for local-UA to local-UA RTP proxying, symmetric RTP was not working. - logging routines now use a MUTEX to be thread safe. - RTP proxy: fixed a bug that could lead to a deadlock on very rapid HOLD/unHOLD sequences. 1-Feb-2004: - Added handling of Max-Forwards header - a detected via loop results in an 482 Loop detected 31-Jan-2004: - Allow 2 of my vias in header to let 2 UA's sitting behind the same siproxd have conversation together UA1 -->--\ > /-->--\ siproxd Registrar UA2 --<--/ < \--<--/ - Redone code for evaluation if a received packet is coming from the inbound or outbound network - RTP streams are now identified by call_id AND USERNAME of the contact header. This provides support for RTP proxying between 2 UAs sitting on the inbound network. -> Calls between local UAs going via siproxd should now work. UA1 -->--\ siproxd UA2 --<--/ - Rewriting of SUBSCRIBE messages should now work. - Removed obsolete prototypes from rtpproxy.h - If the RTP stream in one direction is found to be aborted (sendto() failure), also stop the stream for the opposite direction -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: Thomas R. <tr...@gm...> - 2004-02-12 22:23:21
|
Hi Christof, I included your suggested change. However, it seems that sipgate.de does not properly implement symmetric SIP signalling... Symmetric SIP signalling is requested by a 'rport' parameter in the topmost 'via' header - which siproxd does *NOT* include. Details: http://www.jdrosen.net/papers/draft-ietf-sip-symmetric-response-01.html Anyhow, I hope now siproxd is more tolerant in this respect ;-) Regards, /Thomas On 8 Feb, Christof Meerwald wrote: > Hi, > > I am unable to connect to sipgate.de via siproxd and I have tracked it down > to a problem in siproxd: when siproxd forwards a SIP message it uses a > random local port to send the UDP packet. sipgate.de seems to use this > address to send replies to, but siproxd doesn't listen on this port and so > the reply is lost. > > Here is a tcpdump: > > 14:21:57.348815 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) > 14:21:57.358810 217.10.79.9.5060 > 62.241.36.165.3769: udp 689 (DF) [tos 0x10] > 14:22:01.275851 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) > 14:22:01.285601 217.10.79.9.5060 > 62.241.36.165.3769: udp 689 (DF) [tos 0x10] > 14:22:05.320897 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) > 14:22:05.331116 217.10.79.9.5060 > 62.241.36.165.3769: udp 690 (DF) [tos 0x10] > 14:22:09.306329 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) > 14:22:09.317900 217.10.79.9.5060 > 62.241.36.165.3769: udp 690 (DF) [tos 0x10] > > As you can see, replies are sent to port 3769 on my machine, but siproxd > doesn't expect replies to be sent to this port (it only listens on port 5060 > for replies). > > > Fixing the problem is simple (use the same socket for sending and receiving > SIP messages): > > - remove the line "int sip_socket=0;" in src/siproxd.c > - rename the "listen_socket" in src/sock.c to "sip_socket" > > > bye, Christof > > -- > http://cmeerw.org JID: cm...@ja... > mailto cmeerw at web.de > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Siproxd-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/siproxd-users -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: Christof M. <cm...@we...> - 2004-02-08 13:39:17
|
Hi, I am unable to connect to sipgate.de via siproxd and I have tracked it down to a problem in siproxd: when siproxd forwards a SIP message it uses a random local port to send the UDP packet. sipgate.de seems to use this address to send replies to, but siproxd doesn't listen on this port and so the reply is lost. Here is a tcpdump: 14:21:57.348815 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) 14:21:57.358810 217.10.79.9.5060 > 62.241.36.165.3769: udp 689 (DF) [tos 0x10] 14:22:01.275851 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) 14:22:01.285601 217.10.79.9.5060 > 62.241.36.165.3769: udp 689 (DF) [tos 0x10] 14:22:05.320897 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) 14:22:05.331116 217.10.79.9.5060 > 62.241.36.165.3769: udp 690 (DF) [tos 0x10] 14:22:09.306329 62.241.36.165.3769 > 217.10.79.9.5060: udp 553 (DF) 14:22:09.317900 217.10.79.9.5060 > 62.241.36.165.3769: udp 690 (DF) [tos 0x10] As you can see, replies are sent to port 3769 on my machine, but siproxd doesn't expect replies to be sent to this port (it only listens on port 5060 for replies). Fixing the problem is simple (use the same socket for sending and receiving SIP messages): - remove the line "int sip_socket=0;" in src/siproxd.c - rename the "listen_socket" in src/sock.c to "sip_socket" bye, Christof -- http://cmeerw.org JID: cm...@ja... mailto cmeerw at web.de |
|
From: Thomas R. <tr...@gm...> - 2004-01-30 23:34:04
|
Release Notes for siproxd-0.5.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D After some time, again a release of siproxd. This release does not introduce new features, it contains mainly fixes and enhancements to follow better RFC3261. IPCHAINS & IPTABLES (netfilter) proxy support has been removed as the RTP relay now seems to work reliable. Major changes since 0.5.1: - removed IPCHAINS & IPTABLES (netfilter) proxy support - RTPPROXY correction: match RTP ports crosswise - use one single port (and socket) on each side (inbound/ outbound) to send and receive RTP traffic for every active stream (patch from Christof Meerwald).=20 - Handle with Route headers pointing to myself - Include mandatory branch parameter in added via headers - A lot of smaller bugfixes General Overview: - SIP (RFC3261) Proxy for SIP based softphones hidden behind a masquerading firewall - works with "dial-up" conenctions (dynamic IP addresses) - Multiple local users/hosts can be masqueraded simultaneously - Access control (IP based) for incoming traffic - Proxy Authentication for registration of local clients (User Agents) with individual passwords for each user - May be used as pure Outbound proxy (registration of local UAs to a 3rd party registrar) - Fli4l OPT_SIP (still experimental) available, check http://home.arcor.de/jsffm/fli4l/ - supports Linux and FreeBSD (other BSD derivates not yet tested) - Full duplex RTP data stream proxy for *incoming* and *outgoing* audio data - no firewall masquerading entries needed - Port range to be used for RTP traffic is configurable (-> easy to set up apropriate firewall rules for RTP traffic) - RTP proxy can handle multiple RTP streams (eg. audio + video) within a single SIP session. - Supports running in a chroot jail and changing user-ID after startup - All configuration done via one simple ascii configuration file - Logging to syslog in daemon mode - RPM package - The host part of UA registration entries can be masqueraded (mask_host, masked_host config items). Some Siemens SIP phones seem to need this 'feature'. Requirements: - pthreads (Linux) - glibc2 / libc5 / uClibc - libosip2 Currently tested on: - Redhat 6.0 (Kernel 2.2.x, Glibc) - Redhat 7.2 (Kernel 2.4.x, Glibc) - SUSE 5.3 (kernel 2.0.x, libc5) - Redhat 7.2 build against uClibc - should run on others Linux distributions as well. Reported to build on: - FreeBSD 4.7-STABLE - OpenBSD 2.9 - Solaris2 Reported interoperability (tested with softphones): - Grandstream BudgeTone-100 series - Linphone (local and remote UA) (http://www.linphone.org) - Kphone (local and remote UA) (http://www.wirlab.net/kphone/) - MSN messenger 4.6 (remote and local UA) If you can confirm other SIP phones working, please drop me a short note. Known bugs: There will be... If you port siproxd to a new platform or do other kinds of changes or bugfixes that might be of general interest, please drop me a line. Also if you intend to include siproxd into a software distribution I'd be happy to get a short notice. ----- md5sum for siproxd-0.5.2.tar.gz: =09aac78f680d22c4e1d153c761ba07d84a GnuPG signature for siproxd-0.5.2.tar.gz archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAGublCfzBioe83JQRAr3OAKCJv/3HqBEWKj6nN1mxLO/FpwrnFwCcD7mP MSz8yMxL4n2tUwTfX8ne8aA=3D =3Dn/yR -----END PGP SIGNATURE----- 0.5.2 =3D=3D=3D=3D=3D 30-Jan-2004:=09- If RTP proxy is disabled, don't rewrite incomming =09=09 SDP bodies (patch from Robert H=F6gberg) 29-Jan-2004:=09- new doc/RFC3261_compliance.txt and comments in the =09=09 code that refer to the RFC. 28-Jan-2004:=09- don't die on INVITE requests that include no Contact header - which is legal. (patch from Robert H=F6gberg) =09=09- RTP proxy: don't try to forward empty RTP packets =09=09- renamed some variables of rtp_proxytable_t to make better sense (changed meaning in fullduplex RTP proxy) 27-Jan-2004:=09- added doc/KNOWN_BUGS =09=09- better branch parameter calculation (via header), now honors RFC3261 for stateless proxies (section 16.11) - SIP request: remove a Route-header pointing to myself. This was an issue with Linphone 0.12.1. (patch from Robert H=F6gberg). - removed IPCHAINS & IPTABLES (netfilter) proxy support - RTPPROXY correction: match RTP ports crosswise - use one single port (and socket) on each side (inbound/ outbound) to send and receive RTP traffic for every active stream (patch from Christof Meerwald). 22-Jan-2004:=09- ./configure option: --enable-static to build =09=09 a completely statically linked executable - REGISTER honors the expires parameter of the contact header - Contact header of REGISTER response must be rewritten back to the local (true) URL 18-Jan-2004:=09- security_check_raw: =09=09 size check: >=3D 16 bytes - at exit, check registration file to be writable - no WARNING if SIP user-agent header is not supplied. - Call logging: distinguish between In & Out - include branch parameter for via headers --=20 GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint =3D 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: Thomas R. <tr...@gm...> - 2004-01-28 00:17:05
|
Hi Christof, Thanks for the patch, I just integrated it. Regards, /Thomas On 25 Jan, Christof Meerwald wrote: > Hi, > > RTP relaying is currently broken in siproxd. The problem is that siproxd > uses a "random" socket to forward RTP packets (which means that the source > IP address and the source port of the UDP packets will be random values). > Instead siproxd should use the same socket for sending and receiving RTP > packets from/to the client. > > Siproxd uses one socket to receive packets on the inbound interface and > another socket to receive packets on the outbound interface. When a packet > arrives on the outbound socket, siproxd should send the packet through the > corresponding inbound socket. And when a packet arrives on the inbound > socket, siproxd should send the packet through the corresponding outbound > socket. But the current behaviour is that siproxd uses a random socket for > forwarding all RTP packets (and therefore clients will see the RTP packets > coming from random ports and maybe also "random" IP addresses). > > > Here is a patch (against yesterday's 0.5.2 snapshot) to fix this behaviour. > > > bye, Christof > > -- > http://cmeerw.org JID: cm...@ja... > mailto cmeerw at web.de -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: Christof M. <cm...@we...> - 2004-01-26 10:21:57
|
Hi, RTP relaying is currently broken in siproxd. The problem is that siproxd uses a "random" socket to forward RTP packets (which means that the source IP address and the source port of the UDP packets will be random values). Instead siproxd should use the same socket for sending and receiving RTP packets from/to the client. Siproxd uses one socket to receive packets on the inbound interface and another socket to receive packets on the outbound interface. When a packet arrives on the outbound socket, siproxd should send the packet through the corresponding inbound socket. And when a packet arrives on the inbound socket, siproxd should send the packet through the corresponding outbound socket. But the current behaviour is that siproxd uses a random socket for forwarding all RTP packets (and therefore clients will see the RTP packets coming from random ports and maybe also "random" IP addresses). Here is a patch (against yesterday's 0.5.2 snapshot) to fix this behaviour. bye, Christof -- http://cmeerw.org JID: cm...@ja... mailto cmeerw at web.de |
|
From: Thomas R. <tr...@gm...> - 2003-12-22 11:29:51
|
Release Notes for siproxd-0.5.1 =============================== Just before my vacations I'll make another release. Some new features have been added and some changes are still going on. After giving some thoughts, I decided to discontinue the IPCHAINS and IPTABLES support. Reasons for this are, the RTP relay does fulfill the same task (with the cost of more CPU time needed), but it is much easier to support (portability and support on other platforms) and has no need for any special firewall masquerading configuration. Major changes since 0.5.0: - Feature: Full duplex RTP proxy - masquerading for outgoing RTP stream is no longer needed.Only the RTP relay has been tested yet. However, I'm planning to discontinue IPCHAINS and IPTABLES support in the near future for the sake of less dependency of the OS and portability. - Feature: The BudgeTone SIP phones now DO work with the RTP relay. - Feature: UA registrations now survive a restart of siproxd (ongoing sessions however do not survive). - Fix: cope with changing RTP port numbers suring a session (e.g. kphone does it when doing HOLD/unHOLD) General Overview: - SIP (RFC3261) Proxy for SIP based softphones hidden behind a masquerading firewall - works with "dial-up" conenctions (dynamic IP addresses) - Multiple local users/hosts can be masqueraded simultaneously - Access control (IP based) for incoming traffic - Proxy Authentication for registration of local clients (User Agents) with individual passwords for each user - May be used as pure Outbound proxy (registration of local UAs to a 3rd party registrar) - Fli4l OPT_SIP (still experimental) available, check http://home.arcor.de/jsffm/fli4l/ - supports Linux and FreeBSD (other BSD derivates not yet tested) - Full duplex RTP data stream proxy for *incoming* and *outgoing* audio data - no firewall masquerading entries needed - Port range to be used for RTP traffic is configurable (-> easy to set up apropriate firewall rules for RTP traffic) - RTP proxy can handle multiple RTP streams (eg. audio + video) within a single SIP session. - Supports running in a chroot jail and changing user-ID after startup - All configuration done via one simple ascii configuration file - Logging to syslog in daemon mode - RPM package - The host part of UA registration entries can be masqueraded (mask_host, masked_host config items). Some Siemens SIP phones seem to need this 'feature'. Requirements: - pthreads (Linux) - glibc2 / libc5 / uClibc - libosip2 (libosip1 is no longer supported!) Currently tested on: - Redhat 6.0 (Kernel 2.2.x, Glibc) - Redhat 7.2 (Kernel 2.4.x, Glibc) - SUSE 5.3 (kernel 2.0.x, libc5) - Redhat 7.2 build against uClibc - should run on others Linux distributions as well. - FreeBSD 4.7-STABLE (compilation) Reported to build on: - OpenBSD 2.9 - Solaris2 Reported interoperability (tested with softphones): - Grandstream BudgeTone-100 series - Linphone (local and remote UA) (http://www.linphone.org) - Kphone (local and remote UA) (http://www.wirlab.net/kphone/) - MSN messenger 4.6 (remote and local UA) If you can confirm other SIP phones working, please drop me a short note. Known bugs: There will be... If you port siproxd to a new platform or do other kinds of changes or bugfixes that might be of general interest, please drop me a line. Also if you intend to include siproxd into a software distribution I'd be happy to get a short notice. ----- md5sum for siproxd-0.5.1.tar.gz: 7bc01e78ba57aeaf9c83276900917bf5 GnuPG signature for siproxd-0.5.1.tar.gz archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/5tN7CfzBioe83JQRArf9AJ91kOKXa3T/8xtabc8XHXPgOf2ZmQCgoJll o551Dp/eXpzCWbwaNNeXSnY= =OIi0 -----END PGP SIGNATURE----- -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: <dhi...@bt...> - 2003-10-29 14:28:11
|
Hi Thomas and List, I successfully tested Instant Messaging using siproxd as the outbound = proxy ie the UA behind the NAT gateway registers to a 3rd party = registration server (on the public side) and uses siproxd as the = outgoing proxy. I used Siemens SIP UA. I will test this with some RTP = traffic soon. MSN Messenger 5.0 is buggy - it does not follow the SIP specification. = It tries to send an instant message using INVITE method and gets a BYE = in response. So SIP Instant Messaging with version 5 is not possible. Regards, Dhiraj Bhuyan Security Research Engineer BT Exact Tel: +44 1473 643932 Mob: +44 7962 012145 Email: dhi...@bt...=20 |
|
From: Thomas R. <tr...@gm...> - 2003-09-27 16:53:53
|
Hi, On 27 Sep, sting sting wrote: > Hello, > > I am trying now to make the 0.3.5 version of siproxd and I have a question: > after performing ./configure I get the following error: > > checking for osip_init in -losip2... no > *** ERROR: libosip2 is required! > > from where should I download the libosip2 library ? > > I had ,of course , googled for libosip2 sources ;all FTP/Download sites that > were with > tar.gz had unactive links ! (and I had started 2 days ago , so it does > not seem to be > some temporary failure/update). As libosip2 still is not downloadable from ftp.gnu.org and its mirrors (see http://www.cert.org/advisories/CA-2003-21.html for details), I've temporary put a copy of libosip2-2.0.2 to: http://home.tiscalinet.ch/ries/siproxd/libosip2-2.0.2.tar.gz By the way: the current release of siproxd is 0.3.6b which includes some bugfixes and enhancements. Regards, /Thomas -- GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...> - Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94 - Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: sting s. <zs...@ho...> - 2003-09-27 10:48:14
|
Hello, I am trying now to make the 0.3.5 version of siproxd and I have a question: after performing ./configure I get the following error: checking for osip_init in -losip2... no *** ERROR: libosip2 is required! from where should I download the libosip2 library ? I had ,of course , googled for libosip2 sources ;all FTP/Download sites that were with tar.gz had unactive links ! (and I had started 2 days ago , so it does not seem to be some temporary failure/update). Any advice can be helpful regards, sting _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus |
|
From: sting s. <zs...@ho...> - 2003-09-25 06:50:17
|
Hello, I did corrected the prototypes of the 2 methods as in the answer to my former message in this forum from yesterday (http://sourceforge.net/mailarchive/forum.php?thread_id=3178064&forum_id=11829) these two methods are: int rtp_masq_start_fwd() int rtp_masq_stop_fwd() in rtpproxy_masq.c Now I have other problems: 1) when I do make I get : rtpproxy.o(.text+0x41): In function `rtpproxy_init': /work/src/siproxd-0.3.6/src/rtpproxy.c:52: undefined reference to `rtp_masq_init' As understand , this is because there is missing #define of HAVE_LINUX_IP_MASQ_H So I added this definition (temporarily) in rtpproxy_masq.c (should it be done in amkefiel / elsewhere ? ) Now I get different errors: rtpproxy_masq.c: In function `rtp_masq_start_fwd': rtpproxy_masq.c:143: warning: implicit declaration of function `time' rtpproxy_masq.c:204: invalid use of undefined type `struct ip_masq_ctl' rtpproxy_masq.c: In function `_create_listening_masq': rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:297: dereferencing pointer to incomplete type rtpproxy_masq.c:299: dereferencing pointer to incomplete type rtpproxy_masq.c:299: `IP_MASQ_TARGET_USER' undeclared (first use in this function) rtpproxy_masq.c:299: (Each undeclared identifier is reported only once rtpproxy_masq.c:299: for each function it appears in.) rtpproxy_masq.c:300: dereferencing pointer to incomplete type rtpproxy_masq.c:300: `IP_MASQ_CMD_INSERT' undeclared (first use in this function) rtpproxy_masq.c:301: dereferencing pointer to incomplete type rtpproxy_masq.c:303: dereferencing pointer to incomplete type rtpproxy_masq.c:304: dereferencing pointer to incomplete type rtpproxy_masq.c:306: dereferencing pointer to incomplete type rtpproxy_masq.c:307: dereferencing pointer to incomplete type rtpproxy_masq.c:310: `IP_FW_MASQ_CTL' undeclared (first use in this function) rtpproxy_masq.c:310: dereferencing pointer to incomplete type /usr/include/bits/stdio.h: At top level: rtpproxy_masq.c:72: storage size of `masq_table' isn't known make[2]: *** [rtpproxy_masq.o] Error 1 make[2]: Leaving directory `/work/src/siproxd-0.3.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/work/src/siproxd-0.3.6' make: *** [all-recursive-am] Error 2 What to do ? Is there (even not the latest ) tar.gz which I can perform make with success? regards sting _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail |
|
From: Thomas R. <tr...@gm...> - 2003-09-24 17:34:03
|
Hi sting,
I know why this problem occurs - I created this bug :-)
The calling arguments of the two functions rtp_masq_start_fwd() and
rtp_masq_stop_fwd() in the ELSE part of ifdef HAVE_LINUX_IP_MASQ_H are
simply wrong.
Correct is:
--snip--
#else
/*
* don't have ipchains or iptables - dummy routines and complain
*/
int rtp_masq_start_fwd(osip_call_id_t *callid, int media_stream_no,
struct in_addr outbound_ipaddr, int *outbound_lcl_port,
struct in_addr lcl_client_ipaddr, int lcl_clientport) {
outbound_lcl_port=0;
ERROR("Masquerading support is not enabled (compile time config option)");
return STS_FAILURE;
}
int rtp_masq_stop_fwd(osip_call_id_t *callid) {
return STS_FAILURE;
}
#endif
--snip--
Regards,
/Thomas
On 24 Sep, sting sting wrote:
> Hello ,
> I had downloaded siproxd 0.3.6.targ.gz from sf.net and tried to perform
> ./configure
>
> Since I got an error of mssing : osip lib , I had also downloaded
> libosip2-2.0.2
> and performed ./configure,make,make install on that lib.
>
> Now I had performed ./cofgure on siproxd successfully ; But when trying to
> perform make
> I get the following error:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -pthread -Wall -DBUILDSTR=\"`cat
> .buildno`\" -D_GNU_SOURCE -c rtpproxy_masq.c
> rtpproxy_masq.c:342: conflicting types for `rtp_masq_start_fwd'
> rtpproxy.h:52: previous declaration of `rtp_masq_start_fwd'
> rtpproxy_masq.c:347: conflicting types for `rtp_masq_stop_fwd'
> rtpproxy.h:53: previous declaration of `rtp_masq_stop_fwd'
> make[2]: *** [rtpproxy_masq.o] Error 1
> make[2]: Leaving directory `/work/src/siproxd-0.3.6/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/work/src/siproxd-0.3.6'
> make: *** [all-recursive-am] Error 2
> I saw that in the code (it is rtpproxy_masq.c) this method appears twice
> (the second is in else of #ifdef 0 )
>
> Does anybody why this problem occurs ?
> What should I do to make siproxd?
>
> regards,
> sting
>
--
GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
- Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94
- Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP: sip:174...@pr... | sip:th...@ri... |
|
From: sting s. <zs...@ho...> - 2003-09-24 09:01:42
|
Hello , I had downloaded siproxd 0.3.6.targ.gz from sf.net and tried to perform ./configure Since I got an error of mssing : osip lib , I had also downloaded libosip2-2.0.2 and performed ./configure,make,make install on that lib. Now I had performed ./cofgure on siproxd successfully ; But when trying to perform make I get the following error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -pthread -Wall -DBUILDSTR=\"`cat .buildno`\" -D_GNU_SOURCE -c rtpproxy_masq.c rtpproxy_masq.c:342: conflicting types for `rtp_masq_start_fwd' rtpproxy.h:52: previous declaration of `rtp_masq_start_fwd' rtpproxy_masq.c:347: conflicting types for `rtp_masq_stop_fwd' rtpproxy.h:53: previous declaration of `rtp_masq_stop_fwd' make[2]: *** [rtpproxy_masq.o] Error 1 make[2]: Leaving directory `/work/src/siproxd-0.3.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/work/src/siproxd-0.3.6' make: *** [all-recursive-am] Error 2 I saw that in the code (it is rtpproxy_masq.c) this method appears twice (the second is in else of #ifdef 0 ) Does anybody why this problem occurs ? What should I do to make siproxd? regards, sting _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Thomas R. <tr...@gm...> - 2003-08-30 19:40:45
|
Minor bugfixes and clean-up. Verified that it can be built against
libc5 (FLI4L). As for the bugfixes it is recommended to upgrade to
this new version.
0.3.5
=====
30-Aug-2003: - released 0.3.5
20-Aug-2003: - security tests: responses may have empty SIP URI
don't fail there.
- increase size of call_id for RTP proxy table and
include a size check.
- rtpproxy: cleaned up some stuff with handling of FD's
Daily snapshots are available on http://www.ries.ch.vu/siproxd/
--
GnuPG: pub 1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
- Fingerprint = 13D1 19F5 77D0 4CEC 8D3F A24E 09FC C18A 87BC DC94
- Key via pgp.openpkg.org / http://www.ries.ch.vu/87BCDC94.pub
VoIP: sip:174...@pr... |
5 messages has been excluded from this view by a project administrator.
