siproxd-users — Users Mailing List

[Siproxd-users] cron job starting siproxd

[Craig G. <cr...@tw...>]

I have a problem with siproxd dying periodically- after a few days I can
still log into it but noboy outside shows up as being logged in, and nobody
outside can see me logged in.

Since a simple killall and restart of the siproxd executable fixes the
problem, I've put it into a script file that is called daily by cron. The
problem is, after cron restarts the server, I can no longer sign in to it-
I'm asked for a username and password even though I do not use any
authentication. If I manually run the script again, all is fine.

I can't find any log information that sheds light on this. Can anyone
suggest some differences that may be responsible between the environment
under cron and under a shell in which I've logged in as root, and how I can
get around it? I'm somewhat stumped.

--
Dr. Craig Graham, Software Engineer
Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/

Re: [Siproxd-users] small bug in forwarded SDP invite (fwd)

[Andrew R. <an...@ra...>]

Thomas Ries wrote:
> Hello Andrew
> 
> What version of siproxd are you using?
> Did you try the latest snapshot at http://www.ries.ch.vu/siproxd/
> (must be around middle of May this year). The rewriting of
> INVITE has been rewritten since the last official release.
> 
> I'm currently working abroad and don't have a lot of time
> to work on siproxd development. I will return beginning of August
> and then I will release a new version of siproxd. Up to now,
> please use the lastest snapshot (and read the Changelog for a list
> of bugfixes and improovements that have been made since tha last
> release).
> 
> Please let me know, if this resolves the observed bug, or if
> this bug also exists in the snapshot.
> 
> Regards,
> 
> Thomas (maintainer of siproxd project)

Hi Thomas

I was using 0.3.2. I don't know if I'll have the chance to check this 
but I'll see what I can do. It wasn't causing a fault I just noticed it 
when I was watching the traffic on the wire.

Regards

Andrew Radke

Re: [Siproxd-users] small bug in forwarded SDP invite (fwd)

[Thomas R. <tho...@gm...>]

Hello Andrew

What version of siproxd are you using?
Did you try the latest snapshot at http://www.ries.ch.vu/siproxd/
(must be around middle of May this year). The rewriting of
INVITE has been rewritten since the last official release.

I'm currently working abroad and don't have a lot of time
to work on siproxd development. I will return beginning of August
and then I will release a new version of siproxd. Up to now,
please use the lastest snapshot (and read the Changelog for a list
of bugfixes and improovements that have been made since tha last
release).

Please let me know, if this resolves the observed bug, or if
this bug also exists in the snapshot.

Regards,

Thomas (maintainer of siproxd project)

[Siproxd-users] small bug in forwarded SDP invite

[Andrew R. <an...@ra...>]

Hi,

I've found a small bug in the SDP section of a forwarded INVITE. Between 
the c= and t= lines there is only 0x0a not 0x0d 0x0a.

Regards,

Andrew Radke

Re: [Siproxd-users] Using iptel service ...

[PAZ <rj...@ef...>]

On Tue, 8 Apr 2003, Thomas Ries wrote:

> Hi, Roberto
> 
> On  7 Apr, PAZ wrote:
> > 
> > Hi:
> > 	I tried version 0.3.2 and it worked just fine!!!. Voice sounds 
> > loud and clear. There's only one thing that didn't get to work yet: when 
> > I sing-in into IPTEL service, I don't see my partner like he was on-line 
> > (but he is). I forced a communication with him, and I reach him OK. I used 
> > voice without any trouble.
> > 
> > 	Do you know any reason why my partner doesn't appear as on-line? (I 
> > don't appear as on-line to him either ...). Tomorrow we are going to try 
> > more than one communicaction behind the NAT firewall simultaneously.
> > 
> > 	Thank you.
> > 
> 
> One question: you write "when I sign-in into IPTEL service". How do you
> do this? Your local User Agent must register itself at siproxd. And as
> siproxd currently does no support "proxy-chaining", your local User
> Agent very likely does *not* register itself at IPTEL.
> If you are using a sip<xxx>@iptel.org registration address, your
> configuration is probably working 'just by accident'.
> 
> 
> The following scenario is *not* supported by siproxd:
> 
> 				  +-----------+
>           :			  | registrar |
> 	  :			  |	      |
>  	  :			  +-----------+
> +-------+ : +--------+                  | iptel.org
> | local | : |firewall|  Internet        |
> |  UA   |---|siproxd |------------------+-------------//
> +-------+ : +--------+
> 
> - siproxd will *not* register itself or the local UAs
>   to an other registrar/proxy.
> 
> 
> 
> What *is* supported:
>           :
> +-------+ : +--------+ 
> | local | : |firewall|  Internet   
> |  UA   |---|siproxd |--------------------------------//
> +-------+ : +--------+  myname.homeip.net
> 
> - UA registers itself at siproxd,
>   using a registration record:
>   sip:us...@my...
> 
> - myname.homeip.net must resolve to the
>   public IP address of the firewall.
>   (-> eg DynDNS service)
> 
> - Incomming Calls must be directed to
>   sip:us...@my...
> 
> 
> Maybe, some day siproxd may support the first situation as well, but
> currrently is does not. I also don't know *when* I will have time
> (and I'm in the mood for) to start working on such an issue.
> 
> I'm quite sure that the reason for you problem (not seeing your partner
> online) is that your setup is similar to the first one.
> (If IPTEL is tolerant and redirect calls *TO* you, voice calls may work.
>  It could also be that making voice calls only work in one direction -
>  eg only outgoing calls work but incomming calls fail)
> 
> I hope this helps.
> 
> Best Regards,
> 
> /Thomas
> 

Yes, that's exactly what did happen. Sorry, my mistake. I suppose I didn't 
read documentation enough. I guess I misunderstand something due to iptel 
documentation and MS Messenger, that doesn't work if we don't sing-in our 
user. I guess I will try some other SIP Softphone for Windows.

Thank you, I hope that it will be all.

-- 
Roberto Paz

"The box said, 'Requires Windows 95 or better', so i installed Linux"
TKK 5

Re: [Siproxd-users] Using iptel service ...

[Thomas R. <tr...@gm...>]

Hi, Roberto

On  7 Apr, PAZ wrote:
> 
> Hi:
> 	I tried version 0.3.2 and it worked just fine!!!. Voice sounds 
> loud and clear. There's only one thing that didn't get to work yet: when 
> I sing-in into IPTEL service, I don't see my partner like he was on-line 
> (but he is). I forced a communication with him, and I reach him OK. I used 
> voice without any trouble.
> 
> 	Do you know any reason why my partner doesn't appear as on-line? (I 
> don't appear as on-line to him either ...). Tomorrow we are going to try 
> more than one communicaction behind the NAT firewall simultaneously.
> 
> 	Thank you.
> 

One question: you write "when I sign-in into IPTEL service". How do you
do this? Your local User Agent must register itself at siproxd. And as
siproxd currently does no support "proxy-chaining", your local User
Agent very likely does *not* register itself at IPTEL.
If you are using a sip<xxx>@iptel.org registration address, your
configuration is probably working 'just by accident'.


The following scenario is *not* supported by siproxd:

				  +-----------+
          :			  | registrar |
	  :			  |	      |
 	  :			  +-----------+
+-------+ : +--------+                  | iptel.org
| local | : |firewall|  Internet        |
|  UA   |---|siproxd |------------------+-------------//
+-------+ : +--------+

- siproxd will *not* register itself or the local UAs
  to an other registrar/proxy.



What *is* supported:
          :
+-------+ : +--------+ 
| local | : |firewall|  Internet   
|  UA   |---|siproxd |--------------------------------//
+-------+ : +--------+  myname.homeip.net

- UA registers itself at siproxd,
  using a registration record:
  sip:us...@my...

- myname.homeip.net must resolve to the
  public IP address of the firewall.
  (-> eg DynDNS service)

- Incomming Calls must be directed to
  sip:us...@my...


Maybe, some day siproxd may support the first situation as well, but
currrently is does not. I also don't know *when* I will have time
(and I'm in the mood for) to start working on such an issue.

I'm quite sure that the reason for you problem (not seeing your partner
online) is that your setup is similar to the first one.
(If IPTEL is tolerant and redirect calls *TO* you, voice calls may work.
 It could also be that making voice calls only work in one direction -
 eg only outgoing calls work but incomming calls fail)

I hope this helps.

Best Regards,

/Thomas


-- 
VoIP:  <sip:th...@ri...>

GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
       uid                            Thomas Ries <tho...@gm...>
       Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
       Available via pgp.openpkg.org | http://www.ries.ch.vu/87BCDC94.pub

Re: [Siproxd-users] Using iptel service ...

[PAZ <rj...@ef...>]

Hi:
	I tried version 0.3.2 and it worked just fine!!!. Voice sounds 
loud and clear. There's only one thing that didn't get to work yet: when 
I sing-in into IPTEL service, I don't see my partner like he was on-line 
(but he is). I forced a communication with him, and I reach him OK. I used 
voice without any trouble.

	Do you know any reason why my partner doesn't appear as on-line? (I 
don't appear as on-line to him either ...). Tomorrow we are going to try 
more than one communicaction behind the NAT firewall simultaneously.

	Thank you.

On Sat, 5 Apr 2003, Thomas Ries wrote:

> Hmm, well... you might want to try out a newer vesion of siproxd,
> (the dayly snapshot, not yet released) at:
> http://www.ries.ch.vu/siproxd/siproxd_04Apr2003.tar.gz
> 
> Up to 0.3.1 there is an issue with the RTP proxy, if siproxd
> is run daemonized. This would result in exactly the symptoms
> you describe.
> 
> On the firewall rules, simply have the port range of
> 'rtp_port_low' to (and including) 'rtp_port_high' ACCEPTed
> 
> It is very likely that I have time to release it this weekend.
> 
> Regards,
> 
> /Thomas
> 
> On  4 Apr, PAZ wrote:
> > On Thu, 3 Apr 2003, Thomas Ries wrote:
> > 
> >> Hi,
> >> 
> >> On  1 Apr, PAZ wrote:
> >> > 
> >> > Hi:
> >> > 	I have no luck trying to use iptel.org service with 
> >> > messenger. I am behind a Linux ipchains based NAT, and I opened all 
> >> > suggested ports in README file. With tcpdump, I see iptel.org is trying to 
> >> > reach my external NAT interface, port 8451 udp. Anyone has any idea about 
> >> > this port number?.
> >> 
> >> Might this be the RTP stream (a lot of UDP packets)? If so, this would
> >> indicate that messenger has not registered to siproxd and still sends
> >> its SIP requests directly.
> >> The local UA (-> messenger) must register at siproxd, so siproxd can
> >> act as masquerading proxy in between.
> > 
> > OK. I already had success when I was sing in to Iptel. The problem now is 
> > that the station behind the NAT firewall can establish a voice session to a 
> > remote user, and he can listen everything I said, but I can't hear him. I 
> > presume this is a firewall rule related issue, but I can't positively 
> > affirm this. Any ideas?.
> > 
> > Thank you.
> > 
> >> 
> >> > 
> >> > 	Another question: siproxd does not have to listen in port 
> >> > 7070:7080 also? (or maybe I understand something wrong about that ...).
> >> > 
> >> 
> >> Siproxd will dynamically allocate ports in the range 7070:7080 (and
> >> start listening) for each RTP stream that is started during an INVITE.
> >> Therefore, if no SIP sessions are active, siproxd will *not*
> >> listen on the ports 7070:7080.
> >> 
> >> > 	Thank you in advance.
> >> > 
> >> 
> >> Regards,
> >> /Thomas
> >> 
> >> 
> > 
> > -- 
> > Roberto Paz
> > 
> > "The box said, 'Requires Windows 95 or better', so i installed Linux"
> > TKK 5
> > 
> 

-- 
Roberto Paz

"The box said, 'Requires Windows 95 or better', so i installed Linux"
TKK 5

[Siproxd-users] siproxd-0.3.2 released

[Thomas R. <tr...@gm...>]

All siproxd before 0.3.2 have a potential bug concerning the
RTP proxy. If run daemonized, incoming RTP data stream are very likely
not to be proxied (results in no audio reception). If run in foreground
(non daemonized) the RTP proxy worked fine. This issue should now be
fixed in 0.3.2.
Siproxd can now deal with interfaces that are 'temporary' down (eg.
dialup ppp interfaces), there is no need to stop/start siproxd.
If built against libc5 systems, siproxd did not properly detach itself
from the tty and was terminated at logout - this is fixed also.

0.3.2
=====
 5-Apr-2003:	- released 0.3.2
 4-Apr-2003:	- introduced config option 'silence_log' - this allows
 		  to control how much logging is done to syslog - 
                  logging can even completely be switched off...
 1-Apr-2003:	- should now be able to deal with an outbound interface
                  that is "temporary" DOWN (dial up internet access)
                  if outbounf IF is down, send back a response to
                  inbound UAs "408 Request Timeout".
                - always log to syslog, also when running in foreground
                - changed some WARNINGS into DEBUG statements
                - re-arranged some code
                - rtpproxy: prepared for proper thread termination on exit
                - introduced short term caching for get_ip_by_ifname
                - fixed check for socket() return status
                - fixed bug in RTP Proxy (timeout of inactive streams)
                  that produced a bunch of "ERROR:Error in close(0): Bad file
                  descriptor" errors each time a RTP stream timed out
                - fixed daemonizing (libc5) - now it properly detaches
30-May-2003:	- always log ERROR, WARNING and INFO to syslog (also
                  if not running as daemon)
                - minor corrections on ERROR printouts

-- 
VoIP:  <sip:th...@ri...>

GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
       uid                            Thomas Ries <tho...@gm...>
       Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
       Available via wwwkeys.pgp.net or http://www.ries.ch.vu/87BCDC94.pub

Re: [Siproxd-users] Using iptel service ...

[Thomas R. <tr...@gm...>]

Hmm, well... you might want to try out a newer vesion of siproxd,
(the dayly snapshot, not yet released) at:
http://www.ries.ch.vu/siproxd/siproxd_04Apr2003.tar.gz

Up to 0.3.1 there is an issue with the RTP proxy, if siproxd
is run daemonized. This would result in exactly the symptoms
you describe.

On the firewall rules, simply have the port range of
'rtp_port_low' to (and including) 'rtp_port_high' ACCEPTed

It is very likely that I have time to release it this weekend.

Regards,

/Thomas

On  4 Apr, PAZ wrote:
> On Thu, 3 Apr 2003, Thomas Ries wrote:
> 
>> Hi,
>> 
>> On  1 Apr, PAZ wrote:
>> > 
>> > Hi:
>> > 	I have no luck trying to use iptel.org service with 
>> > messenger. I am behind a Linux ipchains based NAT, and I opened all 
>> > suggested ports in README file. With tcpdump, I see iptel.org is trying to 
>> > reach my external NAT interface, port 8451 udp. Anyone has any idea about 
>> > this port number?.
>> 
>> Might this be the RTP stream (a lot of UDP packets)? If so, this would
>> indicate that messenger has not registered to siproxd and still sends
>> its SIP requests directly.
>> The local UA (-> messenger) must register at siproxd, so siproxd can
>> act as masquerading proxy in between.
> 
> OK. I already had success when I was sing in to Iptel. The problem now is 
> that the station behind the NAT firewall can establish a voice session to a 
> remote user, and he can listen everything I said, but I can't hear him. I 
> presume this is a firewall rule related issue, but I can't positively 
> affirm this. Any ideas?.
> 
> Thank you.
> 
>> 
>> > 
>> > 	Another question: siproxd does not have to listen in port 
>> > 7070:7080 also? (or maybe I understand something wrong about that ...).
>> > 
>> 
>> Siproxd will dynamically allocate ports in the range 7070:7080 (and
>> start listening) for each RTP stream that is started during an INVITE.
>> Therefore, if no SIP sessions are active, siproxd will *not*
>> listen on the ports 7070:7080.
>> 
>> > 	Thank you in advance.
>> > 
>> 
>> Regards,
>> /Thomas
>> 
>> 
> 
> -- 
> Roberto Paz
> 
> "The box said, 'Requires Windows 95 or better', so i installed Linux"
> TKK 5
> 
-- 
VoIP:  <sip:th...@ri...>

GnuPG: pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
       uid                            Thomas Ries <tho...@gm...>
       Fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94
       Available via wwwkeys.pgp.net or http://www.ries.ch.vu/87BCDC94.pub

Re: [Siproxd-users] Using iptel service ...

[PAZ <rj...@ef...>]

On Thu, 3 Apr 2003, Thomas Ries wrote:

> Hi,
> 
> On  1 Apr, PAZ wrote:
> > 
> > Hi:
> > 	I have no luck trying to use iptel.org service with 
> > messenger. I am behind a Linux ipchains based NAT, and I opened all 
> > suggested ports in README file. With tcpdump, I see iptel.org is trying to 
> > reach my external NAT interface, port 8451 udp. Anyone has any idea about 
> > this port number?.
> 
> Might this be the RTP stream (a lot of UDP packets)? If so, this would
> indicate that messenger has not registered to siproxd and still sends
> its SIP requests directly.
> The local UA (-> messenger) must register at siproxd, so siproxd can
> act as masquerading proxy in between.

OK. I already had success when I was sing in to Iptel. The problem now is 
that the station behind the NAT firewall can establish a voice session to a 
remote user, and he can listen everything I said, but I can't hear him. I 
presume this is a firewall rule related issue, but I can't positively 
affirm this. Any ideas?.

Thank you.

> 
> > 
> > 	Another question: siproxd does not have to listen in port 
> > 7070:7080 also? (or maybe I understand something wrong about that ...).
> > 
> 
> Siproxd will dynamically allocate ports in the range 7070:7080 (and
> start listening) for each RTP stream that is started during an INVITE.
> Therefore, if no SIP sessions are active, siproxd will *not*
> listen on the ports 7070:7080.
> 
> > 	Thank you in advance.
> > 
> 
> Regards,
> /Thomas
> 
> 

-- 
Roberto Paz

"The box said, 'Requires Windows 95 or better', so i installed Linux"
TKK 5

[Siproxd-users] Using iptel service ...

[PAZ <rj...@ef...>]

Hi:
	I have no luck trying to use iptel.org service with 
messenger. I am behind a Linux ipchains based NAT, and I opened all 
suggested ports in README file. With tcpdump, I see iptel.org is trying to 
reach my external NAT interface, port 8451 udp. Anyone has any idea about 
this port number?.

	Another question: siproxd does not have to listen in port 
7070:7080 also? (or maybe I understand something wrong about that ...).

	Thank you in advance.

-- 
Roberto Paz

"The box said, 'Requires Windows 95 or better', so i installed Linux"
TKK 5

[Siproxd-users] siproxd-0.3.1 released

[Thomas R. <tr...@gm...>]

Just found another few nasty things. 0.3.0 would not work properly
with incoming SUBSCRIBE requests.

So, this is 

"Version 0.3.1 has been released."

The main changes in this release:
- bugfixes

Upgrading to 0.3.1 is warlmy recommended.


http://siproxd.sourceforge.net/

Siproxd is now available as Fli4l module (still extermimental)
-> http://home.arcor.de/jsffm/fli4l/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

0.3.1
=====
- 29-May-2003:	- released 0.3.1
		- fix in configure.in for statically linking to libosip
		- fix in rewriting SIP messages, figure out proper
		  destination if *not* rewriting the SIP URI
		- another NULL pointer related crash (no UA header present)

0.3.0
=====
- 29-May-2003:	- released 0.3.0
		- supports libosip2 (automatically detect osip1/osip2)
		- redone authentication - now should work with libosip2
                  libosip0.8.8 has a bug (fails in parse_msg)
- 28-May-2003:	- changes in rewriting SIP messages - not everything
		  is blindly rewritten now (e.g. SUBSCRIBE is NOT)
                - fixed resource leak (sockets) in get_ip_by_ifname
- 26-Mar-2003:	- Bugfix: some potential NULL pointers passed to atoi()
		  of optional fields in SIP message could lead to crash
- 23-Mar-2003:	- send 403 FORBIDDEN response to requests addressed
		  to proxy itself (-> SUBSCRIBE bug) 


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] siproxd-0.3.0 released

[Thomas R. <tr...@gm...>]

Version 0.3.0 has been released.

The main changes in this release:
- libosip2 support
- authentication should work again
- fixed a resource leak that was introduced with 0.2.7
- some minor bugfixes

Upgrading to 0.3.0 is recommended.


http://siproxd.sourceforge.net/

Siproxd is now available as Fli4l module (still extermimental)
-> http://home.arcor.de/jsffm/fli4l/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

0.3.0
=====
- 29-May-2003:	- released 0.3.0
		- supports libosip2 (automatically detect osip1/osip2)
		- redone authentication - now should work with libosip2
                  libosip0.8.8 has a bug (fails in parse_msg)
- 28-May-2003:	- changes in rewriting SIP messages - not everything
		  is blindly rewritten now (e.g. SUBSCRIBE is NOT)
                - fixed resource leak (sockets) in get_ip_by_ifname
- 26-Mar-2003:	- Bugfix: some potential NULL pointers passed to atoi()
		  of optional fields in SIP message could lead to crash
- 23-Mar-2003:	- send 403 FORBIDDEN response to requests addressed
		  to proxy itself (-> SUBSCRIBE bug) 


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] probs with FW

[Fabrice c. f. <reg...@fr...>]

Hey all.

Here is my network configuration (2 FW):



  +-------------+               +--------------+
  !             !          eth0 !              !
  ! IntHost     !---------------!   Firewall   !
  !             !    10.25.56.51! linux coyote !
  +-------------+               +--------------+
   10.25.56.0/24                       : eth1 (192.168.99.2)
                                       :
                                       :
                                       :
                                       : eth0 (192.168.99.1)
                                +--------------+
                                !   Firewall   !ppp0 (public IP)
                                ! mail server  !----------->> internet
                                ! redhat 7.2   !
                                +--------------+




This is what i've done:

1) I've installed siproxd on the mail server without any prob

2) Here are the rules i set on the mail server:
ACCEPT     udp  ----l-  anywhere    anywhere        any ->   5060
ACCEPT     udp  ------  anywhere    anywhere        any ->   7070:7080
i set no masquerading rule since all traffic already goes to the second 
FW (192.168.99.2).

3) Here are the rules i set on the 2nd FW :
coyote# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target     prot opt     source                destination           ports
MASQ       all  ------  10.25.56.0/24        anywhere              n/a
Chain output (policy ACCEPT):

I know it is dangerous but it's just for try.
I didn't installed siproxd on the 2nd FW (cuz i can't. It's a floppy 
linux distribution).

4)On the LAN, i use a windows client that calls: SCS-Client (from Siemens).

And it doesn't work. I can see in the messages file of the first FW 
(mail server) that traffic from the SIP server is accepted.
But i can't see nothing in the message file of the 2nd FW.

My friend uses Kphone and he can see the ring icone ringing and that's 
all. I can send him 1 chat message but he can't reply.
Well, i think what is going wrong is the masquerading.

I'm sorry for this very long description. But if anybody can help, i'd 
be very glad :)

fabrice

[Siproxd-users] siproxd-0.2.8 released

[Thomas R. <tr...@gm...>]

Version 0.2.8 has been released.

The main changes in this release:
- working to make siproxd a OPT_SIP for FLI4l (http://www.fli4l.org)
- build an run against libc5 systems (e.g. SUSE 5.3 and the current
  2.0.x versions of fli4l)
- build and run against uClibc (http://www.uclibc.org) C library.
  (For fli4l 2.1.x versions)

http://siproxd.sourceforge.net/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

0.2.8
=====
- 23-Mar-2003:	- released 0.2.8
		- made compile with uClibc (see doc/FLI4L_HOWTO.txt)
- 22-Mar-2003:	- made compile on SUSE5.3 (libc5)
		- added --enable-almost-static feature switch. This will
                  build siproxd statically linked against libosip & pthreads
                  (for Fli4l use)
- 16-Mar-2003:	- ERROR on unknown keywords in config file
		- introduced INFO logging



-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

Re: [Siproxd-users] Remote NAT Traversal

[Thomas R. <tr...@gm...>]

Hi Alejandro,

You did not hear from me because currently I'm quite busy at work
and lacking spare time (well... beside having fun, we all need to
earn some money for living, don't we?).

Ok, thanks for your short description about the remote NAT issue.
I've got a slight idea of the concept, however I still need to take a
deeper look into the draft of the TURN protocol to understant what
it is all about.

With my current knowledge, I have to answer 'no' to your initial
question (siproxd solution for remote NAT traversal). Siproxd must
be running on the firewall host itself as an application proxy.

I hope I could help with this answer.

Best regards,

/Thomas


On 18 Mar, Alejandro Olchik wrote:
> Thomas,
> As I haven't heard from you I'm forwarding this
> email directly to your email address.
> 
> Let me know your thoughts,
> Best regards,
> Alejandro
> 
> -------- Original Message --------
> Subject: Re: [Siproxd-users] Remote NAT Traversal
> From: "Alejandro Olchik" <ao...@te...>
> Date: Fri, March 14, 2003 10:59 am
> To: <sip...@li...>
> 
> 
> Some companies, like Jasomi, implement
> NAT Relay Agents. They work like SIP Proxies but
> make sure all signaling and RTP goes through then
> allowing enpoints behing NAT router to initiate
> or terminate calls withouth using any other NAT
> traversal mechanism (STUN, uPNP or an ALG).
> 
> J.Rosenberg wrote a draft for a protocol called
> TURN (Traversal Using Relay NAT -
> draft-rosenberg-midcon-turn). The NAT Relay
> agent is very similiar to that but is transparent
> to end enpoint (endpoints don't need to explicitly
> allocate ports at the TURN server).
> 
> The advantage of such a solution is that you don't
> need a siproxd running on each of the network edges.
> 
> Alejandro
> 
>> Hello Alejandro
>>
>> I'm not aware of a technique called 'remote NAT traversal'. Could you
>> describe more in detail what exactly you do mean by that?
>> What is the situation you have and what would you like to do?
>>
>> The main purpose of Siproxd is to enable SIP user agents that are
>> 'hidden' behind a masquerading firewall (e.g. in a private IP range)
>> to call and be called to/from the internet.
>>
>> /Thomas
>> Maintainer of Siproxd
>>
>>
>> On 13 Mar, Alejandro Olchik wrote:
>>>
>>> I was trying to figure out if the siproxd can be
>>> used as a solution for remote NAT traversal.
>>>
>>> Thanks,
>>> Alejandro Olchik
>>>


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] siproxd-0.2.7 released

[Thomas R. <tr...@gm...>]

Version 0.2.7 has been released.

Some small code changes to simplify code and enhance performance.

Introduced a (experimental) feature that allows masquerading (or better:
replacement) of the hostname that the UA passes in the registration.
Background: Siemens SIP phones ALWAYS pass the hostname/IP of the
*inbound* interface in registration. This new feature now allows
this to be overridden.

http://siproxd.sourceforge.net/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

0.2.7
=====
- 15-Mar-2003:	- released 0.2.7
-  9-Mar-2003:	- replaced get_ip_by_ifname by simpler code 
		  (still to be *BSD tested)
		- removed old host-name based style for in/outbound interface
                  configuration. This is only done via interface names
                - experimental: The host part of UA registration entries
                  can be masqueraded (mask_host, masked_host config items)
                  Siemens SIP phones seem to need this 'feature'.


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

Re: [Siproxd-users] Remote NAT Traversal

[Alejandro O. <ao...@te...>]

Some companis, like Jasomi, implement
NAT Relay Agents. They work like SIP Proxies but
make sure all signaling and RTP goes through then
allowing enpoints behing NAT router to initiate
or terminate calls withouth using any other NAT
traversal mechanism (STUN, uPNP or an ALG).

J.Rosenberg wrote a draft for a protocol called
TURN (Traversal Using Relay NAT -
draft-rosenberg-midcon-turn). The NAT Relay
agent is very similiar to that but is transparent
to end enpoint (endpoints don't need to explicitly
allocate ports at the TURN server).

The advantage of such a solution is that you don't
need a siproxd running on each of the network edges.

Alejandro

> Hello Alejandro
>
> I'm not aware of a technique called 'remote NAT traversal'. Could you
> describe more in detail what exactly you do mean by that?
> What is the situation you have and what would you like to do?
>
> The main purpose of Siproxd is to enable SIP user agents that are
> 'hidden' behind a masquerading firewall (e.g. in a private IP range) to
> call and be called to/from the internet.
>
> /Thomas
> Maintainer of Siproxd
>
>
> On 13 Mar, Alejandro Olchik wrote:
>>
>> I was trying to figure out if the siproxd can be
>> used as a solution for remote NAT traversal.
>>
>> Thanks,
>> Alejandro Olchik
>>
>>
>
> --
> GnuPG Public Key:
> pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
> uid                            Thomas Ries <tho...@gm...>
> Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

Re: [Siproxd-users] Remote NAT Traversal

[Thomas R. <tr...@gm...>]

Hello Alejandro

I'm not aware of a technique called 'remote NAT traversal'. Could you
describe more in detail what exactly you do mean by that?
What is the situation you have and what would you like to do?

The main purpose of Siproxd is to enable SIP user agents that are
'hidden' behind a masquerading firewall (e.g. in a private IP range) to
call and be called to/from the internet.

/Thomas
Maintainer of Siproxd


On 13 Mar, Alejandro Olchik wrote:
> 
> I was trying to figure out if the siproxd can be
> used as a solution for remote NAT traversal.
> 
> Thanks,
> Alejandro Olchik
> 
> 

-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] Remote NAT Traversal

[Alejandro O. <ao...@te...>]

I was trying to figure out if the siproxd can be
used as a solution for remote NAT traversal.

Thanks,
Alejandro Olchik

[Siproxd-users] hello

[Fabrice c. f. <reg...@fr...>]

Hello,
I'm looking for pple who did experienced the siproxd trough a 2 FWs 
configuration.

fabrice.

[Siproxd-users] siproxd-0.2.6 released (new features & bugfix)

[Thomas R. <tr...@gm...>]

Version 0.2.6 has been released.

This release now *finally* fixes the MSN messenger crash.
It also introduces RTP proxy capability of handling multiple RTP
data streams withing a single SIP session (eg. audio and video session).
This feature has to be field tested - test reports are welcome.

http://siproxd.sourceforge.net/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

0.2.6
=====
-  28-Jan-2003:	- released 0.2.6
		- New Feature: RTP proxy should be able to handle multiple
		  media stream in the same session (audio + video)
-  21-Jan-2003:	- Bugfix: crash in compare_url (MSN Messenger issue)
-  19-Jan-2003:	- use of libosip-0.9.3 not possible yet -
                  libosip fails in msg_setproxy_authenticate
                  -> Bug in libosip? to be investigated!
		- give IP address in debug for 'received packet'
                - 'WARNING:proxy.c:202 request from/to unregistered UA' now
                  includes sender and destination url
-  17-Jan-2003:	- OpenBSD: do not link against gnugetopt (Luke Renn)


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] Daily snapshots available

[Thomas R. <tr...@gm...>]

Automated daily snapshots of the siproxd package are available on:

http://www.ries.ch.vu/siproxd/

They will be made daily at 6am UTC.


/Thomas

-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] siproxd-0.2.5 released (major bugfix)

[Thomas R. <tr...@gm...>]

Version 0.2.5 has been released.

This release mainly fixes a stupid bug in the via loop detection (false
positive) and also should fix a segfault during UA registration with
MSN messenger.
Currently only the source tar.gz will be available - I simply don't have
the time to prepare the RPMS. (I just managed to get this one out - as I
am leaving for vacations on saturday).


http://siproxd.sourceforge.net/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

Release Notes for siproxd-0.2.6
===============================
 This release mainly fixes some annoying (and stupid) bugs.
 See the ChangeLog for details.

 - supports Linux and FreeBSD (other BSD derivates not tested)
 - SIP Proxy for SIP based softphones hidden behind a masquerading firewall
 - Includes an RTP data stream proxy for *incomming* audio data
   (outgoing RTP data should be handled by IP masquerading by the firewall)
 - Port range to be used for incomming RTP traffic is configurable
   (-> easy to set up apropriate firewall rules for incomming traffic)
 - Multiple local users/hosts can be masqueraded simultaneously
 - Supports running in a chroot jail (configurable)
 - Supports changing user-ID after startup (if started as root)
 - All configuration done via one simple ascii configuration file
 - Proxy Authentication for registration of local clients (User Agents)
   with individual passwords for each user
 - Logging to syslog in Daemon mode
 - Access control (IP based) for incomming traffic
 - RPM support (release includes SRC rpm and binary RPMS for Redhat 6.0, 7.2)
 - should now works with "dial-up" conenctions (changing IP addresses)

Requirements:
 - pthreads
 - libosip 0.8.8 

Currently tested on:
- Linux 2.2.x (Redhat 6.0) and 2.4.x (Redhat 7.2), should run
  on others Linux distributions as well.
- FreeBSD 4.7-STABLE (compilation)

Reported to build on:
- OpenBSD 2.9


Reported interoperability (tested with softphones):
 - Linphone (http://www.linphone.org)
 - Kphone (http://www.wirlab.net/kphone/)
 - MSN messenger 4.6


-----
md5sum for siproxd-0.2.6.tar.gz: 	042986602efeaaa77a14bb0b1a416083
md5sum for siproxd-0.2.6-1rh60.i386.rpm:
md5sum for siproxd-0.2.6-1rh72.i386.rpm:
md5sum for siproxd-0.2.6-1.src.rpm:	

GnuPG signature for siproxd-0.2.6.tar.gz archive:




0.2.5
=====
-  6-Dec-2002:	- released 0.2.5 (major bugfixes)
		- Bugfix: MSN messenger 4.6 caused a segfault due to
		  non supplied username in contact header during
                  registration. (Credits to Dhiraj Bhuyan for the hint)
                  Included additional tests in that area.
-  4-Dec-2002:	- fixed a major (but stupid) bug in check_vialoop. Siproxd
		  wrongly claimed to have detected a loop...


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94

[Siproxd-users] siproxd-0.2.4 released (minor feature enhancements)

[Thomas R. <tr...@gm...>]

Version 0.2.4 has been released. This Release now build also on FreeBSD.

http://siproxd.sourceforge.net/

Feedback, Bugreports (and of course also success messages) to:
tries at gmx.net

Release Notes for siproxd-0.2.4
===============================
 - supports Linux and FreeBSD (other BSD derivates not tested)
 - SIP Proxy for SIP based softphones hidden behind a masquerading firewall
 - Includes an RTP data stream proxy for *incomming* audio data
   (outgoing RTP data should be handled by IP masquerading by the firewall)
 - Port range to be used for incomming RTP traffic is configurable
   (-> easy to set up apropriate firewall rules for incomming traffic)
 - Multiple local users/hosts can be masqueraded simultaneously
 - Supports running in a chroot jail (configurable)
 - Supports changing user-ID after startup (if started as root)
 - All configuration done via one simple ascii configuration file
 - Proxy Authentication for registration of local clients (User Agents)
   with individual passwords for each user
 - Logging to syslog in Daemon mode
 - Access control (IP based) for incomming traffic
 - RPM support (release includes SRC rpm and binary RPMS for Redhat 6.0, 7.2)
 - should now works with "dial-up" conenctions (changing IP addresses)

Requirements:
 - pthreads
 - libosip 0.8.8 

Currently tested on:
- Linux 2.2.x (Redhat 6.0) and 2.4.x (Redhat 7.2), should run
  on others Linux distributions as well.
- FreeBSD 4.7-STABLE (compilation only)


Interoperability (tested with softphones):
 - Linphone (http://www.linphone.org)
 - Kphone (http://www.wirlab.net/kphone/)

-----
md5sum for siproxd-0.2.4.tar.gz: 	1f9bd5fb0031870cf8cc25fb1098d687
md5sum for siproxd-0.2.4-1rh60.i386.rpm:1862342b8b006632aec0eb6619a53ae9
md5sum for siproxd-0.2.4-1rh72.i386.rpm:35896373a8a091a4edfcec26418f6b76
md5sum for siproxd-0.2.4-1.src.rpm:	757b63b6365d19b62ae6e5f98489f913

GnuPG signature for siproxd-0.2.4.tar.gz archive:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)

iEYEABECAAYFAj3fwmAACgkQPOYHDi42pIqQtwCdGBsqWmqMsw0ADwH63VBP4r9K
rMwAn3VjqrmeBZ9s9mHyCtmvTaZPNsPX
=w2Ce
-----END PGP SIGNATURE-----


0.2.4
=====
- 23-Nov-2002:	- released 0.2.4 (feature enhancements)
		- BSD: resolved some compatibility issues (sscanf ->
		  resulted in coredump when reading config file)
		  should now build on *BSD (tested on FreeBSD 4-7)
		- inbound/outbound interfaces now can be specified
		  by their interface name - this removes the need
		  for a 'quasi' static IP and restarting siproxd at
		  change of IP address.
- 13-Nov-2002:	- working on portability - goal is building on *BSD
		  (feedback from Georg Schwarz)


-- 
GnuPG Public Key:
pub  1024D/87BCDC94 2000-03-19 Thomas Ries <tr...@gm...>
uid                            Thomas Ries <tho...@gm...>
Key fingerprint = 13D1 19F5 77D0 4CEC 8D3F  A24E 09FC C18A 87BC DC94